Squashing commits in Git - Commands & Configuration

Introduction

Sometimes your git history has many small commits that clutter the log. Squashing commits means combining several commits into one to keep history clean and easier to understand.

When you have multiple small fixes that should be one logical change before sharing your work.

Before merging a feature branch into the main branch to keep history tidy.

When you want to rewrite commit messages for clarity and consistency.

If you accidentally committed work in several steps but want to present it as a single update.

When cleaning up your branch history before pushing to a shared repository.

Commands

Shows a short list of recent commits with their IDs and messages to identify which commits to squash.

Terminal

git log --oneline

Expected Output

a1b2c3d Fix typo in README

f4e5d6c Add user login feature

7g8h9i0 Initial commit

→

--oneline - Shows each commit in one line with short ID and message

Starts an interactive rebase for the last two commits so you can choose to squash them into one.

Terminal

git rebase -i HEAD~2

Expected Output

pick f4e5d6c Add user login feature

pick a1b2c3d Fix typo in README



# Rebase 7g8h9i0..a1b2c3d onto 7g8h9i0 (2 commands)

#

# Commands:

# p, pick = use commit

# s, squash = use commit, but meld into previous commit

# ...

→

-i - Interactive mode to edit commits

Check the commit history after squashing to confirm the commits were combined.

Terminal

git log --oneline

Expected Output

a1b2c3d Add user login feature and fix typo in README

7g8h9i0 Initial commit

→

--oneline - Shows concise commit history

Key Concept

If you remember nothing else from this pattern, remember: interactive rebase lets you combine multiple commits into one clean commit.

Common Mistakes

Using git rebase -i without specifying the correct number of commits

You might miss the commits you want to squash or include too many unrelated commits.

Count how many commits back you want to edit and use HEAD~N where N is that number.

Not changing 'pick' to 'squash' or 'fixup' in the interactive rebase editor

The commits will not be combined and the rebase will just replay them as separate commits.

Change 'pick' to 'squash' for the commits you want to merge into the previous one.

Squashing commits that have already been pushed to a shared repository

It rewrites history and can cause conflicts for others working on the same branch.

Only squash commits before pushing or coordinate with your team if rewriting shared history.

Summary

Use 'git log --oneline' to see recent commits and decide which to squash.

Run 'git rebase -i HEAD~N' to start interactive rebase for the last N commits.

In the editor, change 'pick' to 'squash' to combine commits, then save and exit.

Verify the new commit history with 'git log --oneline' to confirm the squash.

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