Git Branching – Merge vs Rebase
Is rebasing better than merging, or is it the other way around? What is the difference? Find out more here.
- June 2, 2018
Introduction
One of the questions I often hear from those who have been playing around with Git for a little while, without any formal training, is the desire to know more about rebasing.
However, there seems to be an endless debate in the forums, meetings and discussions of the git community – Is rebasing better than merging, or is it the other way around? What is the difference?
Well, I can’t strictly give you an answer to that. It’s like The light side vs. the dark side, Playstation vs Xbox, or United vs. City. Its an endless argument that, to me, comes down to a matter of perspective.
What is rebasing?
For those of you who don’t know, rebasing is not a new idea, it has been around for a while in tools like Rational Clearcase, and basically involves the concept of taking one development stream (or branch) and changing the starting point to include changes made on a different development stream.
You may be thinking that this is what a merge is designed to do, which is true, but the difference is that rebasing affects the start of the branch while merging affects the end of the branch. Lets take a look at an example:
Assume we have the following master and feature branches:
A merge would be very simple, allowing us to combine the changes we created in our feature, with those created on the master branch, the end result looking something like this :
With a rebase, we could create an alternate history, which looks something like this:
I am using the commit hash ID’s here as a way of showing you the contents so as you can see the hash id of the feature branch’s first commit has changed because it includes the changes made in commits 38ac30 and 81bc33, while the end result is the same as what you would get from a merge.
In reality those hash id’s would be different as there is different metadata, but hopefully this makes the concept a bit clearer.
Advantages and Disadvantages
So what are the advantages and disadvantages of each and why does it matter at all?
Merge
Advantages:
- Accurate history
- Simpler and Quicker (usually)
- Less chance of confusion
Disadvantages:
- Often contains useless log messages
- Can cause clutter
- Cannot be “squashed”
Rebase
Advantages:
- Cleaner History
- Easier to understand in the future
- Allows “squashing” of commits (combining multiple commits into a single one)
Disadvantages:
- Usually more complex
- Manipulates and falsifies history
- Should not be used on shared branches
Lets look at the points in a little more detail:
History
It is possible, by squashing branches into a single commit, rebasing them onto the master branch, and finally fast-forward merging to create a project history which is nothing more or less than a linear sequence of commits. The difference between the two can be seen here:
Merging
Squashing & Rebasing
As you can see the difference in readability is huge, especially over a longer time period with hundreds of users and hundreds of branches. but its not accurate, and it’s certainly not true.
This begs the question; what is history for? Do you want to be able to revert back to changes before an activity modified them? If this is the case, the second scenario is fine, or do you want an accurate audit to prove your IP? In which case maybe the second scenario fails.
There also tends to be very little useful data stored on any of the merge commits. They have two parents, a time stamp and a default log message, users rarely put meaningful data and working out which parent you should be diffing against is not always an easy task.
Simplicity
Git has powerful merge algorithms which means there’s a lot an automatic merge can do, unless there is a conflict git handles everything for you including what merge strategy to use.
If you do get a conflict, you simply need to resolve it once and you are done, with a rebase however, you are effectively re-writing the deltas of each individual commit onto a new starting point. This can cause a conflict for each and every commit; some of which may even look quite similar to each other. The more work you have done on the branch, the harder this may become.
Sharing data
If you rebase, you are rewriting history. If other users have access to that history you are modifying how that history looks in your own repository, maybe even on a shared server, but you cannot force another user to rewrite their history unless you have direct access to that repository.
In most cases, when that user comes to communicate with the server git will end up attempting to merge the changes from your rebased branch, with those from your original, unchanged branch.
This merge will be automatic but the end result clutters history even worse than a standard merge strategy. Rebasing branches other people are using is a bad idea and should be avoided unless you are completely comfortable with the ramifications.
Conclusion
There is no right or wrong answer here. Whether you choose to use merging or rebasing should come down to a few key questions :
- Do you need the history?
- Which are you more comfortable with?
- What does your organization’s strategy define?
Personally, while I can’t define a correct answer, I can offer an opinion which is simple enough – if you are moving other people code into a personal branch (i.e master to feature), I prefer to rebase. If you are sharing your code with other people, merging makes more sense.
Need more help with Git?
As well as specialist Git consultants and a specialist Support team, we offer a number of Git training courses. Find out more here, and let us know if you need help with anything Git related.
clearvisionwebmaster
Atlasssian expert resources
Visit our blog for expert news and articles from the Atlassian world. On our resources page you will find recorded webinars, white papers, podcasts, videos and more.
The Software Blog
Read our blog for articles offering best practice advice written by Atlassian experts, as well as the latest news concerning your software.
Software White Papers and Guides
Dive deep into Atlassian software with our white papers and guides on individual tools, partner products, services, and best practices, written by the experts.
Expert Webinars
All of our webinars are pre-recorded and available to watch on-demand. Enjoy everything from partner features to application demos and updates from Atlassian experts.
