Le Git Amend expliqué : Un guide étape par étape avec des exemples

Techniques avancées d'amendement

Cette section traite des utilisations sophistiquées de git amend et des outils connexes. Ils conviennent aux flux de travail complexes.

Rebase interactif pour les commits historiques

La commande git commit --amend est pratique lorsque vous avez seulement besoin de corriger le commit le plus récent. 

Mais que se passe-t-il si l'erreur est enfouie deux ou trois fois plus loin ? C'est là qu'intervient interactive rebase. Il vous permet d'éditer, de réorganiser, d'écraser ou d'abandonner des livraisons plus anciennes, réécrivant ainsi l'historique avec précision.

Supposons que vous souhaitiez modifier l'un de vos trois derniers engagements. Commencez par lancer une base de données interactive :

git rebase -i HEAD~3

Ceci ouvre un éditeur de texte listant vos trois derniers commits, chacun préfixé par le mot pick, comme ceci :

pick a1b2c3 Commit message 1
pick d4e5f6 Commit message 2
pick 789abc Commit message 3

• Remplacez pick par edit à côté du commit que vous souhaitez réviser.
• Enregistrez et fermez l'éditeur.

Git s'arrêtera au commit sélectionné et vous demandera d'effectuer des modifications.

Effectuez maintenant les modifications nécessaires :

• Modifiez les fichiers si nécessaire.
• Mettez en scène les changements :

git add .

• Modifier l'engagement :

git commit --amend

• Mettez à jour le message de validation si nécessaire, puis enregistrez et fermez l'éditeur. 
• Une fois les modifications terminées, demandez à Git de continuer :

git rebase --continue

Git appliquera les commits restants en plus de votre mise à jour. S'il y a des conflits, résolvez-les avant d'exécuter à nouveau le site git rebase --continue.

Explication : Les commandes ci-dessus réécrivent l'historique des trois dernières modifications, ce qui vous permet d'affiner les entrées plus anciennes.

Note : Le rebasement interactif réécrit les hachages des livraisons. Si la branche a été partagée avec d'autres (par exemple, poussée sur un serveur distant), la réécriture de son historique peut poser des problèmes aux collaborateurs. Ne l'utilisez que sur des branches locales ou privées, ou communiquez avec votre équipe avant de la forcer (git push --force).

Corriger les commits dans les pipelines CI/CD

Dans les pipelines CI/CD, un historique Git propre et concis est plus qu'esthétique : il permet des journaux plus clairs, un débogage plus facile et une automatisation plus prévisible. 

Lorsque vous effectuez des corrections mineures (par exemple, corriger une faute de frappe, mettre à jour une configuration, ou ajuster un test), vous pouvez utiliser fixup commits au lieu de créer des commits autonomes bruyants.

Pour préparer un commit qui fusionnera automatiquement avec un commit précédent lors d'un rebase, exécutez :

git commit --fixup <commit-hash>

Cela crée un commit spécial étiqueté comme correctif pour le commit spécifié, signalant qu'il devrait être combiné lors d'un rebasement interactif.

Conseil: Utilisez git log ou git rebase -i pour trouver la cible si nécessaire.

Pour fusionner proprement le commit de correction avec l'original lors d'un rebase, utilisez l'option --autosquash:

git rebase -i --autosquash HEAD~5

Cela ouvre l'éditeur de rebase, où Git va automatiquement réorganiser et étiqueter les commits de correction pour les écraser.

• Il n'est pas nécessaire de changer manuellement pick en fixup- Git le fait pour vous.
• Il suffit de confirmer le plan de rebasement et d'enregistrer le fichier.

Explication : L'utilisation de fixup commits avec --autosquash vous permet de regrouper les modifications mineures dans le bon commit historique, plutôt que d'encombrer l'historique avec des micro-commits. Cela permet d'obtenir un journal propre et linéaire, qui :

• Simplifie l'audit et le débogage dans les environnements CI/CD
• Réduit le bruit dans les demandes d'extraction et les journaux de fusion
• Permet d'éviter les problèmes de compilation ou de test liés à des livraisons incomplètes ou trompeuses.

> Pour aller au-delà des bases, notre cours Gitcs, notre cours Git intermédiaire explore plus en détail les commandes avancées telles que amend et rebase.

Implications mécaniques de l'amendement

La modification des commits modifie votre historique Git. Cette section examine les effets techniques de la modification des engagements. La compréhension de ces éléments garantit une utilisation sûre.

Invalidation du hachage et immutabilité

Chaque commit Git possède un hash SHA-1 (ou SHA-256 dans les versions plus récentes) unique, calculé à partir de son contenu, de ses métadonnées et du commit parent. La modification crée un nouveau hachage, ce qui rompt l'immutabilité en cas de partage.

Si le commit original a déjà été poussé vers une branche distante partagée, cela crée un décalage entre vos branches locales et distantes. décalage entre votre branche locale et votre branche distante.

Pour diffuser l'historique mis à jour, vous devez forcer la mise à jour :

git push --force

Note : Comme nous l'avons mentionné, --force peut écraser le travail des collaborateurs et semer la confusion. Il est plus sûr de modifier les commits avant de les pousser, ou d'utiliser les poussées forcées uniquement sur les branches privées avec coordination.

Reflog et récupération de données

Même si les commits modifiés sont écrasés, Git ne les supprime pas immédiatement. Git maintient un reflog, qui suit les mises à jour des références de branches (comme HEAD ou origin/main), y compris les modifications ou suppressions de commits.

Vous pouvez le visualiser avec :

git reflog

Vous obtiendrez ainsi la liste des modifications récentes avec les hashs de commit associés.

Pour récupérer un engagement perdu :

 git checkout <old-commit-hash>

Vous pouvez ensuite vous en inspirer, sélectionner les modifications ou inspecter les travaux perdus.

Explication : Reflog agit comme un filet de sécurité, vous permettant de récupérer les commits qui semblent "perdus" après une modification ou un rebasement. C'est pratique lorsqu'un coup de force ou une réécriture de l'histoire tourne mal.

Considérations sur le flux de travail collaboratif

Bien que git commit --amend soit un outil puissant pour nettoyer l'histoire, son utilisation dans des environnements collaboratifs doit être manipulée avec précaution. 

La réécriture de l'histoire publique peut entraîner des confusions, des erreurs, voire des pertes de données si elle n'est pas coordonnée correctement.

Risque de modification des engagements publics

Je le répète, une fois qu'un commit a été poussé dans un dépôt distant partagé, le modifier change son hash et son historique. Cela entraîne des erreurs "non fast-forward" lorsque d'autres personnes essaient de tirer ou de pousser, car leur historique local ne correspond plus à l'historique distant.

Si vous devez modifier un engagement public :

• Prévenez votre équipe pour éviter les conflits.
• Utilisez git push --force-with-lease pour des mises à jour plus sûres.

La commande ci-dessus garantit que vous n'écrasez la branche distante que si elle n'a pas changé depuis votre dernière récupération, minimisant ainsi le risque d'effacer le travail d'autres personnes.

Meilleure pratique : Évitez de modifier les commits partagés, sauf en cas d'absolue nécessité. Préférez créer un nouveau commit ou utiliser revert pour préserver la stabilité de l'équipe.

Politiques de protection des branches

De nombreuses équipes appliquent des règles de protection des branches - en particulier sur main, master, ou les branches de version - afin d'empêcher les poussées de force et les modifications directes. Cela peut bloquer toute poussée de force liée à l'amendement après que le commit a été poussé.

Pour contourner ce problème en toute sécurité :

• Effectuer les modifications avant de pousser.
• Travailler dans branches de fonctionnalités qui ne sont pas protégées.
• Si un correctif est nécessaire dans une branche protégée :
• Créez plutôt un nouveau commit.
• Vous pouvez également demander une dérogation aux administrateurs du dépôt en justifiant votre demande.

> Si vous collaborez via GitHub, le cursus GitHub Foundations vous aidera à consolider vos compétences en matière de flux de travail sur GitHub.

Soutien à l'outillage et aux interfaces

La modification des livraisons ne doit pas se limiter à la ligne de commande. 

De nombreux outils Git offrent des interfaces conviviales qui rendent le processus plus accessible, en particulier pour les débutants. Le choix de la bonne interface peut améliorer la confiance et la productivité.

Clients GUI

Les outils d'interface graphique rendent git amend accessiblegrâce à des images :

• Sourcetree : Inclut une case à cocher "Modifier" dans le panneau de validation ; les utilisateurs peuvent visualiser et modifier les changements échelonnés avant de confirmer.
• GitKraken: Permet la réorganisation par glisser-déposer et l'édition interactive des engagements, y compris la prise en charge des modifications.
• Bureau GitHub: Permet aux utilisateurs de modifier la dernière livraison directement à partir de l'historique des livraisons par un simple basculement.

Ces outils fournissent un retour d'information visuel en temps réelréduisent le risque d'erreurs accidentelles et sont particulièrement utiles pour ceux qui apprennent Git.

Comparaison entre l'interface de programmation et l'interface graphique

CLI (git commit --amend) est rapide mais source d'erreurs pour les débutants. Les interfaces graphiques offrent une sécurité grâce à des repères visuels, mais peuvent ralentir les utilisateurs avancés. 

Les interfaces graphiques peuvent certainement faciliter l'apprentissage pour les débutants ; j'ai commencé avec Sourcetree pour comprendre les flux d'amendements avant de passer à l'interface CLI pour la rapidité et le contrôle.

Voici une comparaison visuelle de la prise en charge des amendements par les outils Git les plus répandus :

Graphique comparant les fonctions de modification des outils d'interface graphique.

Bonnes pratiques et recommandations

Pour conclure, voici les principes clés permettant d'utiliser git commit --amend de manière efficace et sûre dans les flux de travail réels :

Amendements locaux

Ne modifiez que les commits locaux pour éviter les problèmes à distance. Vérifiez auprès de git log et définissez les règles de l'équipe dans les documents du projet pour assurer la cohérence.

Commits atomiques et protocoles d'équipe

Créez de petits commits atomiques pour des changements ciblés. Alignez-vous sur la taille du commit avec votre équipe et révisez-le avant de le pousser pour repérer les erreurs.

Sauvegardes automatisées et formation

Utilisez des sauvegardes (par exemple, Git hooks, CI snapshots) avant de modifier et encouragez la familiarisation avec des outils tels que git reflog pour récupérer rapidement les erreurs.

Conclusion

git commit --amend est une commande puissante qui vous permet d'améliorer l'historique des livraisons, de corriger les erreurs et de présenter clairement votre travail. Lorsqu'il est utilisé de manière réfléchie - en particulier sur les commits locaux - il vous aide à maintenir un journal Git propre et professionnel, sans encombrement ni confusion.

Pour continuer à développer votre maîtrise de Git, explorez le cours Git intermédiaire ou téléchargez l'aide-mémoire Git complet pour une référence rapide.

Bon codage, et gardez vos connaissances en histoire !