paint-brush
How to Use Git Rebase to Squash a Sequence of Commits to a New Base Commitā€‚by@mralx
1,788 reads
1,788 reads

How to Use Git Rebase to Squash a Sequence of Commits to a New Base Commit

by Alex Ferreira
Alex Ferreira HackerNoon profile picture

Alex Ferreira

@mralx

Front End Web Developer @hanko.io and owner of a cat...

May 4th, 2021
Read on Terminal Reader
Read this story in a terminal
Print this story
Read this story w/o Javascript
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Rebasing is one of the two Git processes of integrating changes from one branch to another. The goal of rebasing is to keep a clean, clear project history. It allows us to edit commits, squash them, remove them, amend them and so much more. Rebasing can be more powerful (and dangerous) than merging or merging a merge commit. It can be used to update a new commit message and then edit its commit message. The rebase command is followed by the -i parameter and the commit we want to modify.

Company Mentioned

Mention Thumbnail
Super
featured image - How to Use Git Rebase to Squash a Sequence of Commits to a New Base Commit
1x
Read by Dr. One voice-avatar

Listen to this story

Alex Ferreira HackerNoon profile picture
Alex Ferreira

Alex Ferreira

@mralx

Front End Web Developer @hanko.io and owner of a cat named Ubuntu

About @mralx
LEARN MORE ABOUT @MRALX'S
EXPERTISE AND PLACE ON THE INTERNET.

What is a rebase? šŸ“š

Rebasing is one of the two Git processes of integrating changes from one branch to another.

While merging always moves a branch forward in history by simply adding a new commit representing each branch integration, rebasing can be much more powerful (and dangerous) as it allows us to rewrite history.

image

Why do we rebase? šŸ§

Rebasing is the process of moving or combining (i.e. squashing) a sequence of commits to a new base commit.

Imagine youā€™re working on a feature branch and after some time you realise the main (aka "master") branch has been updated by someone else's code. This means your branch has now diverged from the main branch. At some point, you will want to include said changes in your feature branch. A common way of doing this would be to simply do a git pull from main which would add a merge commit to your feature branch.

The issues with this method can be:

  • Merge commits
     can be very vague, providing very little information in the git tree which makes debugging a much harder task
  • Updating a branch ā€” by 
    pulling/ merging
     - multiple times can result in a git history similar to this:
image
Reading this history provides very little (if any) information on what changes have been made to the project.

The goal of rebasing is to keep a clean, clear project history. So instead of pulling the 

main
 changes and add a merge commit we can tell our branch to move its commits to the top of the latest changes

image
Feature branch JIRA-123 is being rebased to the top of the master branch

By rebasing our feature branch to the top of the 

main
 branch, we keep all the changes and commits we made unaltered while getting the latest main 
updates
. In order to achieve this, we can execute the following command while in our feature branch:

$ git rebase main

This will start the rebase process. If no conflicts are found you should see a success message and your feature branch is now up-to-date with the main branch and we're one step closer to having a project history similar to this:

image

Interactive rebase šŸ”¬

Interactive rebasing brings the power of rebasing to a whole new level! It allows us to interactively change multiple commits in different ways.

You can start an interactive rebase by executing a rebase command followed by the -i parameter and the commit we want to modify:

$ git rebase -i <commit hash | HEAD position>
image
Interactive rebase CLI showing the three last commits and always in order from oldest (top) to newest (bottom)

We can tell just by looking at the list of commands displayed in the CLI how powerful this tool can be! We can edit commits, squash them, remove them, amend them and so much more. We can even permanently change the commit order!

Squashing

Squashing allows us to specify which commits we want to combine in order to help maintain clean history.

Does something like this look familiar?

image

Well, if you like committing a lot while you work you probably donā€™t like thinking about being super descriptive on every single commit message. Squashing can be extremely helpful in these situations because starting an interactive rebase you can then tell git which commits will be ā€œmergedā€ into one (or more) and then edit its commit message.

Keep in mind that we must always squash a commit ā€œintoā€ another one.

So say we have 6 commits and we think only two of them are relevant we could squash the other 4 like:

$ git rebase -i HEAD~6
image
ā€œsā€ is simply a shorthand name for ā€œsquashā€

In this case weā€™re saying weā€™d like to merge commits 2ā€“5 and include them in the first one ( 77497f5) and keep the last commit as-is.

Next git will rebase each commit to their new base ( 77497f5) and if there are no conflicts, you'll be able to change their final commit messages, and voila! Only 2 commits total!

What could go wrong? šŸ˜‡

Conflicts

Similarly to what happens with a Git merge, updating a branch with another can result in code conflicts.

A big difference in rebase conflicts is that weā€™re not dealing with one merge commit but with (possibly) multiple commits being moved.

This means rebase conflict solving is an iterative process that goes through each commit being rebased.

image
In a feature branch with two commits, if a conflict is found while rebasing commit A we fix it, tell git to continue the process to the next commit, fix the new conflicts on commit B and only then weā€™ll be done

Pushing local branch after rebasing

Rebasing a local feature branch means weā€™re rewriting history, so what this actually means is that weā€™re not cherry-picking the feature branch commits to the new base. Although visually everything looks the same, Git creates new commits (with new hashes) on the targeted branch.

This means whenever we try simply pushing our changes to our remote repo we get an error stating the local and remote branches have diverged.

To fix this problem itā€™s good practice to push using the --force-with-lease parameter.

You can check -force vs -force with lease to learn more about this.

ā€œI think I made a mistakeā€

Have you heard of the beautiful command:

$ git reflog

Reflog allows us to check every change we did to our local branch. Running the command will return something like this:

image
Reflog output showing the last 3 actions

In this case, if Iā€™d like to go back before I ever did the rebase I could jump back to HEAD~2 or using its hash instead:

$ git checkout 682c215

At this point, Iā€™m in the past and can undo the mistakes Iā€™d made before. Time travel!! šŸŽšŸ”„

If things get out of control

At any point in our interactive rebase if things get too messy and we no longer know how to fix them, we can always abort the whole process in the terminal and the interactive rebase will be canceled completely:

$ git rebase ā€” abort

Conclusion

As you can tell rebase can be used for a lot of different purposes, especially using the interactive rebase functionality. Hopefully, this article provides you with just enough to get started messing around with it.

Donā€™t worry if you run into issues understanding some of the nuances of Git rebase. It has its learning curve and thatā€™s why I included some escape methods so you can go back and try again šŸ’Ŗ

Also published on Alex's Medium

L O A D I N G
. . . comments & more!

About Author

Alex Ferreira HackerNoon profile picture
Alex Ferreira@mralx
Front End Web Developer @hanko.io and owner of a cat named Ubuntu

TOPICS

THIS ARTICLE WAS FEATURED IN...

Permanent on Arweave
Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite