Git: rebase vs merge

Recently I’ve started a new project with a team of .NET developers, and had to choose a branching strategy for the codebase. Previously I had a nice experience with rebase strategy and propose to use it here as well. Because it’s really different from the merge strategy (and all my new teammates didn’t experience anything other), I’ve conducted a workshop for the team, showing them the difference and benefits of rebasing.

Merge flow

First of all, let’s consider a traditional merge flow (figure 1). Let’s imagine, two developers are working on features, which affect the same bunch of source files.

Figure 1

Let’s run quickly through it:

• There are 2 commits in master branch (purple ones)
• We create a new feature/x branch from master and make 2 commits to it (orange ones)
• Meanwhile, master goes forward — an additional commit pulled from origin (a red one)
• Now we have to merge all the changes together — it doesn’t matter, how to merge: master -> feature/x or vice versa — anyway, after all, we’ll have the repo state, as shown in the last picture. Yes, we have an additional merge commit (a green one), since we had to solve merge conflicts.

Here is a screenshot from a demo git repo, I’ve created for the workshop:

Figure 2

Not a very friendly and pretty look, isn’t it?

Right, but what we can do with this?

Rebase flow

And that’s when rebase arrives. Let’s consider figure 3:

Figure 3

• There are 2 commits in master branch (purple ones)
• We create a new feature/x branch from master and make 2 commits to it (orange ones)
• Meanwhile, master goes forward — an additional commit pulled from origin (a red one)
• Once we do a rebase feature/x to master — Git puts commits from feature/x branch on top of the current master’s head one by one (this operation is also known as cherry-picking), with resolving merge conflicts on the fly. Finally, we’ll get a pretty linear history as shown in the last picture.

Screen from another repo as well:

Figure 4

Looks much more beautiful, I believe.

Summary

Basically, that’s it. One more thing — if you try to use rebasing for more clear Git history, combine it with meaningful commit messages guidelines — these two guys are a real power when used together — it’ll make your search through the history a pleasure.