Identify whether the commit was shared
git commit --amend does not edit the last commit. It builds a new commit from the old one, plus whatever is staged and the message you give, then moves your branch to it. The old commit is replaced, so its ID changes, and the question that matters is whether somebody else already has the old one. Amending uses the index like any commit, so the guide to git add and staging covers the preparation.
The examples use orbit-api, with a remote named origin that already has the first commit. You just committed a fix, with a typo in the message, and you have not pushed it. Ask for the branch status and the log:
git status -sb
git log --oneline -2## main...origin/main [ahead 1]
d395755 Hide archived projcts from search
f96f13a Add project search[ahead 1] means your branch holds one commit that origin/main lacks, so it has not been pushed and amending is safe. If the first line were only ## main...origin/main, with no bracket, the commit would already be on the remote. The last section covers that case. The outputs come from Git 2.23; Git 2.30 prints the same text, and Git 2.54 differs only in the wording of one hint, noted in the last section.
GitMini checks it for you. Tick Amend the last commit under the message fields: if the last commit is already on the upstream branch, a warning appears: “This commit is already on origin/main. Amending rewrites history and requires a force push.” It does not block the amend.
Change only the message
Pass the corrected message with -m:
git commit --amend -m "Hide archived projects from search results"[main 3735e86] Hide archived projects from search results
Date: Sun Oct 4 09:00:00 2026 +0200
1 file changed, 3 insertions(+), 1 deletion(-)Without -m, Git opens your editor with the previous message loaded. Nothing was staged here, so the content of the commit is unchanged: only the message differs, and the ID went from d395755 to 3735e86. Your identifiers and dates will differ from the ones in this guide.
In GitMini, tick Amend the last commit. When the summary and description fields are empty, GitMini fills them with the message of the last commit. Edit the summary and click Amend, the label that replaces the usual commit button. A toast confirms it with Amended commit: "<your summary>". The amend works with nothing staged.
Add a missing change
Now suppose you forgot to document the change in README.md. Edit the file, stage it, and amend without touching the message:
git add README.md
git commit --amend --no-edit[main 11fce87] Hide archived projects from search results
Date: Sun Oct 4 09:00:00 2026 +0200
2 files changed, 5 insertions(+), 1 deletion(-)--no-edit keeps the existing message and skips the editor. The commit now holds both files. Only what is staged joins the commit, and changes you did not stage stay in your working tree. Look at what you are adding with git diff --cached first: the guide to git diff --staged explains how to read it.
In GitMini, stage the file with Stage, keep Amend the last commit ticked, and click Amend. The staged files join the replaced commit.
Verify the new commit ID and contents
The log still shows one commit on top of f96f13a, but with a new ID, and git show --stat lists both files:
git log --oneline -2
git show --stat --oneline HEAD11fce87 Hide archived projects from search results
f96f13a Add project search
11fce87 Hide archived projects from search results
README.md | 2 ++
src/search.ts | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)The reflog lists the previous positions of HEAD, so it shows the replacement itself:
git reflog -411fce87 HEAD@{0}: commit (amend): Hide archived projects from search results
3735e86 HEAD@{1}: commit (amend): Hide archived projects from search results
d395755 HEAD@{2}: commit: Hide archived projcts from search
f96f13a HEAD@{3}: commit (initial): Add project searchEach amend created a new commit and moved the branch to it. The earlier commits were replaced, not edited. After an amend, GitMini selects the new commit in the graph, and the panel on the right shows its full SHA and its list of modified files.
If the commit was already pushed
Suppose you pushed 11fce87, then amend its message again:
git push
git commit --amend -m "Hide archived projects from search"
git status -sbTo ../origin.git
f96f13a..11fce87 main -> main
[main afe5af4] Hide archived projects from search
Date: Sun Oct 4 09:00:00 2026 +0200
2 files changed, 5 insertions(+), 1 deletion(-)
## main...origin/main [ahead 1, behind 1][ahead 1, behind 1] means the branch has diverged: your new commit and the old one that the remote still holds are two different commits. A plain push is refused:
git pushTo ../origin.git
! [rejected] main -> main (non-fast-forward)
error: failed to push some refs to '../origin.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.Git 2.23 and 2.30 print these hints. Git 2.54 rewords the two middle ones as hint: its remote counterpart. If you want to integrate the remote changes, followed by hint: use 'git pull' before pushing again. The rejection itself is the same.
Only a force push replaces the remote commit:
git push --force-with-leaseTo ../origin.git
+ 11fce87...afe5af4 main -> main (forced update)Pro Git is blunt about this: don’t amend a commit you have already pushed, because amending changes its ID. If you do it anyway, prefer --force-with-lease to --force: it overwrites the remote branch only if the remote still holds the commit you last saw, so you do not erase somebody else’s newer work.
In GitMini, the Push button in the toolbar covers this case. When the branch is both ahead of and behind its upstream, as here, GitMini does not attempt a plain push. It opens a Forced Push confirmation: “Rewrite origin/main? 1 commit present on the server will be replaced. If you have not rewritten the branch, cancel and make a Pull.” Cancel has the initial focus. The Force push button pushes with --force-with-lease and --force-if-includes, a second check that rejects the forced update if the remote tip was never integrated locally. If you did not rewrite the branch yourself, cancel and pull instead.
To rework several local commits before sharing them, use an interactive rebase instead of repeated amends.
Sources
- Pro Git: Rewriting History, consulted on October 4, 2026.
- Git documentation: git-push, consulted on October 4, 2026.
- GitMini product README, consulted on October 4, 2026.