Chapters
Chapters

Chapters

Hide chapters

Advanced Git

Third Edition · Git 2.50 · Console

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: Advanced Git

Section 1: 7 chapters
Show chapters Hide chapters

Section II: Git Workflows

Section 2: 5 chapters
Show chapters Hide chapters

5. Rebasing to Rewrite History
Written by Jawwad Ahmad

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

As you saw in the previous chapter, rebasing provides you with an excellent alternative to merging. But rebasing also gives you the ability to reorganize your repository’s history. You can reorder, rewrite commit messages and even squash multiple commits into a single, tidy commit if you like.

Just as you’d tidy up your code before pushing your local branch to a remote repository, rebasing lets you clean up your commit history before you push to remote. This gives you the freedom to commit locally as you see fit, then rearrange and combine your commits into a handful of semantically-meaningful commits. These will have much more value to someone (even yourself!) who has to comb through the repository history at some point in the future.

Note: Again, a warning: Rebasing in this manner is best used for branches that you haven’t shared with anyone else. If you must rebase a branch that you’ve shared with others, then you must work out an arrangement with everyone who’s cloned that repository to ensure that they all get the rebased copy of your branch. Otherwise, you’re going to end up with a very complicated repository cleanup exercise at the end of the day.

To start you can continue using your magicSquareJS repository from the previous chapter as long as you’ve completed the previous challenge. Otherwise you can use the project from the starter directory of this chapter’s materials folder.

Reordering commits

You’ll start by taking a look at Will’s wValidator branch. Execute the following to see what the current history looks like:

git log --oneline --graph wValidator

You’ll see the following at the top of your history graph:

* dc24e14 (HEAD -> wValidator) Updated team acronym to teamWYXZC
* 72c4e8f Added Chris as a new maintainer to README.md
* 4c5274c Refactoring the main check function
* f0f212f Removing TODO
* d642b89 check04: Checking diagonal sums
* 791744c util06: Adding a function to check diagonals
* 556b640 check03: Checking row and column sums
* 75a6d1f util05: Fixing comment indentation
* 72ec86a util04: Adding a function to check column sums
* 34a656c util03: Adding function to check row sums
* 0efbaf2 check02: Checking the array contains the correct values
* 136dc26 (origin/zValidator) Refactoring the range checking function
* 665575c util02: Adding function to check the range of values
* 0fc1a91 check01: checking that the 2D array is square
* 5ec1ccf util01: Adding the checkSqaure function
* 69670e7 Adding a new secret

It’s not terrible, but this could definitely use some cleaning up. Your task is to combine the latest two trivial updates to README.md into one commit. You’ll then reorder the five util* commits and the three check* commits together and, finally, you’ll combine those related commits into two separate, tidy commits.

Interactive rebasing

First up: Combine the two top commits into one, inside the current branch. You’re familiar with rebasing branches on top of other branches, but in this chapter, you’ll rebase commits on top of other commits in the same branch.

Squashing in an interactive rebase

Here, Git’s taken all of the commits past your rebase point, 72c4e8f and dc24e14, and put them at the top of the file with some rather helpful comments down below.

Creating the squash commit message

In this case, you’ll just create your own. Clear this file as follows:

Reordering commits

The asynchronous and messy nature of development means that sometimes you’ll need to reorder commits to make it easier to squash a set of commits later on. Interactive rebase lets you literally rearrange the order of commits within a branch. You can do this as often as you need, to keep your repository history clean.

Rewording commit messages

If you take a look at the util01 commit message, you’ll notice that it’s misspelled as “Sqaure” instead of “Square”. As a word nerd, I can’t leave that the way it is. But I can quickly use interactive rebase to change that commit message.

Squashing multiple commits

Now that you have your utility functions all arranged contiguously, you can proceed to squash these commits into one.

Challenge 1: More squashing

You’d like to squash all of the check0x commits into one tidy commit. And you could follow the pattern above, where you first rearrange the commits in one rebase and then perform the squash in a separate rebase.

Challenge 2: Rebase your changes onto main

Now that you’ve squashed your work down to just a few commits, it’s time to get wValidator back into the main branch. It’s likely your first instinct is to merge wValidator back to main. However, you’re a rebase guru by this point, so you’ll rebase those commits on top of main instead:

Key points

  • git rebase -i <hash> starts an interactive rebase operation.
  • Interactive rebases in Git let you create a “script” to tell Git how to perform the rebase operation
  • The pick command means to keep a commit in the rebase.
  • The squash command means to merge this commit with the previous one in the rebase.
  • The reword command lets you reword a particular commit message.
  • You can move lines around in the rebase script to reorder commits.
  • Rebasing creates new commits for each original commit in the rebase script.
  • Squashing lets you combine multiple commits into a single commit with a new commit message. This helps keep your commit history clean.

Where to go from here?

Interactive rebase is one of the most powerful features of Git because it forces you to think logically about the changes you’ve made, and how those changes appear to others. Just as you’d appreciate cloning a repo and seeing a nice, illustrative history of the project, so will the developers that come after you.

4. Demystifying Rebasing
6. Gitignore After the Fact
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now