Ah, and this is why I shun fast forward merges. You were using fast forward merges (and, honestly, I absolutely cannot blame you for doing so). A very, very sim

Ah, and this is why I shun fast forward merges. You were using fast forward merges (and, honestly, I absolutely cannot blame you for doing so). A very, very simple graphic explaining the difference can be seen here: http://stackoverflow.com/a/2850413/1397661 http://stackoverflow.com/a/2850413/1397661 The fast forward merge loses any concept of where the branch was branched from and when it was merged back in. Many in the community find the fast forward version cleaner. Sure, it is cleaner, until you need to revert that merge. After using git professionally for quite a while, my opinion is that one should almost always use --no-ff for merging (unless one really knows better). Sure, the history is a bit more complicated to view. But, if you want to easily revert that one merge, everything becomes much, much simpler. It adds a little complexity for the common case while significantly reducing the complexity for a number of slightly less common cases. That said, this ties back into the learning curve of git. How were you to know that you should do non-fast-forward merges so as to make merge reverts easier? Git has probably the steepest learning curve of any current version control system. It takes time to figure out the proper workflow for a company, and I've seen many rather intelligent people fail at git. By the way, you brought up valid points and questions, and I enjoyed this discussion.