Module 6 Lesson 2: Git rebase: linearizing history

We already know how to merge branches. But merging creates "Merge Commits," which can make your history look like a tangled spiderweb.

Rebasing is an alternative way to integrate changes. Instead of "merging" two branches together, it takes all the commits you made on one branch and "re-plays" them on top of another.

---

1. Merge vs. Rebase

The Merge Approach

• Goal: Join histories.
• Result: A new "Merge Commit" is created.
• Pros: Non-destructive; preserves the exact timeline of when things happened.
• Cons: History becomes cluttered.

The Rebase Approach

• Goal: Move a branch to a new starting point.
• Result: No merge commit. Commits are rewritten to look like they were always part of the main line.
• Pros: Perfectly linear history.
• Cons: Rewrites history (dangerous if shared).

graph TD
    subgraph "Merge Result"
        M_Ancestor --> M_Main
        M_Ancestor --> M_Feature
        M_Main --> M_Merge
        M_Feature --> M_Merge
    end
    
    subgraph "Rebase Result"
        R_Ancestor --> R_Main
        R_Main --> R_Feature_Commits["Feature Commits (Reset to new base)"]
    end

---

2. How to Rebase

Imagine you are on feature-x and main has moved forward since you started. You want to "catch up" without a merge commit.

# 1. Be on your feature branch
git switch feature-x

# 2. Rebase onto main
git rebase main

Git will find the common ancestor, set aside your feature commits, move your branch to match the current main, and then try to apply your commits one by one.

---

3. The Golden Rule of Rebasing

NEVER rebase branches that you have pushed to a public repository.

Because rebasing "rewrites" history (it gives your commits new SHA-1 IDs), if someone else has already pulled your old commits, they will find themselves in a broken state when they try to pull the "new" versions.

Rule of Thumb: Rebase locally to clean up your own work, but use Merge when combining work with others.

---

4. Handling Rebase Conflicts

If a conflict happens during a rebase, it's slightly different from a merge. Git stops at the specific commit where the conflict occurred.

1. Fix the conflict in your editor.
2. git add <file>
3. Instead of commit, run: git rebase --continue
4. Git will then try to apply the next commit in your branch.

---

Lesson Exercise

Goal: Comparing Merge and Rebase.

1. Create a branch merge-branch from main. Add a commit. Switch to main and add a commit. Merge them. Behold the graph: git log --oneline --graph.
2. Now, create a branch rebase-branch from main. Add a commit. Switch to main and add another commit.
3. Switch back to rebase-branch.
4. Run git rebase main.
5. Behold the graph again. Notice it’s a perfectly straight line!

Observation: You'll see that rebasing makes it look like you waited for your teammate to finish their work before you ever started yours. It’s "clean" but technically a lie about the timeline.

---

Summary

In this lesson, we established:

• Rebasing re-plays commits on top of another branch.
• It creates a linear history without merge commits.
• It rewrites commit IDs, making it dangerous for shared branches.
• Conflicts are resolved commit-by-commit using --continue.

Next Lesson: Sometimes you don't want a whole branch; you just want one specific commit. Welcome to Lesson 3: Cherry-picking commits.