Introduction

Modifying a Git commit means rewriting history, not editing an old record in place. That is easy on a local branch, but every rewritten commit gets a new hash, so you need to be more careful once the old history has already been pushed or shared.

Modify the Latest Commit with --amend

If the commit you want to change is the most recent one on the branch, use:

git add path/to/file
git commit --amend

If you only need to change the message:

git commit --amend -m "fix(auth): handle expired token refresh"

Git creates a new commit object to replace the old one. Even a message-only change produces a new hash.

Modify an Older Commit with Interactive Rebase

If the commit is not the tip of the branch, interactive rebase is the standard tool. Start the rebase from before the commit you want to edit:

git rebase -i HEAD~6

In the editor, change the target commit from pick to edit, then save and exit. Git stops at that commit so you can change it:

git add .
git commit --amend
git rebase --continue

Git then rebuilds the commits after the edited one on top of the new history.

Reword Without Changing the Files

Sometimes the files are correct and only the commit message needs work. In interactive rebase, use reword instead of edit.

git rebase -i HEAD~5

Mark the target commit as reword. Git will pause for the message update but leave the content unchanged.

This is a good way to clean up unclear history before opening a pull request.

Split One Commit into Several Commits

In practice, "modify this commit" sometimes means "break this commit into smaller pieces." Interactive rebase can do that too.

Mark the commit as edit, then:

1git reset HEAD^
2git add -p
3git commit -m "part 1"
4git add -p
5git commit -m "part 2"
6git rebase --continue

This is useful when one large commit should become several reviewable commits with cleaner intent.

Be Careful After Pushing

If the original commit has already been pushed, rewriting it means the local branch history no longer matches the remote branch. A normal push will fail. If you really want to replace the old branch history, use:

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

--force-with-lease is safer than plain --force because it refuses to overwrite remote changes you do not already know about.

Create a Safety Branch First

Before a complicated history rewrite, make a backup branch:

git branch backup/pre-rewrite

If something goes wrong, that branch gives you a quick way back.

You should also remember git reflog:

git reflog

The reflog records previous branch tips and is often the fastest recovery path after a mistaken rebase or amend.

Test After Rewriting

Git mechanics are only half the job. If you resolved conflicts or split a commit, run the relevant tests before publishing the rewritten branch. A clean-looking history is not useful if the branch no longer builds or behaves correctly.

Common Pitfalls

The biggest mistake is rewriting a shared branch without coordinating with other developers. Someone else may already have based work on the old commits.

Another issue is starting the interactive rebase from the wrong depth and editing the wrong commit. Check the recent history first with git log --oneline.

People also reach for plain --force when pushing rewritten history. --force-with-lease is almost always the safer option.

Finally, do not forget that every rewritten commit gets a new hash. Old references, code review comments, and branch comparisons may shift accordingly.

Summary

• Use git commit --amend for the latest commit.
• Use interactive rebase to edit, reword, or split older commits.
• Expect rewritten commits to get new hashes.
• Push rewritten history with --force-with-lease, not plain --force.
• Create a backup branch and remember git reflog before complex history edits.