Module 9 Lesson 3: The 'Squash and Merge' vs 'Merge Commit' debate

When you hit the green button on GitHub to merge a Pull Request, you are often given three options:

1. Create a merge commit
2. Squash and merge
3. Rebase and merge

This isn't just a technical choice; it’s a philosophical one. In this lesson, we look at the two most popular strategies and why different teams choose them.

---

1. Create a Merge Commit (The "Full History" Way)

This is the default Git behavior. It preserves every single commit you made on your feature branch and adds a final "Merge Commit" to join it to main.

Pros

• Traceability: You can see exactly how a feature evolved, including the "messy" intermediate steps.
• Context: The merge commit acts as a marker for when the feature was completed.

Cons

• Clutter: main becomes a forest of small, insignificant commits (like "Fix typo", "Update README").
• Navigation: Harder to read the "Big Picture" of the project's progress.

---

2. Squash and Merge (The "Clean History" Way)

This takes all the commits on your feature branch and combines them into one single, high-quality commit on main.

Pros

• Atomic History: Every commit on main is a meaningful, working feature.
• Easy Reverts: If a feature breaks something, you only have to revert one commit.
• Readability: The history looks like a clean, ordered list of accomplishments.

Cons

• Loss of Detail: You lose the granular history of how the feature was built.
• Divergence: Your local feature branch will no longer match the history of main (because the IDs changed).

graph TD
    subgraph "Standard Merge"
        M1["Commit 1 (main)"] --> M_Merge["Merge Commit"]
        F1["Refactor UI"] --> F2["Fix bug"]
        F2 --> M_Merge
    end
    
    subgraph "Squash Merge"
        S1["Commit 1 (main)"] --> S2["New Atomic: Refactor UI & Fix Bug"]
    end

---

3. Which one should you use?

Most Modern Teams Choose: Squash and Merge

Platforms like GitHub and GitLab have made "Squash and Merge" the industry standard because it keeps the main branch clean and easy to manage for senior developers and DevOps pipelines.

---

Lesson Exercise

Goal: The Revert Test.

1. Imagine a feature had 20 commits, and one of them introduced a bug.
2. If you used Merge Commit, you have to find which of those 20 is the culprit.
3. If you used Squash and Merge, you can just revert the single big commit on main.
4. Which one is faster during a "Production Outage" at 2 AM?
5. Write down your preference and why.

Observation: You'll realize that "Clean History" is almost always worth the loss of "Granular Detail" in a production environment.

---

Summary

In this lesson, we established:

• Merge Commits preserve full history but add clutter.
• Squash and Merge simplifies history into meaningful atomic changes.
• Reverting a squashed commit is significantly easier than reverting partial branch history.

Next Lesson: PRs rarely enter on the first try. We’ll learn Lesson 4: Handling feedback and requested changes.