Getting geeky with Git #5. Improving merge workflow with rebase

Git

This entry is part 5 of 8 in the Getting geeky with Git

Merging is not the only utility that can integrate changes from one branch onto another. In this article, we look into rebasing and learn how we can use it as an alternative to merging.

The basics of rebasing

In the previous part of this series, we’ve learned that merging can result in an additional merge commit. This might not be the desired outcome if we aim for the readability of our git logs.

Rebase aims to rewrite git history so that it is simple and straightforward. To visualize it, let’s start with a clean repository:

If you want to know the importance of the   flag, check out the first part of this series.

Below, we simulate a very common situation. Imagine creating a new branch from master and starting to work on it. Before you finish up and want to merge it back to master, it contains some new changes.

Above, we create the   branch and add some changes to the master. Now, our   is 1 commit behind the master branch. Let’s continue by adding some stuff to the .

Now, both the master and the   contain some new code. Let’s check the current state of the   with  :

commit 536676c27b51922b6e65568cebc1b7a9932704e0 (HEAD -> feature-two, origin/feature-two)
Author: Marcin Wanago <wanago.marcin@gmail.com>
Date: Sun Jul 26 18:35:46 2020 +0200

Added the second feature

commit b828ed40f9edd2aa56d99d4d351c624d7c6fbcef
Author: Marcin Wanago <wanago.marcin@gmail.com>
Date: Sun Jul 26 18:22:35 2020 +0200

Initial commit

Performing a rebase

To integrate those two, we could merge the  into master, but that would create a merge commit. Instead, let’s use rebase.

First, rewinding head to replay your work on top of it…
Applying: Added the second feature

Now, let’s see the   again:

commit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95 (HEAD -> feature-two)
Author: Marcin Wanago <wanago.marcin@gmail.com>
Date: Sun Jul 26 18:35:46 2020 +0200

Added the second feature

commit 318ff57e470d10dfe5924da38455b85dac667898 (origin/master, master)
Author: Marcin Wanago <wanago.marcin@gmail.com>
Date: Sun Jul 26 18:35:30 2020 +0200

Added the first feature

commit b828ed40f9edd2aa56d99d4d351c624d7c6fbcef
Author: Marcin Wanago <wanago.marcin@gmail.com>
Date: Sun Jul 26 18:22:35 2020 +0200

Initial commit

With rebasing, we re-wrote the history of the   branch. When doing that, we moved all of the changes from master to the   branch and applied our changes on top of it.

The important thing is that when we rebased, Git created brand new commits when applying our changes on top of the commits from the master branch. To see it better, take a closer look at the above logs. We can see that the hash of our new commit changed.

commit 536676c27b51922b6e65568cebc1b7a9932704e0
Added the second feature

commit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95
Added the second feature

Even though the above commits bring the same set of changes, they are different from the Git point of view.

Pushing our rebased changes

There is one important thing to cover here. If we would like to push the rebased version of our   branch to our remote repository, we might encounter some issues. Let’s try to do so:

To github.com:mwanago/rebase-repo.git
! [rejected] feature-two -> feature-two (non-fast-forward)
error: failed to push some refs to ‘git@github.com:mwanago/rebase-repo.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push –help’ for details.

The reason for the above is because we rewrote the history of our local   branch and it no longer matches its remote counterpart. The most straightforward way to deal with it is to force push it.

Using the   option allows us to overwrite the remote branch even if our local version of it does not strictly match it.

This is not safe, though. Imagine someone else building up on top of your branch while you are rebasing. Using the   flag would cause all of that work to be erased. Instead, we can use the   flag.

The above flag is a safer option that refuses to update the branch if somebody updated the remote branch. Aside from that, you should use this option with some caution and perform it only on branches that you don’t expect anybody else to push to.

If you want to read more about  , check out this article on the Atlassian Developer blog.

Advantages of rebasing

In the previous part of this series, we’ve learned about the fast forward merge. It can occur if there is a linear path between the source branch and the target branch.

We’ve committed to master after creating the   branch. Even though that’s the case, we rewrote the history in a way that our   contains all the commits from the master branch.

Now, we can switch to the master branch and merge our changes.

Updating 318ff57..6c943d2
Fast-forward
feature-two.js | 1 +
1 file changed, 1 insertion(+)
create mode 100644 feature-two.js

The crucial thing above is the fact that we’ve performed a fast-forward merge. Let’s look into the   now:

commit 6c943d260b6aa0fabfe77899babb8bb67ebb1e95 (HEAD -> master, origin/feature-two, feature-two)
Author: Marcin Wanago <wanago.marcin@gmail.com>
Date: Sun Jul 26 18:35:46 2020 +0200

Added the second feature

commit 318ff57e470d10dfe5924da38455b85dac667898 (origin/master)
Author: Marcin Wanago <wanago.marcin@gmail.com>
Date: Sun Jul 26 18:35:30 2020 +0200

Added the first feature

commit b828ed40f9edd2aa56d99d4d351c624d7c6fbcef
Author: Marcin Wanago <wanago.marcin@gmail.com>
Date: Sun Jul 26 18:22:35 2020 +0200

Initial commit

As you can see, there is no merge commit whatsoever. By sticking to rebasing, we end up with a linear project history that we can easily follow from the tip down to the bottom.

When not to rebase

The most important thing about rebasing is not to do it on public branches. Above, we rebased master into our   branch. Then, we’ve merged the   branch back to master using a fast forward merge. While this is fine, doing it the other way would cause trouble.

Rebasing overwrites history, and we need to acknowledge that everybody on our team uses the master branch. Therefore, if we would rewrite the history in remote master, it would cause all of its local copies not to match. Since rebasing results in creating new commits under the hood, Git will think that the history of the remote master diverged from the local copies that our teammates maintain. Avoiding that is sometimes referred to as the golden rule of rebasing.

Summary

In this article, we’ve learned what rebase is and how to perform it. It certainly does have advantages and can simplify our Git history. On the other hand, before rebasing, we need to think if anyone else might use the branch that we are working on. When considering if we should rebase, we should take it into account. The goal should be improving our Git flow and not the other way around.

Rebasing has more functionalities that we can describe as interactive rebasing. It is a cool topic, and you can expect it in this series.

Series Navigation<< Getting geeky with Git #4. Fast-forward merge and merge strategiesGetting geeky with Git #6. Interactive Rebase >>
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments