Identifier un commit local ou déjà partagé
git commit --amend ne modifie pas le dernier commit. Il construit un nouveau commit à partir de l’ancien, en y ajoutant ce qui est indexé et le message que vous donnez, puis déplace votre branche dessus. L’ancien commit est remplacé, donc son identifiant change, et la question qui compte est de savoir si quelqu’un d’autre possède déjà l’ancien. Un amend s’appuie sur l’index comme tout commit : le guide de git add et du staging couvre la préparation.
Les exemples utilisent orbit-api, avec un dépôt distant nommé origin qui contient déjà le premier commit. Vous venez de commiter un correctif, avec une faute dans le message, et vous ne l’avez pas poussé. Demandez l’état de la branche et le journal :
git status -sb
git log --oneline -2
## main...origin/main [ahead 1]
d395755 Hide archived projcts from search
f96f13a Add project search
[ahead 1] signifie que votre branche porte un commit que origin/main n’a pas : il n’a donc pas été poussé, et un amend est sans danger. Si la première ligne était seulement ## main...origin/main, sans crochets, le commit serait déjà sur le dépôt distant. La dernière section traite ce cas. Les sorties sont celles de Git 2.23, en anglais ; Git 2.30 affiche le même texte, et Git 2.54 ne diffère que par la formulation d’un message d’aide, signalée dans la dernière section.
GitMini vérifie cela pour vous. Cochez Amend the last commit sous les champs du message : si le dernier commit est déjà sur la branche amont, un avertissement apparaît : « This commit is already on origin/main. Amending rewrites history and requires a force push. » Il ne bloque pas l’amend. Les libellés de l’interface restent en anglais.
Corriger uniquement le message
Passez le message corrigé avec -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(-)
Sans -m, Git ouvre votre éditeur avec le message précédent chargé. Rien n’était indexé ici : le contenu du commit est donc inchangé, seul le message diffère, et l’identifiant est passé de d395755 à 3735e86. Vos identifiants et vos dates seront différents de ceux de ce guide.
Dans GitMini, cochez Amend the last commit. Quand les champs de résumé et de description sont vides, GitMini les remplit avec le message du dernier commit. Modifiez le résumé et cliquez sur Amend, le libellé qui remplace celui du bouton de commit habituel. Une notification le confirme avec Amended commit: "<votre résumé>". L’amend fonctionne sans rien d’indexé.
Ajouter un changement oublié
Imaginons que vous ayez oublié de documenter le changement dans README.md. Modifiez le fichier, indexez-le, et faites l’amend sans toucher au 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 conserve le message existant et évite l’éditeur. Le commit contient maintenant les deux fichiers. Seul ce qui est indexé rejoint le commit, et les changements non indexés restent dans votre répertoire de travail. Regardez d’abord ce que vous ajoutez avec git diff --cached : le guide de git diff --staged explique comment le lire.
Dans GitMini, indexez le fichier avec Stage, laissez Amend the last commit coché, et cliquez sur Amend. Les fichiers indexés rejoignent le commit remplacé.
Vérifier le nouvel identifiant et le contenu
Le journal montre toujours un seul commit au-dessus de f96f13a, mais avec un nouvel identifiant, et git show --stat liste les deux fichiers :
git log --oneline -2
git show --stat --oneline HEAD
11fce87 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(-)
Le reflog liste les positions précédentes de HEAD : il montre donc le remplacement lui-même.
git reflog -4
11fce87 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 search
Chaque amend a créé un nouveau commit et déplacé la branche dessus. Les commits précédents ont été remplacés, pas modifiés. Après un amend, GitMini sélectionne le nouveau commit dans le graphe, et le panneau de droite affiche son SHA complet et sa liste de fichiers modifiés.
Si le commit a déjà été poussé
Supposons que vous ayez poussé 11fce87, puis que vous modifiiez encore son message :
git push
git commit --amend -m "Hide archived projects from search"
git status -sb
To ../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] signifie que la branche a divergé : votre nouveau commit et l’ancien, que le dépôt distant détient toujours, sont deux commits différents. Un git push ordinaire est refusé :
git push
To ../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 et 2.30 affichent ces messages d’aide. Git 2.54 reformule les deux du milieu en hint: its remote counterpart. If you want to integrate the remote changes, suivi de hint: use 'git pull' before pushing again. Le refus, lui, est identique.
Seul un push forcé remplace le commit distant :
git push --force-with-lease
To ../origin.git
+ 11fce87...afe5af4 main -> main (forced update)
Pro Git est catégorique : ne modifiez pas un commit que vous avez déjà poussé, car l’amend change son identifiant. Si vous le faites quand même, préférez --force-with-lease à --force : Git n’écrase la branche distante que si elle contient toujours le commit que vous avez vu en dernier, ce qui évite d’effacer le travail plus récent de quelqu’un d’autre.
Dans GitMini, le bouton Push de la barre d’outils couvre ce cas. Quand la branche est à la fois en avance et en retard sur son amont, comme ici, GitMini ne tente pas un push ordinaire. Il ouvre une confirmation Forced Push : « Rewrite origin/main? 1 commit present on the server will be replaced. If you have not rewritten the branch, cancel and make a Pull. » Le focus initial est sur Cancel. Le bouton Force push pousse avec --force-with-lease et --force-if-includes, un second contrôle qui rejette la mise à jour forcée si le sommet distant n’a jamais été intégré localement. Si vous n’avez pas réécrit la branche vous-même, annulez et faites plutôt un pull.
Pour retravailler plusieurs commits locaux avant de les partager, utilisez un rebase interactif plutôt que des amends répétés.
Sources
- Pro Git : Rewriting History (en anglais), consulté le 4 octobre 2026.
- Documentation Git : git-push (en anglais), consulté le 4 octobre 2026.
- README du produit GitMini, consulté le 4 octobre 2026.