Rewriting commit history

In version control systems, commit history serves as a record of a project's evolution. There are times when it becomes necessary to modify this history, such as merging multiple commits, amending commit messages, or removing sensitive information. Git provides various tools to achieve these operations, but they should be used cautiously to avoid collaboration issues.

Modifying the Last Commit

git commit --amend is the simplest way to modify history, allowing you to alter the content or message of the most recent commit. For example, when you forget to add a file or need to correct the commit message:

# Modify the commit message
git commit --amend -m "New commit message"

# Add a missed file
git add missed_file.js
git commit --amend --no-edit

--no-edit keeps the original commit message unchanged. Note: This generates a new commit hash, which affects work based on the original commit.

Interactive Rebase

git rebase -i is a more powerful tool for modifying multiple commits. The following operation requires specifying a base point:

git rebase -i HEAD~3  # Modify the last 3 commits

An editor will open with content similar to the following:

pick a1b2c3d First commit
pick e4f5g6h Second commit
pick i7j8k9l Third commit

Different operations can be performed by changing the keywords:

• reword: Only modify the commit message
• edit: Pause the rebase to modify the commit content
• squash: Merge the commit into the previous one
• fixup: Similar to squash but discards the commit message
• drop: Delete the commit

Example: Merging Commits

Merge three commits into one:

pick a1b2c3d First commit
squash e4f5g6h Second commit
squash i7j8k9l Third commit

After saving, you'll enter the commit message editing interface to rewrite the merged message.

Splitting a Commit

Use edit to split a commit:

1. Mark the commit to split as edit
2. When the rebase pauses, execute git reset HEAD~
3. Re-add files and commit
4. Complete the rebase: git rebase --continue

Modifying File Content in History

git filter-branch can batch-modify files in history but has poor performance. git filter-repo is recommended instead:

# Delete config.json from all history
git filter-repo --path config.json --invert-paths

# Replace email addresses in all history
git filter-repo --mailmap my-mailmap.txt

Considerations for Force Pushing

After modifying history, use git push --force. In collaborative environments, --force-with-lease is safer:

git push --force-with-lease origin main

This checks if the remote branch has been modified by others, avoiding overwriting their commits.

Recovering from Mistakes

Modifying history carries risks. Recovery can be done via:

# View operation history
git reflog

# Reset to a specific operation
git reset --hard HEAD@{2}

Practical Scenarios

Scenario 1: Cleaning Up a Development Branch

During development, there may be multiple "WIP" commits. Before merging, you can organize them:

git rebase -i origin/main
# Merge multiple commits into meaningful ones

Scenario 2: Sensitive Information Leak

If an API key was accidentally committed:

git filter-repo --replace-text <(echo "OLD_API_KEY==>NEW_API_KEY")

Scenario 3: Standardizing Commit Messages

Use reword to unify team commit message formats:

reword a1b2c3d feat: Add user login
reword e4f5g6h fix: Fix login redirect

Advanced Techniques

Automating with Commit Hooks

Add a script to .git/hooks/prepare-commit-msg to auto-format messages:

#!/bin/sh
echo "[$(date +%Y-%m-%d)] $(cat $1)" > $1

Visual Tools for Assistance

For complex histories, use visual tools like tig or gitk:

tig --all

Team Collaboration Guidelines

1. Prohibit modifying history of pushed public branches
2. Notify team members after organizing personal branches
3. Create backup tags before modifying important branches
4. Use --force-with-lease instead of --force

git tag backup-before-rebase
git push origin backup-before-rebase