Use git commit --amend to Fix Your Last Commit

git commit –amend is the Git command that replaces the last commit on your current branch with a new commit. Run git commit --amend to edit the message in your editor, git commit --amend -m "new message" to set it inline, or git commit --amend --no-edit to fold staged changes into the last commit and keep its message.

This guide is for developers who just committed and then spotted a typo in the message, a forgotten file, a file that should not be there, or the wrong author. The amended commit gets a new hash, so the guide also shows when amending is safe, how to amend an older or already pushed commit, and how to undo an amend. Splitting and reordering many commits belong to interactive rebase and are not covered here. The last section applies the same question, how to fix something already published, to feature flag versions in Loglune, using output recorded on October 6, 2026.

What git commit –amend does

git commit --amend replaces the tip of the current branch by creating a new commit. The new commit records the tree you have staged, starts from the original commit message unless you pass -m, -F, or -c, and keeps the same parents and author as the original commit.

A rough equivalent shows what amend does step by step:

git reset --soft HEAD^
# ... make the tree you want ...
git commit -c ORIG_HEAD

The old commit is not edited in place. Amending replaces it entirely, so the amended commit is a new entity with its own ref. Amending also changes the SHA-1 of the commit.

How to change the last commit message

To change the message of your last commit, run git commit –amend with nothing staged:

git commit --amend

Git opens your editor with the last commit message filled in. Edit the message, save, and close the editor, and Git writes a new commit with the new message and the same snapshot. With nothing staged, the command edits the previous commit’s message without altering its snapshot.

To change the commit message without opening an editor, pass the new message with -m:

git commit --amend -m "Fix login timeout on Safari"

Both commands change only the most recent commit. To change the message of an older commit, see Amend an older commit.

How to add a forgotten file to the last commit

To add a file you forgot, stage it and amend with --no-edit:

git add main.py
git commit --amend --no-edit

git commit --amend --no-edit amends a commit without changing its commit message. In an example, you commit hello.py, then stage the forgotten main.py and runs the same command, and the result looks as if both files were committed in one snapshot. Drop --no-edit if you also want to edit the message.

How to remove a file from the last commit

To take a file out of the last commit and keep it on disk, remove it from the index with git rm --cached, then amend:

git rm --cached debug.log
git commit --amend --no-edit

--cached removes paths only from the index and leaves the working tree files alone, so debug.log stays in your folder as an untracked file. Add it to .gitignore if it should never be committed.

How to change the author of the last commit

--reset-author, used with --amend, declares that the authorship of the resulting commit now belongs to the committer and renews the author timestamp. Use it after you fix user.name or user.email:

git commit --amend --no-edit --reset-author

Without --reset-author, an amended commit keeps the author of the original commit.

git commit –amend options

Command	What it does
git commit --amend	Replaces the last commit; opens the editor with the old message
git commit --amend -m "msg"	Replaces the last commit with the message msg
git commit --amend --no-edit	Replaces the last commit and keeps its message
git commit --amend --reset-author	Makes you the author and renews the author timestamp
git commit --amend --only	Amends the last commit without committing changes you already staged
git commit --fixup=amend:<commit>	Creates an amend! commit that replaces the content and message of <commit> at the next git rebase --autosquash
git commit --fixup=reword:<commit>	Creates an amend! commit that replaces only the message of <commit>

The --fixup forms are how you prepare a change to a commit that is not the last one.

What happens when you amend a commit

When you amend a commit, Git creates a new commit and moves your branch to it. The old commit still exists in the repository, but no branch points to it anymore. The previous commit will no longer be on your current branch, which has the same consequences as resetting a public snapshot.

That answers the common question of commit vs commit amend:

	git commit	git commit --amend
Commits on the branch afterward	One more than before	The same number as before
The previous last commit	Stays on the branch as the parent	Is replaced and leaves the branch
Hash of the last commit	A new commit with a new hash	A new commit with a new hash; the old hash is no longer on the branch
Safe on pushed commits	Yes	Only with a force push

The old commit stays recoverable for a while through the git reflog, which is how you undo an amend.

Amend an older commit

git commit –amend only reaches the last commit. To change an older commit, start an interactive rebase. Use these steps to change older commit messages:

1. Run git rebase -i HEAD~n, where n is how many commits back to go.
2. In the list, replace pick with reword before each commit whose message you want to change.
3. Save and close the list, then write the new message in each editor that opens.

To change the files of an older commit, mark it edit instead. Git then stops at that commit with the message “You can amend the commit now, with git commit –amend”, and you run git rebase --continue when you are done. A rebase changes the hash of every commit it rewrites.

Can you amend a commit you already pushed?

Yes, but only by rewriting the branch on the remote. Changing a commit message creates a new commit ID, and if the commit has already been pushed you must force push the rewritten history:

git commit --amend
git push --force-with-lease origin your-branch

Use --force-with-lease for this push. Force pushing can disrupt collaborators who have based work on the old commits.

• An amend is a very small rebase, so do not amend your last commit if you have already pushed it.
• Avoid amending a commit that other developers have based their work on, because recovering is confusing and complicated.
• GitHub warns that if a commit message included sensitive information, force pushing an amended commit might not remove the original commit from GitHub, and you have to contact GitHub Support with the old commit ID.

On a shared branch, the safer fix is a new commit. For a commit whose changes were wrong, git revert adds a commit that undoes it and leaves the history as it was. For a forgotten file, commit it as a separate commit.

How to undo git commit –amend

The commit you amended is still in your reflog. The previous commit is stored in Git’s reflog. Recover it by finding that commit in git reflog and resetting the branch to it:

git reflog
git reset --hard <hash-before-the-amend>

--hard moves the branch back and discards the amended changes. Alternatively, git reset --soft keeps the changes staged, so git reset --soft <hash-before-the-amend> moves the branch back and lets you commit the amended changes as a separate commit. The git reset guide covers the 3 modes in detail. The reflog is local and its entries expire, so undo an amend soon, from the same clone.

Amending a published feature flag version

Treat pushed work as final unless you have good reason to change it. The same rule applies to production configuration. When a feature flag change has already reached users, the record of what was published is evidence for every incident review after it, and rewriting that record removes what those reviews read.

A published Loglune flag version is immutable, so there is no amend for it. Every flag edit is appended to the history as a change event, and every publish creates an immutable version with the next number in a sequence that publishing alone advances. The history is an append-only hash chain, and Loglune rejects rewrites and deletions of it. A version can carry a label of 1 to 200 characters and a ticket ID, written in the same insert as the version.

Immutable versions give a flag the 2 fixes that Git recommends for pushed commits, without the force push.

Fix in Git	Loglune
git commit --amend to fix the message	Add a note of 1 to 200 characters to the published version, with the actor and the time. The label, the contents, and the evaluations of that version stay as published
A new commit for a forgotten change	Publish the change as a new version
git revert to undo a change	Roll back to version N, which publishes a new version with the contents of N

What the output looks like

We ran the shipped control route on a local test database on October 6, 2026, with editorial example flags. The run created checkout-v2 with default off and published version 1, then switched it to on and published version 2 with a typo in the label: chekout-v2 on for everyone.

A Git user would amend the message. In Loglune, the run added 2 notes to version 2 instead. The first corrects the label. The second records, with the ticket ID SUP-201, that version 2 also needed the new-payment-form flag.

{
  "version": 2,
  "note": {
    "noteId": "4bab59b2-c7ee-4d00-b830-a533dd221569",
    "actor": "dev@example.com",
    "at": "2026-10-06T09:00:05.000Z",
    "note": "Correction: the label should read checkout-v2 on for everyone"
  }
}

Reading version 2 afterward returned the original label next to both notes, oldest first, and the same contents and publishedAt as when it was published:

{
  "view": {
    "tenantId": "tenant-amend-demo",
    "version": 2,
    "publishedAt": "2026-10-06T09:00:04.000Z",
    "flags": [
      {
        "key": "checkout-v2",
        "kind": "bool",
        "defaultVariationId": "on",
        "defaultValue": true,
        "variationCount": 2,
        "ruleCount": 0
      }
    ],
    "segmentKeys": [],
    "configValues": []
  },
  "label": "chekout-v2 on for everyone",
  "reportId": null,
  "notes": [
    {
      "noteId": "4bab59b2-c7ee-4d00-b830-a533dd221569",
      "actor": "dev@example.com",
      "at": "2026-10-06T09:00:05.000Z",
      "note": "Correction: the label should read checkout-v2 on for everyone"
    },
    {
      "noteId": "57ed3b23-09ca-4af0-aea1-fa2fccb8eb02",
      "actor": "dev@example.com",
      "at": "2026-10-06T09:00:06.000Z",
      "note": "Also needed new-payment-form on; shipped in v3",
      "reportId": "SUP-201"
    }
  ]
}

The forgotten change shipped the way a separate commit would. The run created new-payment-form with default on and published version 3 with the label add new-payment-form, missing from v2 and the ticket ID SUP-201. A diff between version 2 and version 3 listed one change, "key": "new-payment-form" with "change": "added", and empty segments and configValues.

Version	publishedAt	Label	Flags	Notes added later
1	2026-10-06T09:00:02.000Z	checkout-v2 created, off	checkout-v2 off	none
2	2026-10-06T09:00:04.000Z	chekout-v2 on for everyone	checkout-v2 on	2
3	2026-10-06T09:00:09.000Z	add new-payment-form, missing from v2	checkout-v2 on, new-payment-form on	none

A note of 201 characters returned status 400 with "path": "note" and "message": "Too big: expected string to have <=200 characters", and version 2 still had its 2 notes afterward.

Choosing the fix

Use git commit --amend for the last commit while it is only in your clone: -m for the message, --no-edit after staging a forgotten file, and --reset-author for the author. Use git rebase -i with reword or edit for older local commits, and a new commit or git revert once the commit is shared. When the thing already published is a feature flag version, Loglune keeps that version as it was, appends a note with the actor and the time, and ships the missing change as a new version, so every incident review reads the same history. To tell users what changed in each version, write release notes.