What Is a Rebase?

Software engineering is a team sport. I make changes, you make changes. We’re all on one team working together to build a performant, high-quality product.

Source control management (SCM) tools like Git have made this much, much easier than it was in the past. We can now easily synchronize changes from multiple engineers on the same team, and across a codebase for an entire team. There are still challenges that we run across in our day-to-day life though. One of the most common is, of course, the branch and merge.

Explaining Branch and Merge

An individual engineer will make changes in their local branch and then need to push those changes back up into the main branch on the remote SCM server.

The main branch on the remote SCM server is typically the ‘gold standard’ where the code lives, is built from, and deployed from. It’s the source of truth that engineers merge their code into.

There is an inevitable challenge that will happen when two engineers or teams work on the same part of the codebase and then commit one after the other. In most scenarios, that means two different branches — with two different branches of code. Having to reconcile those differences is called a merge. Sometimes the merge is pretty straightforward, as none of the files from one branch may have been edited in the other.

However, this is not always the case. In some scenarios, when the same file is edited in both branches, this is called a merge conflict.

This can be visualized, in the simplest way, as below:

Sometimes the same files may have been edited in different places or touch different variables or components. It can be as easy as just accepting the changes from both and moving on. However, when the same code is edited in both branches, this can be difficult. Sometimes even one file is deleted in one branch and not the other, causing headaches as to where to put the new changes.

Time to Rebase

One of the ways to avoid having to deal with merge conflicts is doing what’s called a “rebase.” A rebase is when a branch pulls in the changes from the main branch in the middle of development. This happens before committing to the main branch, to make it so that there is less to merge later on. This simplifies the process rather than having one big merge at the end you have a few smaller merges.

The grayed-out area is the old history of the branch. When doing the rebase you can see that Feature Team 2’s branch now includes the first commit from Feature Team 1 (v2). As a result, this makes the merge at the end for v4 less of a headache!

So the next question might be, well, how do you do a rebase? Git can initiate a rebase when you are in your feature branch by using the command git rebase <other_branch> where the other_branch is typically the branch you branched your feature branch from. In most cases, this command will actually fail because Git doesn’t know how to handle the merge conflicts of a rebase automatically. So you’ll get an error that will look something like this:

Auto-merging sample_file.js
CONFLICT (content): Merge conflict in sample_file.js
error: could not apply 60f62c9... new feature branch addition
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply 60f62c9... new feature branch addition

So now you need to handle the conflict of the rebase. Git will mark that you have a rebase open, so you can then run git mergetool to start reviewing your merge conflicts. This command will open up the diff tool that you have configured. If you have not configured one, it would be worth running the command git config merge.tool <merge_tool>. You can use a tool like opendiff to handle these.

For each diff, after it is resolved, you will need to run git rebase —continue to continue the rebase. And you’ll get another error message about the attempted auto-merge failure if you have any more conflicts. Keep doing git merge tool to resolve the merge conflicts. Once you’ve resolved all of the commits with merge conflicts you’ll get a message below about the success of your rebase!

[detached HEAD e4d1931] another commit to main
 1 file changed, 5 insertions(+), 1 deletion(-)
Successfully rebased and updated refs/heads/main.

Suppose you make a mistake during the process. In that case, you can abort the rebase using git rebase -abort. But if you want to undo a rebase after it’s already been done, you can use git reflog and reset the head of your repository. Do this at the last commit you made before the rebase started by using git reset -hard HEAD@{x} where X is the step in history that you want to revert back to.

Overall, rebasing can make merging later on easier, as it reduces the number of commits that you need to merge at the end of your development process.

Merges conflicts are painful, you can reduce the size of merges by using rebases. You can reduce merges even more by using trunk-based development, enabled by Split.

Switch It On With Split

The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Schedule a demo to learn more.

Get Split Certified

Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.