Rebasing & History

Rebasing is a way to integrate changes from one branch into another by replaying commits rather than creating a merge commit. The result is a cleaner, linear history.

Merge vs. Rebase

With merge, the original commits (D, E) stay in history and a merge commit (M) ties the two lines together. You can always see which commits came from the feature branch.

With rebase, commits D and E are replayed on top of main as new commits (D', E'). They get new hashes because their parent has changed. The history appears linear — as if the feature was developed after C.

---

Rebase a Branch onto Main

# Make sure main is up to date
git switch main
git pull

# Rebase your feature branch
git switch feature-x
git rebase main

Git replays each commit on your branch on top of the latest main. If there are conflicts, it pauses at each one — just like a merge conflict.

Resolve a rebase conflict

# After editing the conflicted file:
git add <conflicted-file>
git rebase --continue

Abort the rebase

git rebase --abort

Returns you to the state before git rebase started.

---

Interactive Rebase

Interactive rebase opens an editor where you can edit, reorder, squash, or drop commits. It is the most powerful history-editing tool in Git.

git rebase -i HEAD~3

This opens the last 3 commits in your editor:

pick 9f8e7c6 Add greeting file
pick 3d2c1b0 Fix typo in greeting
pick a1b2c3d Add second line to greeting

Change pick to:

• reword — edit just the commit message
• squash — combine this commit into the one above it
• fixup — like squash but discard this commit's message
• drop — delete the commit entirely

---

Squash Commits

A common workflow: you have a feature branch with many "WIP" and "fix typo" commits. Before opening a PR, squash them into clean, logical commits.

git rebase -i HEAD~4

Change:

pick a1b2c3d Add login form
squash 9f8e7c6 WIP
squash 3d2c1b0 fix typo
squash e5d4c3b another WIP

Git combines all four into a single commit and opens the editor for you to write the final message.

---

The Golden Rule

Never rebase shared branches

Rebasing rewrites commit hashes. If you rebase a branch that someone else has already pulled, their copy will be out of sync in a way that is confusing and painful to fix.

Only rebase local, unpushed commits — or branches where you are the only person working on them.

Recommended workflow

1. Develop on a local feature branch.
2. Before opening a PR, git rebase main to put your commits on top of the latest main.
3. Let GitHub's merge button handle the final merge into main.

---

Summary

Command	What it does
git rebase main	Replay current branch's commits on top of main
git rebase --continue	Continue after resolving a rebase conflict
git rebase --abort	Cancel the rebase
git rebase -i HEAD~N	Interactively edit the last N commits