Rebase or Merge into Develop branch? (Small team)

Question

I work in a small team of 5 developers. We are trying to figure out how to keep our development branch as clean and less polluted as possible. Until now, we have been doing this flow:

1. Finish feature (squash all the commits)
2. Checkout to develop branch
3. Pull develop from origin
4. Merge feature branch into development (With conflict resolve if any)
5. Push changes onto origin/develop

The problem is that this usualy cause to create a new "merge...onto dev" commit, and create the diamond shape which is kinda confusing, even with only 5 developers.

Is there any better flow, maybe using rebase, to keep the develop branch cleaner and as straight as possible ?

Best regards

Answer 1

TL;DR :

• merge : when you get back a feature branch on a shared branch
• rebase : only for maintenance on local/development branches (git pull --rebase or git rebase)

So to get into details.

When I passed from svn to git, I was shocked by the graph log complexity, it seemed awful to read after using the flat svn history during years. But graph is an integral part of git and the complexity in the log came with.

To answer your question, I think you need to continue the merging of your feature branches on develop cause it brings sense to your history:

• you can see when the branch diverge
• you can see which commits were concerned by the feature
• you can see when the feature was merged back into the common pool

Concerning the rebase you absolutely have to avoid doing it on public/shared branches. Cause it's often rewriting your history, the risk of losing information is high and your distant repository will quickly be out of sync with your mate's repositories. If you need to do a git push --force on a shared branch, you are in a danger area.

I could preconise you to do rebase only to update your local branch with the distant repository. If you don't, updates will indeed create useless merge commits that will make your history dirty.

So, update your branches only with git pull --rebase and get your feature back with a old classical git merge.

An updated flow will be :

1. Finish feature (squash all the commits if needed)
2. Update feature branch with a git pull --rebase (with conflict resolution if any)
3. Checkout to develop branch
4. Pull develop from the origin (with a git pull --rebase for updating purpose)
5. Merge feature branch into development (with conflict resolution if any)
6. Push changes onto origin/develop

With some practice, you will get more comfortable with the "diamond shape".

I personally use a gup alias which is git pull --rebase to force me to use rebase on every update I do.

Hope it helps.

Julien.