Git Commands Cheat Sheet: The 20 Commands You Actually Need — cod-ai.com

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

Il était 3 h 17 un mardi quand mon téléphone a explosé de notifications. Notre branche principale de production était cassée, les déploiements échouaient, et personne ne pouvait comprendre ce qui s'était passé. J'étais l'ingénieur DevOps senior de garde, et alors que je titubais vers mon ordinateur portable, je savais exactement ce qui s'était passé : quelqu'un avait forcé un push vers la branche principale sans comprendre ce qu'il faisait.

Cet incident nous a coûté environ 47 000 $ en revenus perdus pendant la panne de quatre heures. Mais plus important encore, cela m'a appris quelque chose de crucial : la plupart des développeurs n'ont pas besoin de connaître 200 commandes Git. Ils doivent maîtriser environ 20 commandes et les comprendre suffisamment pour éviter des erreurs catastrophiques.

Je suis Marcus Chen, et je travaille en tant qu'ingénieur DevOps et responsable technique depuis 12 ans, principalement dans des entreprises SaaS de taille moyenne à grande. J'ai intégré plus de 150 développeurs, examiné des milliers de demandes de tirage, et corrigé plus de désastres Git que je ne veux m'en souvenir. Ce que j'ai appris, c'est que la maîtrise de Git ne consiste pas à mémoriser chaque drapeau et option — il s'agit d'avoir un modèle mental fiable et de savoir exactement quelles commandes utiliser dans des situations spécifiques.

Cette feuille de triche représente la sagesse distillée d'une décennie d'utilisation réelle de Git. Ce ne sont pas des commandes théoriques que j'ai trouvées dans la documentation. Ce sont les 20 commandes que j'utilise presque tous les jours, celles que j'enseigne à chaque nouveau membre de l'équipe, et qui ont permis à mon équipe d'économiser d'innombrables heures de frustration. Chaque commande ici a gagné sa place par nécessité pratique, et non par complétude académique.

Avant de plonger, laissez-moi être clair sur quelque chose : ce n'est pas une introduction pour débutants à Git. Si vous êtes complètement nouveau dans le contrôle de version, vous voudrez commencer par les bases ailleurs. Ce guide est pour des développeurs qui savent déjà que Git existe et l'ont utilisé, mais qui souhaitent améliorer leur efficacité et leur confiance. Vous en avez assez de rechercher les mêmes commandes à plusieurs reprises. Vous voulez une référence soigneusement choisie et éprouvée au combat qui reflète réellement comment les professionnels utilisent Git dans des environnements de production.

Les fondamentaux : commandes que vous utiliserez chaque jour

Commençons par les éléments essentiels — les commandes qui forment la colonne vertébrale de votre flux de travail Git quotidien. J'utilise ces commandes si fréquemment qu'elles sont pratiquement devenues des réflexes. Si vous travaillez dans une équipe de n'importe quelle taille, vous utiliserez probablement chacune d'elles au moins une fois par jour, souvent plusieurs fois.

"La maîtrise de Git ne consiste pas à mémoriser chaque drapeau et option — il s'agit d'avoir un modèle mental fiable et de savoir exactement quelles commandes utiliser dans des situations spécifiques."

git status — C'est votre commande de prise de conscience situationnelle. Je l'exécute probablement 30-40 fois par jour, et je n'exagère pas. Avant de vous engager, après vous être engagé, quand quelque chose semble mal, lorsque vous changez de contexte entre des tâches — git status vous dit exactement où vous en êtes. Il vous montre quels fichiers sont en phase, lesquels sont modifiés mais non enregistrés, et lesquels ne sont pas suivis. Pensez-y comme à votre boussole Git. La sortie est codée par couleur et remarquablement claire, c'est pourquoi c'est la première commande que j'enseigne à quiconque.

git add — Cela prépare vos modifications pour l'engagement. L'utilisation la plus courante est git add . pour préparer tout ce qui se trouve dans votre répertoire actuel, mais je recommande en fait d'être plus sélectif. Utilisez git add nom_du_fichier pour préparer des fichiers spécifiques, ou git add -p pour une préparation interactive où vous pouvez examiner et préparer des morceaux individuels de modifications. Ce contrôle granulaire m'a sauvé de nombreuses fois lorsque j'ai effectué plusieurs modifications sans lien et que j'avais besoin de les engager séparément. À mon avis, les développeurs qui utilisent git add sans réfléchir créent des historiques d'engagement désordonnés qui rendent le débogage et la révision de code beaucoup plus difficiles.

git commit -m "message" — Cela crée un instantané de vos modifications préparées. L'option -m vous permet d'ajouter un message d'engagement en ligne. Maintenant, voici où je vais partager une sagesse durement acquise : vos messages d'engagement comptent bien plus que vous ne le pensez. J'ai passé des heures à essayer de comprendre pourquoi un changement particulier a été effectué, pour ne trouver qu'un message d'engagement disant "corriger des choses" ou "mises à jour". Un bon message d'engagement devrait compléter cette phrase : "Si appliqué, cet engagement va..." Par exemple : "Si appliqué, cet engagement va ajouter l'authentification utilisateur à l'endpoint de connexion." Cette discipline a rendu l'archéologie de code infiniment plus facile pour mes équipes.

git push — Cela télécharge vos engagements locaux vers le dépôt distant. Le plus souvent, vous utiliserez git push origin nom_de_branche. La première fois que vous poussez une nouvelle branche, vous aurez besoin de git push -u origin nom_de_branche où l'option -u configure le suivi afin que les futures poussées puissent se faire juste avec git push. Je ne saurais trop insister là-dessus : ne jamais, jamais utiliser git push --force sur des branches partagées à moins que vous sachiez absolument ce que vous faites et que vous ayez communiqué avec votre équipe. Cet incident de 3 h du matin que j'ai mentionné ? C'était un force push mal exécuté.

git pull — Cela récupère les modifications du dépôt distant et les fusionne dans votre branche actuelle. Je commence chaque session de travail par un git pull pour m'assurer que je travaille avec le dernier code. Une chose critique à comprendre : git pull est en fait deux commandes combinées — git fetch suivi de git merge. Parfois, vous voudrez les utiliser séparément pour plus de contrôle, ce dont nous discuterons plus tard. Lorsque vous tirez et qu'il y a des conflits, Git vous dira exactement quels fichiers ont des conflits, et vous devrez les résoudre manuellement avant de pouvoir continuer.

Branchement : votre boîte à outils pour univers parallèles

Le branchement est là où se révèle la véritable puissance de Git. C'est ce qui permet à plusieurs développeurs de travailler sur différentes fonctionnalités simultanément sans se marcher sur les pieds. Dans mon équipe actuelle de 23 développeurs, nous avons généralement entre 40 et 60 branches actives à tout moment. Maîtriser ces commandes de branchement est ce qui sépare les utilisateurs de Git occasionnels des professionnels confiants.

git branch — Exécutez