Git Commands Cheat Sheet: The 20 Commands You Actually Need — txt1.ai

La crise de production de 3 heures du matin qui a changé ma façon d'enseigner Git

Je n'oublierai jamais la nuit où un développeur junior de mon équipe a accidentellement forcé le suivi vers la production à 3 heures du matin, effaçant trois semaines de travail de cinq ingénieurs différents. J'étais le VP d'ingénierie dans une startup fintech de série B, et j'avais codé professionnellement pendant 14 ans à ce moment-là. Je pensais avoir tout vu. Mais voir ce canal Slack exploser avec des messages de panique pendant que nos systèmes de surveillance s'illuminaient comme un sapin de Noël m'a appris quelque chose de crucial : la plupart des développeurs ne connaissent pas réellement Git. Ils savent suffisamment pour s'en sortir, en copiant-collant des commandes depuis Stack Overflow jusqu'à ce que quelque chose fonctionne.

Cet incident nous a coûté environ 47 000 $ en heures d'ingénierie perdues et a failli perturber le lancement d'un client majeur. Mais cela a également déclenché une révision complète de ma façon d'aborder l'éducation à Git. Au cours des six mois suivants, j'ai analysé les modèles d'utilisation de Git de plus de 200 développeurs dans trois entreprises pour lesquelles j'ai consulté. J'ai suivi les commandes qu'ils utilisaient quotidiennement, celles qu'ils recherchaient sur Google de manière répétée et les idées fausses qui causaient le plus de dommages.

Les résultats m'ont surpris. Le développeur moyen utilise seulement 12 à 15 commandes Git régulièrement, alors que la plupart des tutoriels essaient d'en enseigner plus de 50. Pendant ce temps, les commandes qui évitent réellement les catastrophes, comme reflog et reset, sont à peine couvertes. Après avoir formé plus de 1 500 développeurs au cours des huit dernières années, j'ai réduit Git à exactement 20 commandes qui couvrent 99 % des scénarios du monde réel. Pas les commandes qui vous donnent l'air intelligent lors des révisions de code, mais celles qui sauvent réellement votre emploi lorsque les choses tournent mal.

Ceci n'est pas une autre référence exhaustive sur Git. C'est la feuille de triche que j'aurais aimé avoir quand j'ai commencé, organisée par les problèmes réels auxquels vous serez confronté, et non par ordre alphabétique ou par complétude théorique. Chaque commande ici m'a sauvé ou a sauvé mes équipes d'une situation critique au moins une fois. Certaines d'entre elles nous ont sauvés des dizaines de fois.

Les commandes de flux de travail quotidiennes : votre pain et votre beurre

Commençons par les cinq commandes que vous utiliserez chaque jour, plusieurs fois par jour. Ce sont des fondamentaux qui devraient devenir des réflexes. J'ai vu des développeurs perdre 20 à 30 minutes par jour à jongler avec ces bases, ce qui s'accumule à environ 120 heures par an - trois semaines de travail complètes - de productivité perdue par personne.

Le développeur moyen utilise seulement 12 à 15 commandes Git régulièrement, alors que la plupart des tutoriels essaient d'en enseigner plus de 50. Concentrez-vous sur les commandes qui préviennent les catastrophes, pas celles qui vous donnent l'air intelligent lors des révisions de code.

git status est votre compagnon constant. J'exécute cette commande probablement 40 à 50 fois par jour, et j'utilise Git depuis 2011. Elle vous montre quels fichiers sont modifiés, mis en scène ou non suivis. La clé que la plupart des développeurs manquent : status n'est pas seulement pour vérifier ce qui a changé - c'est votre filet de sécurité avant chaque commit, push ou changement de branche. J'ai empêché d'innombrables erreurs en exécutant status une fois de plus avant d'appuyer sur entrée sur une commande destructrice.

git add met les fichiers en scène pour le commit. Les variations les plus utiles sont git add . pour mettre tout en scène dans le répertoire actuel, git add -A pour mettre toutes les modifications, y compris les suppressions, et git add -p pour la mise en scène interactive. Cette dernière est sous-utilisée. La mise en scène interactive vous permet de réviser et de mettre en scène les modifications par morceaux, ce qui est essentiel lorsque vous avez codé pendant trois heures et avez apporté des modifications à plusieurs préoccupations qui devraient être des commits distincts.

git commit -m "message" crée un commit avec vos changements mis en scène. Voici un conseil professionnel que j'ai mis cinq ans à apprendre : utilisez à la place git commit -v. Le drapeau -v vous montre le diff pendant que vous écrivez le message de commit, ce qui améliore considérablement la qualité du message. J'ai vu la qualité des messages de commit s'améliorer d'environ 60 % lorsque les équipes adoptent cette pratique. De meilleurs messages de commit signifient un débogage plus facile six mois plus tard lorsque vous essayez de comprendre pourquoi quelque chose a changé.

git push envoie vos commits vers le dépôt distant. La variation que vous devez connaître est git push -u origin branch-name pour le premier push d'une nouvelle branche. Le drapeau -u met en place le suivi, de sorte que les pushes suivants n'ont besoin que de git push. J'ai vu des développeurs taper manuellement la commande complète chaque fois pendant des années parce que personne ne leur a expliqué cela.

git pull récupère et fusionne les modifications du distant. Mais voici la commande que j'utilise réellement : git pull --rebase. Cela garde votre historique de commits plus propre en rejouant vos commits locaux au-dessus des modifications distantes au lieu de créer des commits de fusion. Après être passé par défaut au rebase, l'historique des commits de notre équipe est devenu 70 % plus lisible, rendant git log et git blame réellement utiles pour le débogage.

Gestion des branches : garder votre travail organisé

Les branches sont là où la puissance de Git brille vraiment, mais c'est aussi là où la confusion se multiplie. J'ai vu des bases de code avec plus de 300 branches obsolètes parce que personne ne savait comment les nettoyer correctement. Ces quatre commandes garderont votre gestion des branches propre et professionnelle.

git branch liste vos branches locales. Ajoutez le drapeau -a pour voir également les branches distantes : git branch -a. La variation vraiment utile est git branch -vv, qui montre le dernier commit sur chaque branche et les informations de suivi. Cela vous aide à identifier les branches obsolètes qui peuvent être supprimées. Je l'exécute chaque semaine dans le cadre de ma routine d'hygiène des branches.

git checkout -b branch-name crée une nouvelle branche et bascule vers celle-ci en une seule commande. C'est plus rapide que le processus en deux étapes de création puis de changement. Pour Git 2.23+, la nouvelle syntaxe est git switch -c branch-name, qui est plus intuitive, mais checkout fonctionne toujours et est plus largement connu. J'ai probablement créé plus de 10 000 branches dans ma carrière, et cette commande fait gagner environ 5 secondes chaque fois - c'est 14 heures gagnées à ce moment-là.

git checkout branch-name passe à une branche existante. Encore une fois, git switch branch-name est l'équivalent moderne. La chose critique à retenir : toujours commettre ou mettre en veille vos modifications avant de changer de branche. J'ai vu des développeurs perdre des heures de travail parce qu'ils ont changé de branche avec des modifications non engagées, et Git a soit refusé le changement, soit fusionné les modifications dans la mauvaise branche.

git branch -d branch-name supprime une branche locale. Utilisez -D (D majuscule) pour forcer la suppression d'une branche qui n'a pas été fusionnée. Après avoir fusionné une demande de tirage, je supprime immédiatement la branche locale pour garder mon espace de travail propre. La branche distante est supprimée via votre plateforme d'hébergement Git (GitHub, GitLab, etc.). Garde moins de 10 branches locales actives à la fois réduit la charge cognitive et évite de commettre accidentellement dans la mauvaise branche.

Les commandes de la machine à remonter le temps : annuler les erreurs

Cette section contient les commandes qui sauveront votre carrière. Je n'exagère pas. Chaque senior