TortoiseGit Amend Last Commit: Fixing a Forgotten File Before Push

You committed, closed the dialog, and immediately noticed a file you meant to include is still unstaged. With a local commit that has not left your machine, TortoiseGit's Amend last commit checkbox lets you fold that change into the previous commit instead of creating a new fix-up commit. The useful takeaway is that amend is a local history rewrite, not an edit.

The problem amend solves on Windows

TortoiseGit is a Windows shell extension that surfaces Git operations through Explorer context menus. The commit dialog is the usual place to stage files, write a message, and create a commit. When you realize after clicking OK that a file was left out, or the message needs a tweak, creating a second commit pollutes history. Amend replaces the previous HEAD commit with a new commit that has the same parent but updated content and message.

HEAD is the pointer to the current commit on your branch. Amend does not edit the old commit, it creates a new commit object with a new hash and moves HEAD to it. Because the hash changes, any remote that already has the old hash will see a divergence.

What the checkbox actually does

In the TortoiseGit Commit dialog, the Amend last commit checkbox enables Git's amend behavior. When enabled, TortoiseGit runs an equivalent of git commit --amend with the currently staged changes.

The dialog pre-fills the commit message from the previous commit, which saves retyping and makes it clear you are rewriting, not starting fresh. The underlying rewrite updates the commit identity as configured in your Git settings. No additional flags are exposed in the GUI, so the operation is limited to the staged index and the previous commit.

When it is safe and when it is not

Safe use is strictly local. If the commit has not been pushed to a shared remote and no teammate has pulled it, rewriting is invisible to others. This is the normal case for a quick fix right after a local commit.

Risk starts once the commit is public. Amending a commit already pushed requires a force push to overwrite the remote history. That can invalidate teammates' local history and cause merge conflicts on their next pull. Avoid amend on public branches.

There is also a signature caveat. If commits are signed with GPG and commit.gpgsign is enabled, amending creates a new commit object. Depending on configuration, the signature may need to be reapplied and will change.

Worked example in Explorer

Assume you have Git for Windows installed and TortoiseGit is active in Windows Explorer for C:\projects\myapp.

1. Right-click the repository folder and choose TortoiseGit → Commit.
2. Stage the forgotten file in the left pane so it appears under Changed.
3. Check Amend last commit. The message box is pre-filled from the previous commit.
4. Adjust the message if needed and click OK.

To verify the rewrite locally, open Git Bash or Command Prompt in the repository root and run:

git log --oneline -2

Expected check: the top two lines should show one fewer commit than before the amend if you previously had a new commit, or the same number of commits with the top commit message updated. Running git show --stat HEAD before and after should show the file set changed while the commit count stays at one.

Required permissions are read/write to the working tree and .git folder. Risk is history rewrite. Do not push with force unless you have confirmed the commit is unshared.

Limitations to keep in mind

TortoiseGit is Windows-only, so this workflow does not transfer to Linux or macOS without a different GUI. Amend only affects the last commit; it cannot rewrite multiple commits from the dialog. If you need a broader rewrite, use Git's interactive rebase from the command line.

As an actionable rule, use Amend last commit only for immediate local corrections before the first push. Once pushed, prefer a new clarifying commit. That keeps shared history stable and avoids coordination overhead.