Git Rebase – All WordPress Developers Need to Know

If you have ever worked together with someone on a project using Git, you know this problem: You have been working on a feature for a while and, since you branched out, your branch has fallen behind master. The issue is how to get your branch up to date, before you fall too much out of sync. Rebasing to the rescue!

In the illustration below, you can see a typical example of a branch that has fallen behind master:

While we work on the branch for the new theme layout, we miss out on the bug fixes happening on master. They might be relevant for our work, so it is always preferable to keep our branch as up-to-date as possible. We basically want to move the point of the branching out forward, so that instead of branching out at tag v2.3.4, we do it at fix bug #456. If we can accomplish that, out branch will have every commit that master has, plus the ones we have added ourselves.

We can use Git’s rebase command to accomplish this and make the branch look like this instead:

Let’s dive into the rebase command to see how this actually works.

If you prefer watching a video tutorial, here is a video from my “Git for WordPress Developers” course on rebasing:

A simple rebase

Before we begin rebasing, let’s take a look at our list of commits by running git log on the master branch:

commit b84990c56c6b014e4294296c5d6841053a4ac809
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:53:17 2017 +0200

    fix bug #456

commit 0a1193fd2b641b45a229908c2b4ffcb56421b980
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:52:51 2017 +0200

    fix bug #345

commit 3ea017a1519ff5d0f609f859cad7673ac73e8b95
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:50:48 2017 +0200

    tag v2.3.4

commit 48ac842baf4d16febd73027e408a81474323a26a
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:50:09 2017 +0200

    add green background

commit 159f40c1bd87afb0fd9db772ac3e8abe32b4b01d
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:49:28 2017 +0200

    initial commit

We can run the same command on the new branch too see how far back we are out of sync:

commit a77139cdda8f99c57fd8d5e9af46ee01d8a34097
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:52:03 2017 +0200

    setup post layout

commit 6a47c30fecad5338aa48e899e3749ef4ebc132fa
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:51:23 2017 +0200

    new base theme

commit 3ea017a1519ff5d0f609f859cad7673ac73e8b95
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:50:48 2017 +0200

    tag v2.3.4

commit 48ac842baf4d16febd73027e408a81474323a26a
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:50:09 2017 +0200

    add green background

commit 159f40c1bd87afb0fd9db772ac3e8abe32b4b01d
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:49:28 2017 +0200

    initial commit

As we already knew, the last commit we have in common is the tag v.2.3.4 commit. It’s time to begin our rebase. To get started, we need to run the git rebase command from the new branch and tell Git that we want to rebase on top of master. It looks like this (from the new branch):

git rebase master
First, rewinding head to replay your work on top of it...
Applying: new base theme
Applying: setup post layout

In this case, Git encountered no conflicts and could perform the rebase on its own, without our involvement. In order to rebase the branch, Git started removing commits on our new branch until it found one that was also on master. It then applied the new commits from master so both branches are basically the same. Git uses hashes to know if two commits are the same, sort of like blockchain, but that’s another story… Finally Git reapplies all the new commits from our branch, so our Git log now looks like this:

commit 0f0f7ddec7504ddc622cfcbcd897383edddb95ef
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:52:03 2017 +0200

    setup post layout

commit 083463105c29b610517029749798eb21fb8ddc4b
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:51:23 2017 +0200

    new base theme

commit b84990c56c6b014e4294296c5d6841053a4ac809
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:53:17 2017 +0200

    fix bug #456

commit 0a1193fd2b641b45a229908c2b4ffcb56421b980
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:52:51 2017 +0200

    fix bug #345

commit 3ea017a1519ff5d0f609f859cad7673ac73e8b95
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:50:48 2017 +0200

    tag v2.3.4

commit 48ac842baf4d16febd73027e408a81474323a26a
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:50:09 2017 +0200

    add green background

commit 159f40c1bd87afb0fd9db772ac3e8abe32b4b01d
Author: Peter Suhm <peter@suhm.dk>
Date:   Thu Jul 13 09:49:28 2017 +0200

    initial commit

As you can see, we now have all the commits on our new branch which is exactly what we wanted. Thank you, Git rebase!

Resolving merge conflicts

We all know that life isn’t always cakes and pies. Sometimes things does not go quite as smoothly. When Git is reapplying our commits on top of master, it is basically doing a merge every time. Merge = merge conflicts, as you probably know. If your rebase stops right in the middle of the process and Git is complaining about merge conflicts, fear not. It’s not that tricky actually. Here is how to deal with merge conflicts during a rebase:

  1. Take a deep breath
  2. Shut down your computer (JK you don’t need this step)
  3. Run git status to see which files are causing troubles
  4. Open up those files and try to resolve the merge conflicts as good as you can – if you have some kind of tests, you probably want to give them a spin
  5. Run git add to add the files to the staging area
  6. Run git rebase --continue
  7. If you have more conflicts, jump back up to step 1

See? Not that bad. Rebasing is just Git doing a bunch of merges to clean things up. If you want to see me resolve a conflict, check out the video earlier in this post.

You can find more documentation on Git rebase here.

 

Want to read more like this?

Add your email address below to stay in the loop when new content arrives. You'll never miss a post.

Peter Suhm

Peter is a web developer from the Land of the Danes. He is the creator of WP Pusher and a huge travel addict.