Git amend : corriger le dernier commit

Exemple et conditions

L’exemple est un commit local ordinaire avec un message erroné et une modification oubliée dans src/parser.js. Ce sont deux réparations : message seul ou contenu aussi. Ce n’est pas un commit ancien, initial ou merge. Adaptez chemin et message et partez de la pointe actuelle.

Examiner avant de modifier

Lisez status, dernier commit et diff --cached. L’index fournit le contenu d’un amend ordinaire : des fichiers préparés pour une autre tâche peuvent s’y glisser. Examinez aussi le non indexé. Vérifiez si l’original a été publié, intégré ou utilisé par des collègues avant de changer son identité.

git status --short
git log -1 --oneline
git diff --cached
git diff

Garder une référence ou un checkout séparé

Créez rescue/before-amend sur HEAD pour garder l’objet original et le comparer. Cela ne sauvegarde pas tous les fichiers locaux : conservez séparément ceux qui comptent. Reflog peut retrouver des états encore retenus localement, sans garantir des objets permanents ni sauvegarder des modifications jamais commitées.

git branch rescue/before-amend HEAD

Premier parcours

Pour le message seul, --amend --only sans chemins exclut les modifications déjà indexées. -m fournit le message corrigé. Examinez ensuite commit et index : le travail indexé doit rester disponible pour un commit distinct. Inclure aussi l’index est l’autre parcours, même si les deux commandes utilisent --amend.

git commit --amend --only -m "Fix parser error message"
git diff --cached

Choisir l’autre résultat consciemment

Pour le fichier oublié, indexez le chemin voulu, vérifiez tout le diff indexé et utilisez --amend --no-edit pour garder le message. Les autres fichiers indexés entrent aussi sauf exclusion délibérée. Effectuez les contrôles du projet. Choisir des hunks précis aide la revue sans prouver la justesse du commit combiné.

git add -- src/parser.js
git diff --cached
git commit --amend --no-edit

Limites et exceptions

Si la pointe a été partagée, préférez un nouveau commit correctif. Publier une pointe réécrite peut exiger une coordination et être interdit sur une branche protégée. Pas de force push générique ici. Si l’équipe autorise la réécriture, suivez son processus distinct de lease, branche et vérifications avec les collaborateurs.

git add -- src/parser.js
git diff --cached
git commit -m "Correct parser handling"

Conflits et nettoyage

Amend n’a généralement pas de séquence propre de conflits. Un hook échoué ou un commit refusé demande l’examen du message et de l’état, pas un reset --hard automatique. Si le contenu est incorrect, comparez d’abord rescue/before-amend. Conservez des copies vérifiées des fichiers locaux avant un reset correctif.

Vérifier le résultat

Comparez fichiers et message des deux commits. Des identifiants différents sont normaux. Pour le message seul, leurs arbres doivent correspondre ; pour le contenu, seul le patch prévu doit changer. Vérifiez le travail indexé restant et gardez le secours jusqu’à l’intégration sûre du remplacement revu.

git show --stat HEAD
git diff rescue/before-amend HEAD
git status --short

Questions fréquentes

No-edit empêche-t-il le contenu de changer ? Non, il garde le message ; l’index peut modifier le contenu. Amend corrige-t-il un ancien commit ? Pas directement : autre parcours requis. Après push ? Seulement avec une politique explicite d’historique partagé ; un commit supplémentaire évite beaucoup de coordination.

Examiner l’opération dans FluxGit

Utilisez l’historique visuel et la vue des modifications de FluxGit pour examiner l’opération et les commits concernés. Gardez les vérifications de branche, de partage et de fichiers locaux de cet exemple. La page de téléchargement présente les builds et plateformes disponibles.

Références officielles Git

• git-commit
• git-diff
• git-reflog