Daniel Hoelbling-Inzko talks about programming
One common mistake and my team seem to be doing at times with Git is that we routinely commit after resolving a merge conflict during a rebase.
The idea is simple: Instead of doing thousands of merges (thus cluttering the timeline of the project) whenever someone wants to check something into the central repository he fetches the remote changes and applies his local changes onto the remote ones.
Thanks to Visual Studio and it's way of having every source file referenced from the .csproj files (I hate that btw), we routinely get merge conflicts on the project files that need to be manually resolved. During a rebase this means the rebase will stop on the commit that caused the conflict and you have to fix it.
After you are done with fixing the conflict (usually it's just removing the conflict markers Git inserted) you then have to add the now merged file to the index (aka staging area) and hit git rebase --continue
.
Problem is: Since it's just a special state of a repository you can just as easily do the following:
git add -A
git commit
Good job you just put your repository into limbo mode and your merge is gone .. You recorded a commit onto your rebase-HEAD
and you can't continue the rebase because the rebase head is no longer where it belongs to.. So once you try to do git rebase --continue
git will tell you: "No changes - did you forget to use 'git add'?" And when you run git status
you'll see: "Not currently on any branch. nothing to commit"
Your only avenue here is:
git rebase --abort
git checkout master
git rebase origin/master
... redo the merge
git rebase --continue