For a long time, I was telling myself how ugly those fucking merge bulks were on my git history. Then I learned about
git-rebase and how clean my history can be thanks to these command.
But recently, I was in a debate with my CTO on how consistent
git-rebase is even for the history on a uniq branch, like
His point was that having a merge bulk in our history represents the reality, ie
different developers worked in parallel on the same project on the same branch at the same time. It's just a matter of graph.
My point is that using rebase does not hide this parallelism in the project
history and allows a cleaner and more linear history. It is way simpler to read,
in my point of view at least. But I do not have a real argument against the
But I went through some lectures and something went in my mind. To explain it, I will shortly (re)explain what
rebase is about.
The rebase, as its noun indicates, reset the starting point of a branch and
reapplies the set of commits you are fetching. Merge conflicts are combined with these commits so they become grouped together. And that, my friends, it is a huge difference to me!
Using merge to pull in changes mixes those changes with the resolved merge conflicts. This means that the current branch won't necessarily have the same state as the one it was based on (from the hierachical structure). Since the resolved conflicts are grouped all together in one merge commit, you have also made it harder to cleanly cherry-pick individual changes.
cherry-pick stuff is one of the reasons you really should consider using rebase.
If you can bring me more, I would really be happy about that!
For more details on
git rebase and
git merge, read git merge vs git rebase: Avoiding Rebase Hell by Jarrod Spillers.
If you are still afraid of
git rebase, you should read The Magical (And Not Harmful) Rebase by Jeff Kreeftmeijer.
Source : http://makingthingssimpler.com/post/why-you-should-consider-using-git-rebase