Introduction

Changing a commit message after push is possible, but it rewrites commit history because the commit hash includes message text. If nobody has pulled the branch yet, this is usually safe as long as you push carefully and verify remote state before and after. The key is to treat this as a controlled history rewrite, not a routine edit.

Know When Message Rewrites Are Safe

A rewrite is safe only when the branch is effectively private or when teammates explicitly confirm they are not based on the old commit hash. If another developer already pulled, rebased, or reviewed against that hash, rewriting can cause confusion and extra repair work.

Before you amend anything, check three things:

• You are on the correct branch.
• Your working tree is clean or intentionally staged.
• The remote branch has not moved unexpectedly.

1git branch --show-current
2git status -sb
3git fetch origin
4git log --oneline --decorate -n 5
5git log --oneline --decorate origin/feature/webhook-validation -n 5

This short preflight prevents accidental edits on the wrong branch and catches remote drift early.

Update the Most Recent Commit Message

For the latest commit, the workflow is direct: amend locally, then force push with lease protection.

git commit --amend -m "feat(api): validate webhook signature before processing"

This command changes only the message when no content changes are staged. If files are staged, they become part of the amended commit. That behavior is useful in some cases but risky when your goal is text-only correction. Run git status immediately before --amend to avoid surprises.

Reword an Older Commit With Interactive Rebase

If the wrong message is not the latest commit, use interactive rebase. Mark only the target commit as reword, keep others as pick, and continue.

git rebase -i HEAD~5

After the editor opens:

• Replace pick with reword on the commit that needs a new message.
• Save and close.
• Enter the corrected message when Git prompts.

Then finish the operation:

git rebase --continue

Interactive rebase rewrites that commit and every descendant commit. That is expected behavior, so run it only when the branch ownership and timing are clear.

Push Rewritten History Safely

After amend or rebase, a normal push is rejected because the remote branch still points to old history. Use lease-protected force push.

git push --force-with-lease origin feature/webhook-validation

--force-with-lease is the safer default because it refuses to overwrite remote updates that you have not fetched. This is especially important when teams commit quickly and branch tips can move between your local rewrite and push attempt.

If lease push fails, do not switch to raw --force immediately. Fetch again, inspect divergence, and decide whether to reapply your rewrite on top of newer history.

Verify Result and Communicate the Change

After pushing, verify both local and remote references show the corrected message.

git fetch origin
git log --oneline --decorate -n 3
git log --oneline --decorate origin/feature/webhook-validation -n 3

In a pull request workflow, leave a short note in the PR thread that commit history was rewritten to correct commit text. That prevents reviewer confusion when previously referenced hashes disappear from discussion.

A concise note can be: rewritten commit message for clarity, content unchanged. This keeps the audit trail understandable for everyone following the branch.

Recovery If You Rewrite the Wrong Commit

Mistakes are recoverable in most cases through reflog, which stores recent branch tip positions.

git reflog -n 15
git reset --hard HEAD@{3}

The reflog entry index will differ in your repository, so inspect output carefully before reset. If you want extra safety, create a rescue branch at the reflog target first and inspect commit history there.

git branch recovery/pre-rewrite HEAD@{3}

This gives you a non-destructive checkpoint while you verify what happened.

Common Pitfalls

• Running git commit --amend with staged files and accidentally changing both message and code.
• Using plain git push --force and overwriting new remote commits.
• Rewriting history on protected or shared integration branches where force push is restricted.
• Skipping git fetch before force-with-lease, which makes lease checks less useful.
• Forgetting to notify reviewers that commit hashes changed.

Summary

• Commit message edits after push require history rewrite because commit hashes change.
• Use git commit --amend for the latest commit and interactive rebase for older commits.
• Push rewritten history with git push --force-with-lease, not plain force.
• Verify local and remote branch tips after the rewrite.
• Use reflog for recovery if the rewrite targeted the wrong commit.
• Communicate rewrite actions in team workflows to keep review context clear.