We are using git-flow for our source code branch management model. If you are not familiar with git-flow, Why aren’t you using git-flow? article provides a nice overview.
Many git users may be familiar with the git merge vs git rebase debate. In essence:
- Merge is simple to use and works great. It creates however lots of merge commits especially when working with a larger team.
- Rebase keeps commit history linear and clean. It is however harder to use and can be potentially destructive.
git merge vs git rebase: Avoiding Rebase Hell article provides a great comparison of both techniques.
The way to get the best of both worlds is to be explicit about when to use one versus the other. For us the simple rules to follow are:
- Rebase feature branches.
- Never rebase develop or master branch. (Always merge into develop and master.)
- Never rebase public branches.
To implement the rules we made a small change to the standard git-flow process:
When implementing enhancements or fixes always start by creating a feature branch:
git flow feature start foo
When done with work:
- pull develop branch from github
- rebase feature branch on top of develop
git rebase develop feature/foo
- finish feature branch
git flow feature finish foo
- push develop to github
To get more details on using rebase with feature branches please go to The magical (and not harmful) rebase article.
With this simple process change, git commit history is easier to follow while risks of making a mistake are kept at bay.
Like this:
Like Loading...
We have been chosen by AlwaysOn as one of the AlwaysOn Global 250 winners. Inclusion in the AlwaysOn Global 250 signifies leadership amongst its peers and game-changing approaches and technologies that are likely to disrupt existing markets and entrenched players.
Robert Tekiela
