I’ve been only using git for little more than two years now, but having using it daily for every project (even those in subversion servers, via git-svn) I’ve learnt a few tricks and developed my own workflow.
During this semester, I have been working on a 13 people project and we are using git (and github) to manage the code. This means a large code-base with two different teams working on different parts of the software, that depend on each other. And I’m the lucky poor bastard who has to keep updated with the whole system and perform the merges of feature and bug branches.
Working on such environment makes weird stuff happen to the repository and when one gets to merge a branch, discovers everything is now broken and some stuff disappeared. Here are some things to avoid, learned from this and many other projects:
- Developer A commits some stuff. He then pushes to master.
- Developer B (almost at the same time) commits and pushes to master.
- Developer A finds out he forgot to include one file, and commit amends the file. He then pushes with -f (because an amended commit requires it) and B changes are lost for ever (not quite, but B may delete that code once pushed).
Another interesting story is about a feature X that was accepted to be merged into master, but since it was based on a really old version and a total refactor of half of the code. Smart as I were, I decided to do a rebase instead of a regular merge, to resolve merges commit by commit. Turned out I needed to undo the rebase and turn it again on a branch without my conflict solving.
As a rule of thumb, avoid at all costs to use -f, because as easy and attractive as it might seem, in the end it might corrupt your repository. Also, merges are a nice way of keeping your history clean and prevent from losing individual codes.