At 07:37 -0800 13 Dec 2012, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
On Dec 13, 1:58pm, Oliver Kiddle wrote: } } +* Do not merge your private feature branches onto the master branch: a } + linear history without merge commits is simpler to follow (and to } + bisect). Both "git cherry-pick" and "git merge --ff-only" can be used } + bring changes over to another branch without a merge commit. Is there any way to actually enforce this?
If the main git repository were fully under our control, yes, a hook could be setup there to reject pushes which introduce merge commits. Unfortunately, I'm not aware of any of the free git hosting sites which allow that type of policy to be configured for repositories that they host, although I haven't really looked into that.
How does one "recover" from an accidental merge commit?
If that were to happen, we'd either need to live with it or rewrite published history. I think just allowing it to stay in would be the better option, having an occasional merge in the history shouldn't introduce much confusion an is better than dealing with the mess of altering commits that were already made public.
If the accidental merge is discovered before it has been pushed, or any other changes have been made to the target branch the merge can be backed out simply by using:
git reset --hard HEAD~To reset the branch and working tree to the state before the merge, allowing another try at merging the changes without creating a merge commit. This would also blow away any uncommitted changes, although those could be safely saved away using `git stash` before doing the reset and then recovered later with `git stash pop`.