Git Rebase

Rebasing is one of Git's most powerful yet most misunderstood commands. While merging combines two branches by creating a merge commit, rebasing replays your commits on top of another branch, creating a clean linear history. Understanding when and how to use rebase versus merge is a key skill for professional development workflows.

The Concept Behind Rebasing

Imagine you are writing a book with a co-author. You both started writing from the same outline (a common ancestor commit). Your co-author has written chapters 5 and 6, which are now in the main manuscript. Meanwhile, you wrote chapters 7 and 8 on your own copy. Rebasing is like taking your chapters 7 and 8 and rewriting them as if you had started after chapters 5 and 6 were already done — making it look like you always had the latest version when you began.

How Rebase Works

When you rebase branch A onto branch B, Git:

1. Finds the common ancestor of both branches
2. Takes the changes introduced by each commit on branch A
3. Saves those changes temporarily
4. Resets branch A to point to the tip of branch B
5. Replays each saved change one at a time on top of branch B

Visually:

Notice that commits E, F, and G become E', F', and G' — they are new commits with different SHA hashes because their parent has changed, even though their content differences are the same.

Basic Rebase Commands

Rebase current branch onto main:

Rebase onto a specific branch:

Continue after resolving conflicts:

Abort a rebase in progress:

Skip a conflicting commit:

Interactive Rebase

Interactive rebase is incredibly powerful for cleaning up your commit history before sharing it with others:

This opens your editor showing the last 4 commits:

You can change pick to various actions:

• pick — keep the commit as-is
• reword — keep the commit but change its message
• squash — combine with the previous commit, keep both messages
• fixup — combine with previous commit, discard this message
• drop — remove the commit entirely
• edit — pause to amend the commit

For example, squashing a typo fix into the original commit:

Rebase vs Merge: When to Use Which

Use rebase when:

• You want a clean, linear project history
• You are working on a feature branch and want to incorporate the latest main changes
• You want to clean up messy commits before a pull request
• Your team convention prefers linear history

Use merge when:

• You want to preserve the complete history of how development happened
• You are combining a completed feature into main (especially via pull request)
• Multiple people are working on the same branch
• You want to clearly see when branches were integrated

The Golden Rule of Rebasing

Never rebase commits that have been pushed to a shared repository and that others may have based work on.

When you rebase, you rewrite commit history. If someone else has based their work on your original commits, rebasing creates a confusing situation where the same changes exist as different commits. This leads to duplicated work and messy history.

Handling Rebase Conflicts

Conflicts during rebase are resolved one commit at a time. Git replays each commit sequentially, so you might need to resolve conflicts multiple times:

After fixing the conflict:

If the same files conflict repeatedly, consider squashing related commits first with interactive rebase to reduce the number of conflict resolution steps.

Practical Workflow: Keeping Feature Branch Updated

The most common rebase workflow is keeping your feature branch up-to-date with main:

The --force-with-lease flag is safer than --force because it refuses to push if someone else has pushed commits to that branch since you last fetched.

Rebase for Pull Request Cleanup

Before submitting a pull request, use interactive rebase to present clean, logical commits:

Combine work-in-progress commits, fix typo commits, and reword unclear messages. Your reviewers will appreciate a clean, easy-to-review history.

Key Takeaways

Rebasing creates clean, linear history by replaying commits on top of another branch. It is ideal for keeping feature branches updated and cleaning up commits before sharing. However, never rebase shared history that others depend on. Interactive rebase is a powerful editing tool for crafting meaningful commit history. Combined with merge (for integration points), rebase gives you complete control over how your project history reads.