How to Change a Git Commit Message After Pushing or Locally

Writing descriptive git commit messages is critical for tracking project milestones. However, developers frequently commit changes too quickly, leaving typos, incorrect ticket references, or missing descriptions in the git log history.

Fortunately, Git allows you to edit and update your commit messages.

The strategy you choose depends on whether the commit is still residing on your local machine, has already been pushed to a remote server, or is buried deep in your commit history.

In this guide, we will step through how to amend the most recent commit, run interactive rebases for older commits, and handle remote synchronization safely.

Case 1: Editing the Most Recent Commit (Not Yet Pushed)

If you made a typo in your last commit and have not yet run git push, you can replace the latest commit message immediately.

Run the commit command with the --amend flag:

# Amend the latest local commit message
git commit --amend -m "The updated, correct commit message"

This updates the message on your local branch without generating a duplicate commit record.

Case 2: Editing the Most Recent Commit (Already Pushed)

If you amended a commit locally that was already pushed to a remote server (like GitHub), the remote repository will reject a standard git push because the commit hash values no longer align.

You must force Git to accept the updated history.

Step 1: Amend Locally

Update the message on your local computer:

git commit --amend -m "New descriptive message"

Step 2: Push with force-with-lease

To publish the corrected history, push it to the server using the --force-with-lease flag:

# Push history update to the remote branch safely
git push --force-with-lease origin main

Why use --force-with-lease instead of --force? The basic --force flag overwrites the remote repository regardless of other developers' work. If a team member pushed commits to the remote branch after your last fetch, --force will delete their work. The --force-with-lease flag checks if the remote branch matches your local tracking branch, aborting the push if changes exist.

Case 3: Editing Older or Multiple Commits (Interactive Rebase)

If the commit you need to edit is not the latest one, but is located 2, 3, or more commits back in your git history, you must use Interactive Rebase.

Step 1: Launch Interactive Rebase

To inspect and rewrite the last N commits (e.g., the last 3 commits), run:

# Open interactive rebase shell for the last 3 commits
git rebase -i HEAD~3

This launches a text editor listing the target commits:

pick a1b2c3d Add login UI component
pick e4f5g6h Fix styling bugs
pick i7j8k9l Update package dependencies

Step 2: Mark Commits for Rewording

Change the word pick to reword (or just r) next to the commit messages you want to edit:

reword a1b2c3d Add login UI component
pick e4f5g6h Fix styling bugs
pick i7j8k9l Update package dependencies

Save and close the editor (in Vim: type :wq then Enter; in Nano: Ctrl+O then Ctrl+X).

Step 3: Edit the Messages

Git will sequentially open a text editor window for each commit you marked as reword. Edit the commit message text, save, and exit.

Once all messages are updated, Git will finalize the rebase:

Successfully rebased and updated refs/heads/main.

Step 4: Update the Remote

If these commits were already pushed to the remote server, force-push the rebased history:

git push --force-with-lease origin main

The Golden Rule of Rewriting Git History

Never rewrite or force-push commits that are part of a shared public branch (like main or master) where other developers are actively building. Rewriting history changes the SHA hashes of commits, which forces team members into detached HEAD states and corrupts their repository history. Limit history rewriting to your personal, unmerged feature branches.

Conclusion

Editing Git commit messages preserves repository documentation. Use git commit --amend to update your most recent local commit, deploy git push --force-with-lease to update corrected records on remote servers safely, utilize git rebase -i to reword older commits, and protect shared public branches by limiting history rewrites to isolated feature branches.