This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Rebasing Branches

What is Rebasing?

Rebasing is a way to move or combine a sequence of commits to a new base commit.
In simple terms, rebasing lets you “replay” your work from one branch onto another branch, creating a cleaner, linear history.

Why Use Rebase?

  • Cleaner History:
    Rebasing creates a straight line of commits, making the project history easier to read.
  • Avoids Merge Commits:
    Unlike merging, rebasing doesn’t create extra merge commits unless there are conflicts.
  • Keeps Features Up-to-Date:
    You can update your feature branch with the latest changes from main before merging.

How Does Rebasing Work?

Imagine you have this history:

A---B---C main
         \
          D---E feature

If you run git rebase main while on feature, Git will:

  1. Temporarily remove commits D and E from feature.
  2. Move feature to the tip of main (commit C).
  3. Replay D and E on top of C.

Result:

A---B---C---D'---E' feature
  • D' and E' are new commits (copies of D and E).

Basic Rebase Command

git checkout feature
git rebase main
  • This moves your feature branch to start from the latest commit on main.

Interactive Rebase

Interactive rebase lets you edit, reorder, squash, or drop commits.

git rebase -i HEAD~n
  • Replace n with the number of commits you want to edit.
  • You’ll see a list of commits in your editor, where you can:
    • pick (keep as is)
    • reword (edit commit message)
    • squash (combine commits)
    • drop (remove a commit)

Rebasing vs. Merging

ActionResultHistory Shape
MergeCombines branches, creates merge commitsBranched
RebaseMoves commits, creates linear historyStraight line
  • Merge preserves the full branch structure.
  • Rebase rewrites history for a cleaner look.

Handling Conflicts During Rebase

  • If there’s a conflict, Git will pause and let you resolve it.
  • After fixing the conflict, run:
    git add <file>
git rebase --continue
  • If you want to abort the rebase:
    git rebase --abort

When (Not) to Rebase

  • Do rebase:
    • On your own feature branches before merging, to clean up history.
  • Do NOT rebase:
    • On public branches that others are using. Rebasing rewrites commit history, which can confuse collaborators.

Visualizing Rebase

Use this command to see your commit history as a graph:

git log --oneline --graph --all

Tip:
Rebasing is powerful for keeping your history tidy, but always be

1 - Interactive Rebase in Git

What is Interactive Rebase?

Interactive rebase is a powerful Git feature that lets you rewrite, edit, reorder, squash, or even delete commits in your branch’s history.
It’s called “interactive” because Git opens an editor and lets you choose exactly what happens to each commit.

Why Use Interactive Rebase?

  • Clean up messy commit history before sharing your work.
  • Combine (squash) multiple commits into one.
  • Edit commit messages for clarity or consistency.
  • Reorder commits to make history logical.
  • Remove unwanted commits (like mistakes or debug code).
  • Split a commit into smaller, more focused commits.

How to Start an Interactive Rebase

Decide how many commits you want to work with (counting backwards from your current commit):

git rebase -i HEAD~n
  • Replace n with the number of commits you want to edit.
  • Example: To edit the last 4 commits:
    git rebase -i HEAD~4

The Rebase Todo List

Git opens your default text editor with a list like:

pick a1b2c3d Add login form
pick b2c3d4e Fix typo
pick c3d4e5f Add logout button
pick d4e5f6g Update styles
  • Each line is a commit, from oldest (top) to newest (bottom).
  • The word pick means “keep this commit as is.”

What Can You Do in Interactive Rebase?

Replace pick with one of these commands:

  • pick: Use the commit as is.
  • reword: Edit the commit message.
  • edit: Pause to change the commit’s content (amend).
  • squash: Combine this commit into the previous one (good for cleanup).
  • fixup: Like squash, but discard this commit’s message.
  • drop: Remove the commit entirely.
  • exec: Run a shell command.

Example: Squash and Reword

pick a1b2c3d Add login form
squash b2c3d4e Fix typo
reword c3d4e5f Add logout button
pick d4e5f6g Update styles

Step-by-Step Example: Squashing and Editing

Suppose you want to:

  • Combine “Fix typo” into “Add login form”
  • Edit the message for “Add logout button”
  1. Start the rebase:
    git rebase -i HEAD~4
  2. In the editor, change:
    pick a1b2c3d Add login form
squash b2c3d4e Fix typo
reword c3d4e5f Add logout button
pick d4e5f6g Update styles
  3. Save and close the editor.
  4. Git will prompt you to combine commit messages for the squashed commits.
  5. Git will prompt you to edit the commit message for the “reword” commit.
  6. If there are conflicts, Git will pause and ask you to resolve them:
    • Fix the files.
    • Run git add <file>.
    • Continue with git rebase --continue.

Aborting or Continuing

  • Abort the rebase and return to original state:
    git rebase --abort
  • Continue after resolving conflicts:
    git rebase --continue

When to Use Interactive Rebase

  • Before merging a feature branch, to tidy up your commits.
  • When you want to split, combine, or reorder commits for clarity.
  • When you need to edit a commit message or remove a mistake.

Caution

  • Interactive rebase rewrites history.
    Only use it on branches that haven’t been pushed/shared with others, or coordinate with your team.
  • Never rebase public/shared branches unless everyone agrees.

Tip:
Interactive rebase is one of the most powerful tools in Git for crafting a clean, professional commit history.
Practice on a test branch to get comfortable before using it on important

2 - Squash Commits with Interactive Rebase

What is Squashing?

Squashing means combining multiple commits into a single commit.
This is useful for cleaning up your commit history before merging a feature branch—so instead of a long list of tiny or “work in progress” commits, you have one clear, meaningful commit.

Why Squash Commits?

  • Cleaner History:
    Makes your project history easier to read and understand.
  • Atomic Changes:
    Groups related changes together, making it easier to review and revert if needed.
  • Professionalism:
    Shows a tidy, intentional history when collaborating or submitting pull requests.

How to Squash Commits Using Interactive Rebase

Suppose your branch has several commits you want to squash into one.

1. Start an Interactive Rebase

Decide how many commits you want to squash.
For example, to squash the last 3 commits:

git rebase -i HEAD~3

2. The Rebase Editor

Git will open your default text editor with a list like:

pick a1b2c3d First commit
pick b2c3d4e Second commit
pick c3d4e5f Third commit
  • The commits are listed from oldest (top) to newest (bottom).

3. Mark Commits to Squash

  • Leave pick on the first commit.
  • Change pick to squash (or just s) on the commits you want to combine into the first.

Example:

pick a1b2c3d First commit
squash b2c3d4e Second commit
squash c3d4e5f Third commit
  • This will squash the second and third commits into the first.

4. Write the Commit Message

  • After saving and closing the editor, Git will open another editor window to combine the commit messages.
  • Edit the message to describe the combined changes clearly.
  • Save and close the editor.

5. Finish the Rebase

  • If there are no conflicts, you’re done!
  • If there are conflicts, Git will pause and ask you to resolve them. After fixing, run:
    git add <file>
git rebase --continue

Example: Before and After Squash

Before:

* c3d4e5f - Third commit
* b2c3d4e - Second commit
* a1b2c3d - First commit

After squashing:

* z9y8x7w - Combined commit (contains all changes)

Squash While Merging (Alternative)

You can also squash all commits from a feature branch into one when merging to main:

git checkout main
git merge --squash feature-branch
git commit
  • This prepares a single combined commit from the feature branch.

When to Squash

  • Before merging a feature branch into main or develop.
  • When you want to clean up “work in progress” commits.
  • When submitting a pull request and the project prefers a tidy history.

Tip:
Squashing is a great way to make your project history clean and professional.
But remember: **never squash commits on a branch that others are working

3 - Reordering Commits with Interactive Rebase

Why Reorder Commits?

Sometimes, you make commits in an order that doesn’t make sense for the project’s history.
Maybe you fixed a typo before adding the main feature, or you want related changes grouped together.
Reordering commits helps you organize your history so it’s logical, readable, and easy to review.

How to Reorder Commits in Git

You use interactive rebase to reorder commits.
This lets you pick up any commit and move it before or after others.

Step-by-Step: Reordering Commits

Suppose your history looks like this (from newest to oldest):

* d4e5f6g - Update styles
* c3d4e5f - Add logout button
* b2c3d4e - Fix typo
* a1b2c3d - Add login form

But you want “Fix typo” to come after “Add login form” and before “Add logout button”.

1. Start an Interactive Rebase

Decide how many commits you want to reorder (counting backwards from HEAD):

git rebase -i HEAD~4

2. The Rebase Todo List

Git opens your editor with:

pick a1b2c3d Add login form
pick b2c3d4e Fix typo
pick c3d4e5f Add logout button
pick d4e5f6g Update styles
  • Commits are listed from oldest (top) to newest (bottom).
  • The order here is the order they will appear in history after the rebase.

3. Change the Order

To reorder, simply move the lines up or down.

Example:
To put “Fix typo” after “Add logout button”:

pick a1b2c3d Add login form
pick c3d4e5f Add logout button
pick b2c3d4e Fix typo
pick d4e5f6g Update styles
  • Save and close the editor.

4. Finish the Rebase

  • Git will replay the commits in the new order.
  • If there are conflicts, Git will pause and let you resolve them:
    • Fix the files.
    • Run git add <file>.
    • Continue with git rebase --continue.

Tips for Reordering Commits

  • Test after reordering:
    Changing commit order can sometimes cause conflicts or break your code if commits depend on each other.
  • Keep related changes together:
    Grouping related commits makes your history easier to understand.
  • Use meaningful commit messages:
    After reordering, you can also use reword to update messages for clarity.

When to Reorder Commits

  • Before merging a feature branch, to make history logical.
  • When you want to group bug fixes or features together.
  • When preparing a pull request for review.

Caution

  • Reordering rewrites history.
    Only reorder commits on branches that haven’t been pushed/shared, or coordinate with your team.
  • Never reorder commits on public/shared branches unless everyone agrees.

Tip:
Reordering commits is a great way to make your project history logical and professional.
Practice on a test branch to get comfortable before using it on important