How to Change a Git Commit Message, Even After Pushing

By 

Updated on

8 min read

Changing a Git commit message with git commit --amend

When working with Git, you may need to edit a commit message to fix a typo, remove sensitive information, or add missing details.

This guide explains how to change the message of the most recent commit, how to reword older commits with an interactive rebase, and what to do when the commit has already been pushed to a remote.

Quick Reference

TaskCommand
Amend the last commit messagegit commit --amend -m "New message"
Amend without changing the messagegit commit --amend --no-edit
Open editor to amend last commitgit commit --amend
Force push amended commitgit push --force-with-lease origin branch
Interactive rebase for older commitsgit rebase -i HEAD~N

For a printable quick reference, see the Git cheatsheet .

Change the Most Recent Commit Message

The git commit --amend command rewrites the most recent commit with a new message. The amended commit is a completely new Git object with a different SHA; the original commit no longer exists on the current branch.

If the commit has not been pushed to a remote repository yet, amending it is safe and straightforward.

  1. Navigate to the repository directory in your terminal.

  2. Run the following command to rewrite the message of the latest commit:

    Terminal
    git commit --amend -m "New commit message."

    The -m option lets you write the new message directly on the command line without opening an editor. To open your default editor instead, run git commit --amend without -m.

  3. If you also want to include changes you forgot to stage, add them before amending:

    Terminal
    git add forgotten-file.txt
    git commit --amend -m "New commit message."

Change a Commit Message After Pushing

Git has no way to edit a commit in place on the remote. To change the message of a commit you have already pushed, you rewrite it locally and then replace the remote branch with the rewritten history. This can cause problems for anyone who based work on the original commit, so consult your team before doing it on a shared branch.

  1. Amend the message of the latest pushed commit:

    Terminal
    git commit --amend -m "New commit message."
  2. Force push to update the remote repository history:

    Terminal
    git push --force-with-lease <remote> <branch>

    Use --force-with-lease instead of --force. It refuses to overwrite the remote branch if someone else has pushed to it since your last fetch, protecting you from accidentally discarding their work.

If the commit you want to fix is not the latest one, the same rule applies: reword it locally with an interactive rebase as described below, then force push the branch.

Add Staged Changes Without Changing the Message

To amend the most recent commit by adding staged changes without touching the commit message, use --no-edit:

Terminal
git add forgotten-file.txt
git commit --amend --no-edit

This updates the commit with the new file while keeping the original message intact.

Change an Older or Multiple Commit Messages

To change the message of an older commit or several commits at once, use an interactive rebase.

Warning
Rebasing rewrites commit history. Do not rebase commits that have already been pushed to a shared remote repository without coordinating with your team first.
  1. Navigate to the repository containing the commit you want to change.

  2. Start an interactive rebase for the last N commits. For example, to work with the last five commits:

    Terminal
    git rebase -i HEAD~5

    Git opens the last N commits in your default text editor :

    plain
    pick 43f8707f9 fix: update dependency json5 to ^2.1.1
    pick cea1fb88a fix: update dependency verdaccio to ^4.3.3
    pick aa540c364 fix: update dependency webpack-dev-server to ^3.8.2
    pick c5e078656 chore: update dependency flow-bin to ^0.109.0
    pick 11ce0ab34 fix: Fix spelling.
    
    # Rebase 7e59e8ead..11ce0ab34 onto 7e59e8ead (5 commands)
  3. Replace pick with reword on each line whose message you want to change:

    plain
    reword 43f8707f9 fix: update dependency json5 to ^2.1.1
    reword cea1fb88a fix: update dependency verdaccio to ^4.3.3
    pick aa540c364 fix: update dependency webpack-dev-server to ^3.8.2
    pick c5e078656 chore: update dependency flow-bin to ^0.109.0
    pick 11ce0ab34 fix: Fix spelling.
    
    # Rebase 7e59e8ead..11ce0ab34 onto 7e59e8ead (5 commands)
  4. Save the file and close the editor.

  5. For each commit marked reword, Git opens a new editor window. Edit the message, save, and close:

    plain
    fix: update dependency json5 to ^2.1.1
  6. Once all messages are updated, force push the changes to the remote repository:

    Terminal
    git push --force-with-lease <remote> <branch>

Troubleshooting

Force push rejected with “stale info”
git push --force-with-lease aborts with ! [rejected] main -> main (stale info) when the remote branch does not match the value in your remote-tracking reference. This usually means someone else pushed to it. Fetch and inspect the new commits before deciding what to do:

Terminal
git fetch origin
git log --oneline HEAD..origin/main

Do not push again until you decide how to handle those commits. If they must remain, start from the fetched remote history and repeat the interactive rebase there so that the original commit is reworded and the newer commits are replayed after it. Do not simply rebase your amended tip onto origin/main, because Git can identify a message-only replacement as a duplicate patch and drop it. If you are unsure, coordinate with the contributor instead of force pushing.

Git opens Vim and you cannot get out
Git selects the commit-message editor from GIT_EDITOR, core.editor, VISUAL, or EDITOR. Interactive rebase can use the separate GIT_SEQUENCE_EDITOR or sequence.editor setting for its todo list. On many Unix systems, Git falls back to Vi. To save and quit Vim or Vi, press Esc, type :wq, and press Enter. To make Nano the default editor for Git:

Terminal
git config --global core.editor "nano"

Rebase fails with “invalid upstream”
HEAD~5 is the fifth first-parent ancestor of HEAD, so it exists only when that path contains at least six commits including HEAD. The same error can occur when a shallow clone does not contain the required ancestor. Check the revision directly:

Terminal
git rev-parse --verify HEAD~5

If the command fails, lower the number. To include the first commit in the rebase, use:

Terminal
git rebase -i --root

You started a rebase by mistake
Cancel it and put the branch back where it was:

Terminal
git rebase --abort

If Git answers fatal: no rebase in progress, the rebase already finished, so there is nothing to cancel.

You amended the wrong commit and lost the original message
The original commit normally remains in the reflog until unreachable entries expire, which is 30 days by default. Find the exact entry and display its message without moving the branch:

Terminal
git reflog
git show -s --format=%B <old-commit>

Copy the old message, then open the current commit for another amend and paste it into the editor:

Terminal
git commit --amend

This keeps the current file changes and avoids resetting the branch.

The old commit reappears after a teammate pulls
A collaborator who had the original commit and then merged instead of rebasing brings both versions back into the history. Before pointing their branch at the rewritten remote state, they should create a backup branch for local commits and stash uncommitted and untracked changes:

Terminal
git branch backup-before-sync
git stash push -u
Warning
The following reset makes the current branch match origin/main. It discards uncommitted changes that were not stashed and removes the current branch reference from local-only commits. Run it only after confirming that the backup branch exists and any needed working-tree changes were stashed.

Fetch and reset the branch only after creating those backups:

Terminal
git fetch origin
git reset --hard origin/main

The backup-before-sync branch keeps local-only commits reachable. Inspect it before deleting it, and restore stashed changes with git stash pop after confirming that the branch history is correct.

FAQ

Can I amend a commit without changing the message?
Yes. Use git commit --amend --no-edit after staging the changes you want to add. Git rewrites the commit with the new content but keeps the original message.

What is the difference between --force and --force-with-lease?
--force overwrites the remote branch unconditionally. --force-with-lease checks that no one else has pushed to the branch since your last fetch and aborts if they have. Always prefer --force-with-lease when pushing amended or rebased commits to a shared repository.

Should I amend or revert a pushed commit?
Amending rewrites history and requires a force push, which can disrupt collaborators. If the commit is already on a shared branch, it is usually safer to revert it , which creates a new commit that undoes the change without altering history.

Can I change a commit message on GitHub or GitLab?
No. Neither GitHub nor GitLab lets you edit an existing commit message from the web interface. You have to amend or reword the commit locally and force push the branch, which is what updates the message shown on the hosting site.

How do I undo the last commit entirely?
Use git reset to move the branch pointer back. git reset --soft HEAD~1 keeps your changes staged; git reset --hard HEAD~1 discards them entirely.

Can I change the commit author as well as the message?
Yes. Each commit records the author identity configured at the time it was made. To update it along with the message, add --reset-author: git commit --amend --reset-author -m "New message.".

Conclusion

To change the most recent commit message, use git commit --amend. To change older or multiple commit messages, use git rebase -i HEAD~N, and follow either one with git push --force-with-lease when the commit is already on a remote.

For a full Git command reference, see the Git cheatsheet .

Linuxize Weekly Newsletter

A quick weekly roundup of new tutorials, news, and tips.

About the authors

Dejan Panovski

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 800+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page