Martin Belev

Today we are going to look at how Git merge and rebase commands behave while trying to keep feature branch up to date.

In a large codebase where a lot of people are working, we have constant updates to the master branch. We want to work on top of this branch and always have to latest changes. We can achieve this by either using merge or rebase to get the latest changes made in the master branch into our feature branch.

Link to this heading

merge

So what is merge doing:

Join two or more development histories together

Let's now look at an example using merge to keep our branch up to date. This is pretty simple example with a few commits in each branch:

1* c5d39ef (HEAD -> feature) update 1 feature.txt
2* 0c4d97c add feature.txt
3| * 4d55c54 (master) update 1 master.txt
4|/
5* 2358179 add master.txt
6
7// Different representation of the situation
8A---B  master
9 \
10  C---D  feature

We started our feature branch from master where at first there was only one commit A. We made a commit 'C' in our feature branch. In the meantime, someone made a commit B in the master branch and after that, we made another commit D in our feature branch. We now have to get the latest changes from master into our feature branch and we are going to use merge.

After executing git merge master from our feature branch we got:

1*   ec3f6dc (HEAD -> feature) Merge branch 'master' into feature
2|\
3| * 4d55c54 (master) update 1 master.txt
4* | c5d39ef update 1 feature.txt
5* | 0c4d97c add feature.txt
6|/
7* 2358179 add master.txt
8
9// Different representation of the situation
10A---B  master
11 \
12  C-B-D-E  feature

It has it's benefits, of course, like every other thing in software development but the drawbacks in the large codebase are huge.

• It is hard to go back and change/clean our feature branch commits.
• It is making hard to follow and find out when/why something was done.

In this simple example maybe it is understandable what happened. But in real life where we got hundreds of commits and we will make a lot of redundant merge commits. You can imagine that this is going to become almost impossible to follow when we are working for a long time on a feature because we will end up with a lot of merge commits.

Link to this heading

rebase to the rescue

So what is rebase doing:

Reapply commits on top of another base tip

We will review the same scenario using rebase instead.

1A---B  master
2 \
3  C---D  feature

After executing git rebase master from our feature branch we got:

1* 7d4b7c0 (HEAD -> feature) update from-rebase.txt
2* 5b61ccd add from-rebase.txt
3* d694446 (master) update rebase.txt
4* 8f8b0e3 add rebase.txt
5
6// Different representation of the situation
7A---B  master
8     \
9      C'-D'  feature

We got our changes reapplied over the latest commit from the master branch. Note: the commits have the same set of changes but from Git point of view they are completely different objects and have different hashes.

Link to this heading

Conclusion

By using rebase we benefit from:

• making the history in our master branch much easier to follow because it is linear
• long tramlines from long-lived feature branches
• ability to easily change our feature branch history

There are a couple of things to keep in mind though:

• it can be confusing for less experienced Git users
• we are losing the chronological order - IMO this is not a problem at all because we achieve a series of intentional changes that are made to master branch
• it can result in fixing the same conflict for every commit in the feature branch - for this one, I find really useful the git rerere configuration which is saving the resolved conflicts and then reusing them. With it, we don't have to resolve the same conflict all over again.

I don't recommend blindly use rebase to keep your feature branches up to date but for larger projects, my preference is to use rebase instead of merge.