Introduction

If the commits have not been pushed yet, changing their messages is safe because you are only rewriting local history. The right Git command depends on whether you want to edit just the most recent commit or one of several older commits.

Change The Most Recent Commit Message

If only the latest commit message is wrong, use git commit --amend.

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

This replaces the message of HEAD without requiring a rebase.

A quick verification step is:

git log --oneline -n 3

Because the commit object changes, the commit hash also changes. That is normal when rewriting history.

Change Older Unpushed Commit Messages

If the commit is not the most recent one, use interactive rebase.

Suppose you want to edit one of the last three commit messages:

git rebase -i HEAD~3

Git opens an editor showing something like:

pick a1b2c3d Add parser
pick d4e5f6g Fix tests
pick h7i8j9k Update docs

Change pick to reword for the commits whose messages you want to edit:

pick a1b2c3d Add parser
reword d4e5f6g Fix tests
pick h7i8j9k Update docs

Save and close the editor. Git will pause at each reword commit and open another editor so you can enter the new message.

Example Workflow

Imagine your last two commit messages are too vague.

git log --oneline -n 2

Output:

91ab234 fix
78cd567 stuff

Rewrite both:

git rebase -i HEAD~2

Mark both lines as reword, then enter clearer messages such as:

Handle null usernames in signup validation
Refactor email service retry logic

When the rebase completes, git log --oneline -n 2 will show the improved history.

If Conflicts Appear

Changing only commit messages usually does not introduce conflicts, because the file content is not being modified. But conflicts can still happen if your branch state is unusual or if you combine message changes with other history edits.

If that happens:

git status
git add <resolved-files>
git rebase --continue

If you decide to stop:

git rebase --abort

That returns the branch to the state it had before the rebase started.

Why This Is Safe Only Before Push

Rewriting commit messages changes commit IDs. If the commits are already pushed and other people may have based work on them, changing history becomes disruptive unless everyone coordinates.

For unpushed commits, none of that collaboration risk exists yet. That is why the operation is routine and safe in local history.

Message Quality Guidelines

Since you are already rewriting the messages, use the opportunity to make them useful.

Good commit messages usually:

• describe what changed
• hint at why it changed
• avoid vague text such as fix, stuff, or updates

For example:

• weak: fix bug
• better: Prevent duplicate session creation on retry

Clear messages help later code review, debugging, and release note generation.

Common Pitfalls

A common mistake is using interactive rebase when git commit --amend would solve the problem more simply for the latest commit.

Another issue is forgetting that rewritten commits get new hashes. That is expected and not a sign of corruption.

Developers also sometimes start a rebase for too many commits, which makes the operation harder to review than necessary. Limit the range to exactly the history you need to edit.

Finally, do not rewrite pushed history casually. The question here is about unpushed commits, which is the safe case.

Summary

• Use git commit --amend to change the most recent unpushed commit message.
• Use git rebase -i with reword to edit older unpushed commit messages.
• Rewriting messages changes commit hashes because history is being rewritten.
• Conflicts are uncommon for message-only edits, but git rebase --continue and git rebase --abort handle them if needed.
• Prefer clear, specific commit messages while you are rewriting the history.