Timeline for Git: simplest way of squashing commits on master
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 23, 2017 at 13:55 | comment | added | styfle |
@MarkLongair Can you add a note about the HEAD~5 syntax when selecting a commit?
|
|
| Aug 23, 2017 at 13:54 | comment | added | styfle |
@Gabe Whenever I force push a branch, I let everyone working on that branch know about it. Then they can git branch -D branchname && git checkout branchname && git pull which will delete their copy of the branch and checkout a fresh copy. We prevent any pushing to master and do all work on a feature branch. So only people working on the same feature branch are affected.
|
|
| May 23, 2017 at 11:46 | history | edited | URL Rewriter Bot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Nov 21, 2011 at 20:10 | vote | accept | Gabe | ||
| Nov 21, 2011 at 15:45 | comment | added | Mark Longair |
@whoami: Yes, it's best to restrict history rewriting to commits that you haven't pushed yet. If you know exactly that you want to squash all the last N commits, reset --soft and committing is probably easier, but if you want to selectively squash and reorder commits, using git rebase -i will give you that flexibility. (Also it depends which commands you're more familiar with...)
|
|
| Nov 21, 2011 at 15:41 | comment | added | Gabe |
Urgh sounds a bit messy either way, I suppose the moral of the story is to do it all before it goes on GitHub? In that case is reset --soft or rebase most suitable?
|
|
| Nov 21, 2011 at 15:33 | comment | added | Mark Longair |
@Noufal Ibrahim: The problem with merging in that situation is that they will still have all the small commits in their merged master branch, and might push them back to the repository.
|
|
| Nov 21, 2011 at 15:30 | comment | added | Noufal Ibrahim | They will all see that their local branches and the remote have diverged and will have to merge the changes in rather than just fast forward. | |
| Nov 21, 2011 at 15:30 | comment | added | Mark Longair |
@whoami: If someone else pulls that branch, they will see (forced update) and git will refuse to update their branch. They then need to (a) make sure that all their work is committed (b) typically either rebase (e.g. with git rebase origin/master) or reset their branch to the remote-tracking branch version that's just been force-updated (e.g. with git reset --hard origin/master). Unless you're happy explaining to people what to do, it's definitely best not to force-push rewritten history.
|
|
| Nov 21, 2011 at 15:23 | comment | added | Gabe | What are the repercussions of doing this if other branches regularly pull from the repo (fast forwarding only)? | |
| Nov 21, 2011 at 15:19 | history | answered | Mark Longair | CC BY-SA 3.0 |