Comment modifier le dernier commit dans Git (message, fichiers, auteur et annulation)

Pour corriger le commit le plus récent sur votre branche actuelle, exécutez git commit --amend. Si rien n'est préparé, Git remplace le commit par votre message mis à jour ; si vous effectuez d'abord de nouvelles modifications, Git intègre ces modifications dans la validation et vous permet de conserver le message existant avec --no-edit ou de le réécrire en place. Vous préférez un flux de travail visuel ? Dans GitTree sur macOS, Windows et Linux, activez Modifier la validation précédente dans le panneau de validation (ou cliquez avec le bouton droit sur la validation supérieure du graphique et choisissez Modifier le message de validation…) pour pré-remplir le message, transférer ou annuler la validation de lignes individuelles, afficher un avertissement de branche distante avant de réécrire l'historique poussé et récupérer à tout moment en un seul clic Annuler.

Référence rapide : chaque commande git commit --amend

Choisissez la commande exacte qui correspond à ce qui ne va pas avec votre dernier commit ou passez à la section détaillée ci-dessous pour les cas extrêmes, les hooks, les commits signés et les alternatives visuelles.

Ce que git commit --amend fait réellement sous le capot

Chaque hachage de validation Git est une somme de contrôle cryptographique (SHA-1 ou SHA-256) calculée à partir de cinq éléments de données : l'instantané de l'arbre racine, le(s) hachage(s) de validation parent, le nom/l'e-mail/l'horodatage de l'auteur, le nom/l'e-mail/l'horodatage du commissaire et le message de validation. Modifiez ne serait-ce qu'un seul caractère dans le message (ou l'horodatage du committer une seconde plus tard) et le hachage résultant est complètement différent.

# Before git commit --amend:
A --- B --- C  <-- main (HEAD)

# After git commit --amend:
A --- B --- C' <-- main (HEAD)
       \
        C      (still in git reflog as HEAD@{1} until garbage collection)

Lorsque vous exécutez git commit --amend, Git prend tout ce qui se trouve actuellement dans la zone de transit (l'index), le combine avec le(s) pointeur(s) parent(s) de C (B), écrit un nouvel objet de validation C' et met à jour votre référence de branche actuelle pour pointer vers C'. Le commit d'origine C n'est pas supprimé immédiatement : il reste enregistré dans votre reflog local (HEAD@{1}) pendant au moins 30 à 90 jours (gc.reflogExpireUnreachable), c'est pourquoi une modification accidentelle est toujours récupérable localement, soit via git reflog, soit via les outils Annuler et Rétablir et Lost & Found de GitTree.

1. Modifiez le dernier message de validation

Si vous venez de commettre et avez immédiatement remarqué une faute de frappe, un mauvais numéro de problème Jira/GitHub ou un préfixe Conventional Commits manquant (feat:, fix:, chore:), vérifiez d'abord git status pour savoir si quelque chose est indexé.

Passez un nouveau message d'une ligne ou de plusieurs paragraphes avec -m

Pour remplacer le message directement depuis le terminal sans lancer d'éditeur, passez -m. Vous pouvez enchaîner plusieurs indicateurs -m pour créer une ligne d'objet et des paragraphes de corps :

# Replace the commit subject inline
git commit --amend -m "fix(auth): validate refresh token expiry before rotation"

# Replace both the subject line and body paragraph
git commit --amend \
  -m "fix(auth): validate refresh token expiry before rotation" \
  -m "Prevents expired tokens from issuing a new session when clock skew exceeds 30s."

Modifiez le message existant dans votre éditeur de texte

Lorsque votre commit contient déjà une description détaillée sur plusieurs lignes, des bandes-annonces (Co-authored-by:, Signed-off-by:) ou des références de problème que vous ne souhaitez pas retaper, exécutez git commit --amend sans -m :

git commit --amend

Git ouvre votre core.editor configuré (Vim, Nano, VS Code, Zed, etc.) avec le message de validation actuel préchargé. Enregistrez et fermez le fichier pour écrire le commit modifié. Si vous changez d'avis pendant que l'éditeur est ouvert, supprimez l'intégralité du message de validation (en laissant le fichier vide) et enregistrez : Git abandonne la modification avec Aborting commit due to empty commit message et laisse HEAD intact.

2. Ajoutez des fichiers oubliés ou des lignes spécifiques au dernier commit

Oublier d'enregistrer un fichier, d'effectuer un test ou d'exécuter votre formateur avant de valider est la raison la plus courante pour laquelle les développeurs recherchent --amend. Effectuez d'abord les modifications manquantes, puis modifiez-les avec --no-edit afin que Git conserve le message de validation existant sans ouvrir d'éditeur :

# Stage the forgotten file (or files)
git add src/auth/token-validator.test.ts

# Fold the staged file into the last commit and keep the existing message
git commit --amend --no-edit

Indexez uniquement des lignes ou des morceaux spécifiques avant de les modifier

Que se passe-t-il si votre arborescence de travail contient à la fois le correctif de 3 lignes qui appartient au commit précédent *et* 40 lignes de journalisation de débogage ou de travail pour votre prochaine fonctionnalité ? N'exécutez pas git add . ou git commit -a --amend. Au lieu de cela, indexez uniquement les morceaux ou les lignes exacts qui appartiennent au commit précédent en utilisant le mode patch (couvert en détail dans notre guide sur git add -p et la indexation de lignes spécifiques) :

# Choose y/n/s (split) for each changed hunk
git add -p src/auth/token-validator.ts

# Verify what is staged vs what stays in the working tree
git diff --staged

# Amend the last commit with only the staged hunks
git commit --amend --no-edit

Dans GitTree, vous n'avez jamais à vous battre avec le fractionnement des morceaux de terminal (s, e) pour ce faire : cliquez sur n'importe quel fichier dans Modifications non indexées, sélectionnez les lignes exactes ou cliquez sur Stage Hunk dans la comparaison côte à côte ou en ligne, et activez Modifier la validation précédente. Consultez notre Guide des différences Git pour voir comment l'inspection des différences préparées et non préparées empêche le code accidentel de se glisser dans une validation modifiée.

3. Supprimez un fichier validé par erreur (sans le supprimer du disque)

Supposons que vous ayez exécuté git add . et que vous ayez accidentellement validé un fichier .env.local, un artefact de build volumineux ou un fichier appartenant à une demande d'extraction distincte. La façon dont vous le supprimez de HEAD dépend du fait que le fichier existait dans le commit avant HEAD (HEAD~1) ou qu'il a été récemment ajouté dans HEAD.

Cas A : Supprimer un fichier nouvellement ajouté du dernier commit (conserver le fichier local)

Utilisez git rm --cached pour supprimer le fichier de l'index intermédiaire tout en laissant le fichier physique sur votre disque, puis modifiez :

# Remove the file from the index only (leaves the file on disk)
git rm --cached .env.local

# Optional: add it to .gitignore so it never gets staged again
echo ".env.local" >> .gitignore
git add .gitignore

# Rewrite the last commit without .env.local
git commit --amend --no-edit

Cas B : rétablir les modifications vers un fichier suivi lors de la dernière validation (conserver les modifications locales)

Si <file> a déjà été suivi dans HEAD~1 et que vous y avez accidentellement inclus des modifications dans HEAD, n'utilisez pas git rm --cached (cela enregistrerait une suppression de fichier dans HEAD !). Au lieu de cela, restaurez l'entrée d'index de ce fichier à partir de HEAD~1 :

# Reset only the staged index state of <file> back to HEAD~1
git restore --source=HEAD~1 --staged src/config/database.ts

# Amend HEAD: the commit no longer touches database.ts, and your local edits stay in the working tree
git commit --amend --no-edit

Si vous souhaitez plutôt supprimer les modifications locales indésirables ou nettoyer complètement les fichiers non suivis, consultez comment ignorer les modifications et nettoyer les fichiers non suivis dans Git et comment restaurer un fichier supprimé dans Git.

4. Modifiez l'auteur, l'e-mail ou l'horodatage du dernier commit

Lorsque vous effectuez une validation sur un nouvel ordinateur portable avant de définir user.email, ou lorsque vous effectuez une validation dans un référentiel de travail alors que votre adresse e-mail personnelle GitHub est configurée globalement, la validation enregistre la mauvaise identité. git commit --amend peut réécrire les métadonnées du commit sans toucher à un seul fichier.

# Option 1: Set an explicit author name and email on the last commit
git commit --amend --author="Jane Doe <jane@company.com>" --no-edit

# Option 2: Update git config first, then reset the commit author to match
git config user.name "Jane Doe"
git config user.email "jane@company.com"
git commit --amend --reset-author --no-edit

# Option 3: Amend the author date as well
git commit --amend --date="2026-11-11T14:30:00+02:00" --no-edit

5. Comment modifier en toute sécurité un commit que vous avez déjà poussé

Dès que vous modifiez un commit qui a déjà été poussé vers origin, votre branche locale et la branche de suivi à distance (origin/<branch>) divergent : votre branche locale a C', tandis que origin a toujours C. Les deux commits partagent le parent B.

Si la branche est votre propre branche de fonctionnalité ou de demande d'extraction, mettez à jour le dépôt distant en toute sécurité avec --force-with-lease (et --force-if-includes dans Git 2.30+) :

# Safely replace the remote branch tip with your amended commit
git push --force-with-lease --force-if-includes origin HEAD

• Pourquoi `--force-with-lease` au lieu de `--force` : Simple git push --force écrase aveuglément la branche distante, effaçant tous les commits poussés par un coéquipier ou un bot CI depuis votre dernière récupération. --force-with-lease vérifie que origin/<branch> pointe toujours vers le commit SHA exact stocké dans votre référence locale de suivi à distance ; si quelqu'un d'autre a poussé entre-temps, Git rejette la poussée au lieu de perdre son travail.
• Ce que `--force-if-includes` ajoute : Si la récupération automatique en arrière-plan est activée, votre référence de suivi à distance peut être mise à jour avant votre envoi. --force-if-includes vérifie que le commit à la pointe de la branche distante a bien été intégré à votre reflog local avant d'autoriser la réécriture.
• Lorsque vous êtes sur `main` ou sur une branche partagée : Ne pas modifier et forcer le push d'une branche partagée sur laquelle d'autres développeurs basent leur travail. Au lieu de cela, laissez le commit intact et envoyez un nouveau commit de correctif, ou inversez-le proprement avec git revert (voir notre guide pour annuler les commits et les fusions et le Tutoriel de récupération des erreurs poussées).
• Besoin de configurer d'abord votre branche de suivi ? Voir comment définir une branche en amont dans Git.

6. Que se passe-t-il si le commit que vous devez modifier n'est PAS le dernier commit ?

git commit --amend ne réécrit que HEAD (le commit de pointe). Lorsque la faute de frappe ou la modification manquante appartient à HEAD~2 ou à trois commits en arrière, vous disposez de deux options propres, sans cacher ni sélectionner manuellement :

Option 1 : autosquash CLI rapide avec git commit --fixup

Préparez le correctif, créez un commit --fixup ciblant le SHA de l'ancien commit (ou --fixup=amend:<sha> pour modifier également son message) et exécutez git rebase -i --autosquash :

# 1. Stage the changes meant for the older commit (e.g. a1b2c3d)
git add src/api/client.ts

# 2. Create a fixup commit targeting a1b2c3d
git commit --fixup=a1b2c3d

# 3. Autosquash the fixup commit straight into a1b2c3d
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash a1b2c3d~1

Option 2 : rebasement visuel interactif dans GitTree

Au lieu de copier les SHA et de modifier les fichiers de tâches de rebase dans le terminal, lisez notre guide GUI de rebase interactif complet et notre guide de rebase de branche. Dans le planificateur Interactive Rebase et Reword, Squash and Drop de GitTree, cliquez avec le bouton droit sur n'importe quelle validation plus ancienne dans le graphique, choisissez Interactive Rebase from Here…, basculez cette validation vers Reword ou faites-y glisser une validation de correctif vers Fixup/Squash, et appliquez-la en un seul clic.

7. Comment annuler un git commit accidentel --amend

Avez-vous exécuté git commit --amend alors que des fichiers involontaires étaient transférés, ou avez-vous accidentellement écrasé un message de validation dont vous aviez besoin ? Étant donné que Git enregistre chaque mouvement de HEAD dans le reflog local, votre commit de pré-modification est toujours en sécurité à HEAD@{1}.

# 1. Inspect the reflog to see the amend and the commit before it
git reflog -n 5
# e9f8d7c (HEAD -> feature) HEAD@{0}: commit (amend): feat: add billing webhook
# 4a3b2c1 HEAD@{1}: commit: feat: add billing webhook

# 2. Restore the branch to the pre-amend commit and keep any extra changes staged
git reset --soft HEAD@{1}

L'utilisation de git reset --soft HEAD@{1} replace votre pointeur de branche sur le commit d'origine (4a3b2c1) et laisse la différence entre le commit modifié et le commit d'origine effectué dans votre index : rien dans votre arbre de travail n'est perdu. Pour une analyse approfondie des réinitialisations et de la récupération de reflog de soft, mixed et hard, lisez Git reset --soft vs --mixed vs --hard, comment annuler la réinitialisation, le rebase ou le commit de git avec reflog et comment récupérer les caches abandonnés et les commits en suspens.

Quand utiliser git commit --amend vs reset, revert ou rebase -i

Utilisez cette matrice de décision chaque fois que vous avez besoin de corriger l'historique afin de choisir la commande qui correspond à la position de votre commit et si vos coéquipiers l'ont exécutée :

Comment GitTree élimine toutes les erreurs courantes de git commit --amend

La plupart des accidents de modification de ligne de commande se produisent parce que le terminal cache trois éléments de contexte critiques jusqu'à ce qu'il soit trop tard : ce qui se trouve déjà dans votre zone de transit, si HEAD a déjà été poussé vers origin et quel était le SHA de validation précédent avant que vous ne l'écrasiez. GitTree résout chacun de ces modes de défaillance directement dans l'interface :

• Inspection des différences en direct et sans indexées : Avant de cliquer sur Modifier la validation, la liste Modifications par étapes se trouve directement au-dessus de la zone de validation afin que vous ne puissiez jamais plier accidentellement des fichiers à moitié terminés dans HEAD. Vous pouvez indexer ou annuler la indexation de lignes, de morceaux ou de fichiers individuels en un seul clic (Stage Files, Hunks and Lines).
• Détection de validation poussée et protection contre la transmission forcée avec bail : Lorsque HEAD est déjà sur la branche distante, GitTree vous avertit directement dans le panneau de validation *avant* de modifier et associe le flux de travail avec Forcer la poussée (avec bail)… afin de ne jamais écraser la poussée d'un coéquipier.
• Reformulation par clic droit et création rapide `fixup!`/`amend!` : Vous souhaitez reformuler HEAD sans toucher à vos fichiers préparés ? Cliquez avec le bouton droit sur le premier commit dans le graphique de commit et choisissez Modifier le message de commit…. Besoin de corriger un ancien commit ? Cliquez avec le bouton droit sur cet ancien commit dans le graphique pour créer un commit fixup! ou amend! ou ouvrez Interactive Rebase.
• Instantanés de sécurité automatiques (`refs/ogt/trash`) et annulation en un clic : Avant d'exécuter l'une des 19 opérations de modification de l'historique, y compris Modification d'un commit, rebase interactif, réinitialisation, suppression de branche et suppression, GitTree enregistre un instantané local sous refs/ogt/trash. En cliquant sur Annuler (Cmd+Z/Ctrl+Z), vous restaurez immédiatement votre état exact de validation et de pré-modification.
• Visuel Lost & Found & Built-in Terminal : Même si vous avez modifié à partir du terminal intégré ou il y a des semaines, Lost & Found fait apparaître des commits inaccessibles et remplacés avec leurs différences complètes afin que vous puissiez les restaurer, les sélectionner ou les créer sans analyser la sortie brute git reflog.
• Git Hooks, Secret Warnings & AI Commit Messages : GitTree exécute les pre-commit et commit-msg Git hooks de votre référentiel, vérifie les différences par étapes pour les clés API accidentelles et (dans GitTree Pro) permet à Nour de générer des messages de validation précis à l'aide de votre propre agent de codage local.