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

• 1. Getting geeky with Git #1. Remotes and upstream branches
• 2. Getting geeky with Git #2. Building blocks of a commit
• 3. Getting geeky with Git #3. The branch is a reference
• 4. Getting geeky with Git #4. Fast-forward merge and merge strategies
• 5. Getting geeky with Git #5. Improving merge workflow with rebase

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:

echo "# rebase-repo" >> README.md
git init
git add README.md
git commit -m "Initial commit"
git remote add origin git@github.com:mwanago/rebase-repo.git
git push -u origin master

If you want to know the importance of the - u 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.

git branch feature-two
echo "console.log('Feature one')" > feature-one.js
git add ./feature-one.js
git commit -m "Added the first feature"
git push origin master

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

git checkout feature-two
echo "console.log('Feature two')" >> feature-two.js
git add ./feature-two.js
git commit -m "Added the second feature"
git push origin feature-two

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

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 feature - two into master, but that would create a merge commit. Instead, let’s use  rebase .

git rebase master

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

Now, let’s see the git log 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 feature - two branch. When doing that, we moved all of the changes from master to the  feature - two 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 feature - two branch to our remote repository, we might encounter some issues. Let’s try to do so:

git push origin feature-two

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 feature - two branch and it no longer matches its remote counterpart. The most straightforward way to deal with it is to  force push it.

git push --force origin feature-two

Using the -- force 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 -- force flag would cause all of that work to be erased. Instead, we can use the  -- force - with - lease flag.

git push --force-with-lease origin feature-two

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 -- fore - with - lease , 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 feature - two branch. Even though that’s the case, we rewrote the history in a way that our  feature - two contains all the commits from the master branch.

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

git checkout master
git merge feature-two

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  git log 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 feature - two branch. Then, we’ve merged the  feature - two 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.