Squashing commits in Git - Deep Dive

Overview - Squashing commits

What is it?

Squashing commits means combining multiple small changes into one single change in your git history. It helps keep the project history clean and easier to understand. Instead of many tiny steps, you get one clear step that shows the full change. This is often done before sharing your work with others.

Why it matters

Without squashing, git history can become cluttered with many small, sometimes meaningless commits. This makes it hard to track what changed and why. Clean history helps teams review code faster, find bugs easier, and understand the project’s evolution. Squashing also helps when you want to undo or revert changes safely.

Where it fits

Before learning squashing, you should know basic git commands like commit, branch, and rebase. After mastering squashing, you can learn advanced git workflows like interactive rebasing, cherry-picking, and managing pull requests effectively.

Mental Model

Core Idea

Squashing commits is like merging several small puzzle pieces into one big piece to make the picture clearer and simpler.

Think of it like...

Imagine writing a story in a notebook with many tiny notes on each page. Squashing is like rewriting those notes into one neat paragraph so the story is easier to read and understand.

┌───────────────┐
│ Commit A     │
├───────────────┤
│ Commit B     │
├───────────────┤
│ Commit C     │
└──────┬────────┘
       │ Squash
       ▼
┌───────────────┐
│ Commit ABC   │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding git commits

Concept: Learn what a git commit is and how it records changes.

A git commit is like a snapshot of your project at a point in time. Each commit saves changes you made to files with a message explaining why. You create commits using 'git commit -m "message"'.

Result

You have a saved state of your project with a message describing the changes.

Understanding commits is essential because squashing works by combining these saved snapshots into one.

2

Foundation

Basic git history and branches

Concept: Learn how commits form a history and how branches organize work.

Git stores commits in a chain called history. Branches are pointers to different lines of work. You can see history with 'git log'. Branches let you work on features separately.

Result

You can view your project's commit history and understand how branches separate work.

Knowing history and branches helps you see where squashing fits in cleaning up your work before merging.

3

Intermediate

What is commit squashing

Concept: Introduce the idea of combining multiple commits into one.

Squashing means taking several commits and merging them into a single commit. This is often done to tidy up before sharing code. It keeps history simple and focused.

Result

Multiple commits become one, making history cleaner.

Recognizing squashing as a way to simplify history helps you write clearer project stories.

4

Intermediate

Using interactive rebase to squash

🤔Before reading on: do you think 'git rebase -i' can only reorder commits or also combine them? Commit to your answer.

Concept: Learn how to use 'git rebase -i' to pick and squash commits interactively.

Run 'git rebase -i HEAD~N' where N is the number of commits to review. In the editor, change 'pick' to 'squash' or 's' for commits you want to combine into the previous one. Save and close to apply.

Result

Selected commits are combined into one with a new commit message.

Knowing interactive rebase lets you control history precisely, not just squash but also reorder or edit commits.

5

Intermediate

Editing commit messages when squashing

🤔Before reading on: do you think git automatically keeps all commit messages when squashing, or lets you edit them? Commit to your answer.

Concept: Learn how git lets you write a new message for the combined commit.

After choosing commits to squash, git opens an editor showing all messages. You can edit, combine, or rewrite them to make a clear, single message that explains the whole change.

Result

The final commit has a clean, meaningful message summarizing all changes.

Editing messages during squash helps communicate clearly what the combined commit does.

6

Advanced

Squashing commits in pull requests

🤔Before reading on: do you think squashing commits before merging a pull request is optional or recommended? Commit to your answer.

Concept: Understand why teams squash commits before merging code into main branches.

Many teams require squashing to keep main branch history clean. When you squash before merging a pull request, reviewers see one clear change. This reduces noise and makes reverting easier if needed.

Result

Main branch history stays simple and easy to follow.

Knowing team workflows around squashing helps you collaborate better and avoid messy histories.

7

Expert

Risks and pitfalls of squashing commits

🤔Before reading on: do you think squashing commits can cause problems if done after sharing code? Commit to your answer.

Concept: Learn when squashing can cause conflicts or confusion, especially with shared branches.

Squashing rewrites history, changing commit IDs. If others have based work on original commits, this causes conflicts. It's best to squash before pushing or coordinate closely with your team. Also, squashing too much can hide useful history.

Result

You avoid breaking others' work and keep useful history intact.

Understanding the risks of rewriting history prevents common collaboration problems.

Under the Hood

Git stores commits as snapshots with unique IDs (hashes). Squashing creates a new commit that combines changes from multiple commits and replaces the old ones in history. This changes commit hashes and the chain structure. Git uses a directed acyclic graph to track commits, so rewriting history means updating pointers and hashes carefully.

Why designed this way?

Git was designed for flexibility and speed. Squashing is possible because commits are immutable snapshots linked by hashes. Rewriting history lets users clean up mistakes or organize work better. Alternatives like merge commits keep all history but can clutter logs, so squashing offers a cleaner option.

HEAD -> Commit ABC (new squashed commit)
  ↑
  ├─ Commit A
  ├─ Commit B
  └─ Commit C

Squash replaces A, B, C with ABC and moves HEAD.

Myth Busters - 4 Common Misconceptions

Quick: Does squashing commits erase your changes or just combine them? Commit yes or no.

Common Belief: Squashing deletes the changes made in the commits.

Reality: Squashing combines the changes into one commit; no changes are lost unless explicitly removed.

Why it matters: Believing changes are lost may cause fear of squashing and prevent cleaning history.

Quick: Can you squash commits after pushing to a shared branch without issues? Commit yes or no.

Common Belief: You can safely squash commits anytime, even after pushing to shared branches.

Reality: Squashing after pushing rewrites history and can cause conflicts for others using the branch.

Why it matters: Ignoring this leads to broken collaboration and confusing merge conflicts.

Quick: Does squashing always improve git history? Commit yes or no.

Common Belief: Squashing always makes history better and clearer.

Reality: Over-squashing can hide useful details and make debugging harder.

Why it matters: Misusing squashing can remove valuable context and slow down problem-solving.

Quick: Is 'git merge --squash' the same as interactive rebase squashing? Commit yes or no.

Common Belief: 'git merge --squash' and interactive rebase squashing do the same thing.

Reality: 'git merge --squash' prepares changes for a single commit but does not rewrite history like rebase does.

Why it matters: Confusing these commands can lead to unexpected history states and workflow errors.

Expert Zone

1

Squashing can be combined with reordering commits to create a logical, easy-to-follow history.

2

Some teams prefer to squash only minor fixup commits, keeping meaningful commits separate for clarity.

3

Squashing affects commit hashes, so it must be done carefully to avoid disrupting shared branches.

When NOT to use

Avoid squashing on public branches already used by others to prevent conflicts. Instead, use merge commits or revert commits for shared history. Also, do not squash commits that represent distinct logical changes; keep them separate for clarity.

Production Patterns

In professional workflows, developers squash feature branch commits before merging to main branches using pull requests. Continuous integration systems often require clean history, and some platforms offer 'Squash and merge' buttons to automate this. Teams use commit message templates during squash to maintain consistent documentation.

Connections

Version Control History

Builds-on

Understanding how git history works is essential to grasp why squashing rewrites commit chains and how it affects collaboration.

Code Review Process

Supports

Squashing commits helps produce cleaner pull requests, making code reviews faster and more focused on meaningful changes.

Writing Clear Essays

Analogy in a different domain

Just like combining multiple rough drafts into one polished essay improves clarity, squashing commits refines project history for better understanding.

Common Pitfalls

#1 Squashing commits after pushing to a shared branch without coordination.

Wrong approach:

git rebase -i HEAD~3
# squash commits

git push origin feature-branch

Correct approach:

git rebase -i HEAD~3
# squash commits

git push --force-with-lease origin feature-branch

Root cause:

Forgetting that rewriting history requires force pushing and coordination to avoid breaking others' work.

#2 Squashing all commits including meaningful separate changes.

Wrong approach:

git rebase -i HEAD~5
# squash all commits into one

Correct approach:

git rebase -i HEAD~5
# squash only minor fixup commits, keep main changes separate

Root cause:

Misunderstanding that all commits should be combined, losing valuable context.

#3 Not editing commit messages after squashing, leaving confusing combined messages.

Wrong approach:

git rebase -i HEAD~3
# squash commits
# accept default combined message without editing

Correct approach:

git rebase -i HEAD~3
# squash commits
# edit commit message to summarize changes clearly

Root cause:

Ignoring the importance of clear commit messages reduces history readability.

Key Takeaways

Squashing commits combines multiple small changes into one clear commit to keep git history clean and understandable.

Interactive rebase is the main tool to squash commits, allowing you to pick, squash, and edit commits before sharing.

Squashing rewrites history, so it should be done before pushing or with careful coordination to avoid conflicts.

Good commit messages during squash help communicate the purpose of combined changes clearly.

Overusing squashing or doing it incorrectly can hide useful history or break collaboration, so use it wisely.

Practice

1. What is the main purpose of squashing commits in Git?

easy

A. To revert the last commit without changing history

B. To combine multiple commits into one for a cleaner history

C. To create a new branch from the current commit

D. To delete all commits from the repository

Solution

1. Step 1: Understand commit history management

   Squashing is used to combine several commits into a single commit to simplify the commit history.

2. Step 2: Identify the purpose of squashing

   This helps keep the project history clean and easier to read by reducing clutter from many small commits.

3. Final Answer:

   To combine multiple commits into one for a cleaner history -> Option B

4. Quick Check:

   Squashing = combine commits [OK]

Hint: Squash = combine commits to clean history [OK]

Common Mistakes:

• Thinking squashing deletes commits permanently
• Confusing squashing with branching
• Believing squashing reverts commits

2. Which Git command starts an interactive rebase to squash commits?

easy

A. git commit --squash HEAD~3

B. git merge -i HEAD~3

C. git rebase -i HEAD~3

D. git reset --soft HEAD~3

Solution

1. Step 1: Identify the command for interactive rebase

   The command to start an interactive rebase is git rebase -i followed by the commit range.

2. Step 2: Confirm the correct syntax

   git rebase -i HEAD~3 opens the last 3 commits for editing, allowing squashing.

3. Final Answer:

   git rebase -i HEAD~3 -> Option C

4. Quick Check:

   Interactive rebase = git rebase -i [OK]

Hint: Use git rebase -i to start squashing commits [OK]

Common Mistakes:

• Using git merge -i which does not exist
• Trying git commit --squash which is invalid
• Confusing reset with rebase for squashing

3. Given these commits:

commit1: Add README
commit2: Fix typo
commit3: Update README formatting

If you run git rebase -i HEAD~3 and squash commit2 and commit3 into commit1, what will the commit history show?

medium

A. One commit combining messages from commit1, commit2, and commit3

B. Three separate commits unchanged

C. One commit with message from commit1 only

D. Two commits: commit1 and combined commit2+commit3

Solution

1. Step 1: Understand squash behavior in interactive rebase

   Squashing merges commits into one, combining their changes and commit messages.

2. Step 2: Result of squashing commit2 and commit3 into commit1

   The final commit will include all changes and combined commit messages from all three commits.

3. Final Answer:

   One commit combining messages from commit1, commit2, and commit3 -> Option A

4. Quick Check:

   Squash merges commits and messages [OK]

Hint: Squash merges commits and their messages together [OK]

Common Mistakes:

• Assuming only the first commit message remains
• Expecting commits to stay separate after squash
• Thinking squash deletes commit messages

4. You ran git rebase -i HEAD~4 to squash commits but got a conflict error. What should you do next?

medium

A. Manually fix the conflicts, then run git rebase --continue

B. Abort the rebase with git rebase --abort and try again

C. Run git reset --hard to discard all changes

D. Push your changes immediately to remote to fix conflicts

Solution

1. Step 1: Understand conflict during rebase

   A conflict means Git needs you to fix code differences manually before continuing.

2. Step 2: Resolve conflicts and continue rebase

   Fix the conflicts in files, then run git rebase --continue to proceed with squashing.

3. Final Answer:

   Manually fix the conflicts, then run git rebase --continue -> Option A

4. Quick Check:

   Fix conflicts + git rebase --continue [OK]

Hint: Fix conflicts manually then git rebase --continue [OK]

Common Mistakes:

• Aborting rebase without trying to fix conflicts
• Using git reset --hard which discards work
• Pushing incomplete changes to remote

5. You squashed commits locally and want to update the remote branch. What is the correct command to push your changes safely?

hard

A. git push --all origin

B. git push origin main

C. git push --no-verify origin main

D. git push --force-with-lease origin main

Solution

1. Step 1: Understand effect of squashing on commit history

   Squashing rewrites commit history, so the remote branch history differs from local.

2. Step 2: Use force push safely

   To update remote with rewritten history, use git push --force-with-lease to avoid overwriting others' work accidentally.

3. Final Answer:

   git push --force-with-lease origin main -> Option D

4. Quick Check:

   Force push safely after squash [OK]

Hint: Use git push --force-with-lease after squash [OK]

Common Mistakes:

• Using normal git push causing rejection
• Using --no-verify which skips hooks but not force push
• Pushing all branches unnecessarily