Learn how to change a commit message in Git using simple and safe methods. This guide covers git commit --amend, editing messages before and after push, and best practices to avoid breaking your repository history.
Table of Contents
When You Need to Change a Git Commit Message
Every developer has been there: you type git commit -m "fxi stuff", press Enter, and immediately wince. Or you push a commit with a vague message like “update” only to confuse your teammates three weeks later during a code review. Knowing how to change a commit message in git is a fundamental skill that keeps your project history clean and meaningful.
Fix a Typo or Unclear Message
The most common reason to git change commit message is a plain old typo. A message like "Adds usre authentication" is both embarrassing and unhelpful. Beyond typos, vague messages like "changes" or "wip" give zero context to anyone reading the log later.
Follow Commit Message Conventions
Many teams enforce commit conventions like Conventional Commits (e.g., feat:, fix:, chore:). If you forgot the prefix or used the wrong type, editing the message keeps CI checks and changelogs accurate.
Update Incorrect or Missing Information
Sometimes a commit message references the wrong ticket number, describes the wrong behavior, or simply omits the “why.” A corrected message saves hours of archaeology when someone bisects a bug six months from now.
Pro Tip
Git Change Commit Message Before Push (Safest Way)
Changing a commit message before you push to a remote repository is completely safe — no one else has seen that commit yet, so rewriting it affects only your local history. This is by far the preferred approach whenever possible.
Using the Amend Command
The git commit --amend command opens your default text editor (usually Vim or Nano) with the last commit message pre-populated. You edit the message, save, and close — and Git replaces the commit with a corrected one.
git commit --amend
# Your editor opens with something like:
Fix usre authentication typo
# Please enter the commit message for your changes.
# Lines starting with '#' will be ignored, and an empty
# message aborts the commit.
#
# Date: Sat Apr 11 10:22:00 2026 +0200
#
# On branch main
# Your branch is up to date with 'origin/main'.Edit the first line to your corrected message, then save and close the editor. Git creates a brand-new commit object with the updated message and the same changes as before.
Change Last Commit Message Inline
If you want to skip the editor entirely, pass the new message directly with the -m flag. This is the fastest way to git amend commit message without any interactive prompts:
# Replace the last commit message in one line
git commit --amend -m "Fix user authentication typo"
[main 3f92a1c] Fix user authentication typo
Date: Sat Apr 11 10:22:00 2026 +0200
1 file changed, 4 insertions(+), 2 deletions(-)Example Workflow
Here’s a complete, realistic scenario of making a commit and then immediately correcting the message:
# Step 1: Stage your changes
git add src/auth.js
# Step 2: Commit with a typo by mistake
git commit -m "Adds usre login endpoint"
[main a1b2c3d] Adds usre login endpoint
# Step 3: Catch the typo immediately — fix it!
git commit --amend -m "Add user login endpoint"
[main e4f5g6h] Add user login endpoint
1 file changed, 42 insertions(+)
# Step 4: Verify the corrected message
git log --oneline -1
e4f5g6h (HEAD -> main) Add user login endpointResult
Git Amend Last Commit Message (Quick Fix)
The git amend last commit message workflow is your fastest tool for quick corrections. It’s a one-command operation, but it’s important to understand exactly what it does under the hood — because the side effects matter.
When to Use Amend
- You’re fixing only the most recent commit (the one pointed to by
HEAD) - The commit has not been pushed to a shared remote branch
- You want to also add forgotten files using
git addbefore amending - You need to correct the author information using
--author
Important Boundary
git commit --amend only touches the last commit. For older commits, you need interactive rebase. Amend cannot reach back two or more commits in the history.What Happens Internally
This is where many developers get surprised. When you run git commit --amend, Git does not simply update the message in place. It:
- Takes the current staging area and the previous commit’s tree
- Creates abrand-new commit objectwith the updated message (and a new SHA-1 hash)
- Moves the branch pointer (
HEAD) to the new commit - Leaves the original commit unreferenced — it will eventually be garbage collected
# BEFORE amend:
a1b2c3d (HEAD -> main) Adds usre login endpoint
9f8e7d6 Add signup form
# AFTER git commit --amend -m "Add user login endpoint":
e4f5g6h (HEAD -> main) Add user login endpoint ← new hash!
9f8e7d6 Add signup form
# Note: a1b2c3d no longer exists in the visible history
# The commit hash changed because the commit object changedThe key takeaway: commit hash changes are why amending pushed commits causes problems. If you’ve already shared a1b2c3d with teammates, and you replace it with e4f5g6h, their local histories diverge from the remote — leading to conflicts.
Safe Zone Rule
git push yet, amending is always safe. Once you push, treat the commit as shared history and proceed with caution.Git Change Commit Message After Push
So you’ve already pushed, and the commit message is wrong. It happens. The question is: how do you git amend commit message after push safely without destroying your team’s workflow? Here are your options — from least to most disruptive.
Amend + Force Push
The most direct way to change git commit message after push without breaking history (for a solo branch or personal fork) is to amend locally and then force-push. Always prefer --force-with-lease over bare --force — it’s a safer variant that fails if someone else pushed to the branch since your last fetch.
# Step 1: Amend the last commit message locally
git commit --amend -m "Fix login token expiry validation"
# Step 2: Force push using the safer --force-with-lease flag
git push --force-with-lease origin main
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done.
To github.com:yourname/your-repo.git
+ a1b2c3d...e4f5g6h main -> main (forced update)–force-with-lease vs –force
--force-with-lease checks that the remote tip matches what you last fetched. If a teammate pushed something while you were amending, the command fails instead of silently overwriting their work. Always prefer it.Why Force Push Is Dangerous
Force-pushing rewrites the remote branch’s history. Anyone who has pulled from that branch now has a diverged local copy. When they try to push or pull, Git will report conflicts because their history references the old commit hash that no longer exists on the remote.
# Teammate tries to pull after your force push:
git pull origin main
hint: You have divergent branches and need to specify how to reconcile them.
fatal: Need to specify how to handle the diverged branches.
# They now need to reset or rebase to align with the new remote history
git fetch origin
git reset --hard origin/main # ⚠️ loses their local unpushed work!Safer Alternative for Teams
If the branch is shared with multiple developers, the safest path is often not to rewrite history at all. Instead:
- Communicate first — tell your team you’re about to force-push and ask them to stash or pause work on that branch
- Use a follow-up commit — add a new commit like
"docs: correct previous commit message context"(though this doesn’t fix the original message) - Use git revert — if the commit introduced bad content (not just a bad message),
git revertcreates a new undo commit without rewriting history - Protect main/master — configure branch protection rules on GitHub/GitLab that block force pushes to shared branches entirely
Golden Rule
main, master, or any shared branch without explicit team coordination. Reserve force pushes for your own feature branches only.Git Edit Older Commit Messages (Interactive Rebase)
What if the bad commit message isn’t the last one? Maybe it’s three commits back in your feature branch. This is where git rebase change commit message comes in — specifically, interactive rebase with the reword action.
Start Interactive Rebase
The -i flag puts rebase in interactive mode. You tell Git how many commits back to include using HEAD~N, where N is the number of recent commits you want to view and potentially edit.
# Open interactive rebase for the last 3 commits
git rebase -i HEAD~3
# Your editor opens with a list like this:
pick a1b2c3d Add user signup form
pick e4f5g6h Fxi login endpoint validtion ← this one has typos
pick i7j8k9l Update README with API docs
# Commands:
# p, pick = use commit as-is
# r, reword = use commit, but edit the message
# e, edit = use commit, but stop for amending
# s, squash = merge into previous commit
# d, drop = remove commit entirelyChange “pick” to “reword”
To edit a commit message, change pick to reword (or just r) on the line of the commit you want to fix. Leave all other lines as pick. Then save and close the editor.
# Change this:
pick e4f5g6h Fxi login endpoint validtion
# To this (use 'r' or 'reword'):
reword e4f5g6h Fxi login endpoint validtion
# Save and close → Git pauses and opens the message editor:
Fix login endpoint validation
# Edit, save, close → Git continues replaying commitsEdit Multiple Commit Messages
You can mark multiple commits as reword in the same rebase session. Git will pause at each one, let you edit the message, and then continue to the next. Here’s a full step-by-step example:
- Run
git rebase -i HEAD~4to see the last 4 commits in your editor - Change
picktorewordon every commit whose message needs fixing (you can mark multiple lines) - Save and close the rebase todo list
- For each marked commit, Git opens the message editor — update it, save, and close
- After the last message is saved, Git finishes replaying all commits with the new messages
- Verify with
git log --onelineto confirm all messages look correct
git rebase -i HEAD~3
# Editor opens — mark two commits as 'reword'
reword a1b2c3d Adds usre signup form ← typo
reword e4f5g6h Fxi login endpoint ← typo
pick i7j8k9l Update README
# Save and close. Git opens editor for first commit:
Add user signup form ← corrected
# Save, close. Git opens editor for second commit:
Fix login endpoint validation ← corrected
# Save, close. Rebase completes:
Successfully rebased and updated refs/heads/feature/auth.
git log --oneline -3
z9y8x7w (HEAD -> feature/auth) Update README
m6n5o4p Fix login endpoint validation
q3r2s1t Add user signup formResult
main, the rewritten hashes are acceptable — just force-push the branch if it’s already on the remote.Rebase Rewrites All Subsequent Hashes
Git Commit -m Message Command Example
The best way to avoid needing to git change commit message in the first place is to write great messages from the start. The -m flag lets you write the message inline — but that speed advantage disappears if you rush and produce unclear messages.
Writing Better Commit Messages
- Use the imperative mood — “Add feature” not “Added feature” or “Adding feature”
- Keep the subject line under 72 characters — it wraps in most git UIs at this length
- Capitalize the first word of the subject line
- No period at the end of the subject line
- Separate subject from body with a blank line when providing extended detail
- Explain the why, not just the what — the diff shows what changed; the message explains why
Good vs Bad Examples
The difference between a useful commit log and a useless one comes down to specificity. Here’s how common bad messages translate to better ones:
bad
fix bug Which bug? In which file? Why did it occur?
good
Fix login validation skipping empty password Specific, imperative, under 72 chars.
bad
update Update what? The database? A UI label? A config file?
good
Update API base URL for production environment Clear context, no ambiguity.
bad
Never commit WIP to a shared branch.
good
Conventional Commits format — CI-friendly.
bad
Please don’t do this to your future self.
good
Clear action, meaningful subject.
Multi-line Messages with -m
-m flags to create a subject + body without opening an editor:git commit -m "Fix cart total rounding" -m "Prices were rounding down instead of using banker's rounding, causing $0.01 discrepancies on large orders."Common Mistakes When Changing Commit Messages
Even experienced developers make these errors when editing commit history. Knowing them upfront saves you from painful recovery sessions.
Amending Pushed Commits Without Coordination
MISTAKE:
Amending a commit that teammates already pulled
HEAD points to the old commit hash. They have to manually git fetch and git reset --hard origin/main, potentially losing local work.Fix: Always check with the team before force-pushing to any shared branch. Use
--force-with-lease at minimum, and ideally coordinate on a Slack or Teams thread first.Losing Commit History with a Wrong Rebase Range
MISTAKE:
Accidentally dropping commits during rebase
pick line (or changing it to drop) removes that commit from history. If you don’t catch it before completing the rebase, the commit disappears from the branch.Fix: Use
git reflog to find the lost commit and git cherry-pick <hash> to restore it. The reflog keeps a 90-day safety net of all recent HEAD movements.# Find the lost commit hash in the reflog
git reflog
e4f5g6h HEAD@{0}: rebase -i (finish): returning to refs/heads/feature/auth
...
a1b2c3d HEAD@{5}: commit: Accidentally dropped this one
# Restore it with cherry-pick
git cherry-pick a1b2c3d
[feature/auth b2c3d4e] Accidentally dropped this oneForce Push Conflicts on Protected Branches
MISTAKE:
Trying to force-push to a protected branch
git push --force-with-lease origin main on a repo with branch protection rules enabled results in a rejected push error. This is intentional — the protection rule exists precisely to prevent history rewrites on critical branches.Fix: If you absolutely must fix a message on a protected branch, an admin can temporarily disable the protection rule, allow the force-push, and re-enable it immediately after. Document the action in your team’s change log.
Never Use –force on main
git push --force (without --lease) on a shared branch is one of the fastest ways to cause serious problems. It overwrites the remote with no safety checks. Always use --force-with-lease or configure branch protection rules to make --force impossible.Quick Comparison Table
Use this table to quickly pick the right method based on your situation — whether you need to git amend commit message for the last commit or reach further back with rebase.
| Method | Scope | Pushed? | Rewrites History? | Safety | Best For |
|---|---|---|---|---|---|
| git commit –amend | Last commit | No | Yes (new hash) | ✅ Safe | Quick pre-push fix |
| git commit –amend -m | Last commit | No | Yes (new hash) | ✅ Safe | Inline one-liner fix |
| amend + –force-with-lease | Last commit | Yes | Yes | ⚠️ Caution | Solo feature branch |
| git rebase -i (reword) | Any recent commit | No | Yes (chain rewrite) | ⚠️ Caution | Older commits, pre-push |
| rebase -i + force-push | Any recent commit | Yes | Yes | 🔴 Risky | Coordinated team effort |
| New follow-up commit | N/A (additive) | Yes | No | ✅ Safe | Shared/protected branches |
Git Change Commit Message — The Right Method for Every Situation
Knowing how to git change commit message is one of those skills that separates a developer who maintains a clean, readable history from one who leaves a trail of “fix” and “update” messages behind. The right tool depends entirely on your situation:
If the commit hasn’t been pushed yet, git commit –amend is your fastest, safest friend. For older commits on a local feature branch, interactive rebase with reword gives you surgical control over any message in your recent history. And if the commit is already pushed to a shared branch, tread carefully — coordinate with your team, use --force-with-lease, and consider whether the message is bad enough to justify the disruption.
The underlying principle is simple: rewriting local history is always safe; rewriting shared history always requires communication. Follow that rule, pair it with the comparison table above, and you’ll always know exactly which of these six methods to reach for.
Also see how to Git Remove Last Commit.
Most importantly, invest in writing better commit messages from the start — a clear, imperative-mood message under 72 characters saves far more time than any amend command ever could.
