Générateur de commandes Git — Arrêtez de chercher les mêmes commandes chaque jour

J'avais autrefois un onglet de navigateur ouvert en permanence sur la documentation git. Pas parce que je ne connaissais pas git, je l'utilisais depuis des années, mais parce que j'oubliais sans cesse la syntaxe exacte des choses que je ne faisais qu'occasionnellement. Était-ce git reset --soft ou git reset --cached quand je voulais désindexer sans perdre les changements ? git stash apply supprimait-il le stash ou le laissait ? Le flag pour définir l'upstream était-il -u ou --set-upstream ?

Chaque développeur que je connais a une version de cette expérience. Git est l'un de ces outils où les commandes quotidiennes deviennent réflexes en quelques semaines, mais les commandes de fréquence moyenne, celles qu'on utilise tous les quelques jours ou une fois par semaine, ne restent jamais vraiment. On les apprend, on les oublie, on les rapprend, on les oublie à nouveau.

Le Générateur de commandes Git sur ToolBox Hub existe précisément pour ces moments-là. Au lieu de basculer vers la documentation, vous pouvez filtrer par catégorie, chercher par ce que vous essayez de faire, remplir un nom de branche ou un hash de commit, et copier la commande complète. Pas de chasse, pas de débogage de mauvais flags.

Comment fonctionne l'outil

Quand vous ouvrez le Générateur de commandes Git, vous voyez une barre de recherche et une rangée de boutons de catégorie : Basic, Branching, Remote, Undo, Stash et Advanced.

Les cartes de commande montrent chacune la commande dans un bloc de code à chasse fixe, une description en langage clair de ce qu'elle fait, et un bouton de copie. Pour les commandes qui ont besoin d'un paramètre, un nom de branche, un chemin de fichier, un hash de commit, il y a une entrée de texte en dessous de la carte. Quoi que vous tapiez est substitué dans le modèle de commande en temps réel, donc le bouton de copie copie toujours la version prête à exécuter.

Par exemple, si vous cliquez sur la carte "Créer et basculer vers une nouvelle branche" et tapez feature/payments dans le champ de nom de branche, le bloc de commande se met instantanément à jour sur git checkout -b feature/payments et c'est ce qui est copié dans votre presse-papiers.

La barre de recherche filtre à travers les noms de commandes et les descriptions, donc vous pouvez taper "undo" et voir toutes les commandes pertinentes, ou taper "stash" et voir le workflow de stash complet ensemble.

Les commandes que vous utiliserez vraiment

Plutôt que de passer en revue toutes les 40 commandes et plus alphabétiquement, laissez-moi les parcourir par catégories telles qu'elles apparaissent dans une vraie journée de travail.

Configuration et bases quotidiennes

Les commandes de la catégorie Basic sont celles dont la mémoire musculaire prend le relais dans votre premier mois. git status est probablement la commande git la plus exécutée, elle vous dit ce qui est indexé, ce qui ne l'est pas, et ce qui n'est pas suivi. git add . indexe tout dans le répertoire courant. git commit -m "message" crée un commit.

Les deux que je vois sous-utilisées chez les développeurs dans cette catégorie sont git diff et git diff --staged. Exécuter git diff avant d'ajouter quoi que ce soit vous montre précisément ce qui a changé dans votre arbre de travail depuis le dernier commit. Exécuter git diff --staged après l'ajout montre ce qui entre réellement dans votre prochain commit. Prendre l'habitude de les examiner avant chaque commit attrape un nombre surprenant de logs de débogage, de blocs de code commentés et d'inclusions accidentelles de fichiers.

git log --oneline est un autre outil quotidien sous-estimé. La sortie par défaut de git log est verbeuse au point d'être difficile à parcourir. La version --oneline compresse chaque commit sur une seule ligne : les 7 premiers caractères du hash et le sujet du message de commit. Beaucoup plus rapide pour trouver le commit que vous cherchez.

Stratégie de branches

La catégorie Branching couvre tout, de la création de branches à la fusion et au balisage.

git checkout -b <branche> (ou le plus récent git switch -c <branche>) est ainsi que démarre la plupart du travail de fonctionnalité. Vous la nommez, vous y basculez, vous construisez. Quand le travail est terminé, vous ouvrez une pull request ou vous fusionnez en retour. Flux standard.

Les commandes sur lesquelles les gens sont flous sont git merge versus git rebase. Les deux intègrent les changements d'une branche dans une autre, mais de manière différente.

git merge crée un commit de fusion. L'historique de votre branche et l'historique de la branche cible sont tous deux préservés, et le commit de fusion montre où ils ont rejoint. En regardant un graphe git, les commits de fusion créent une forme de losange. C'est fidèle à ce qui s'est réellement passé, deux flux de travail parallèles ont convergé, et c'est le défaut sûr pour les workflows d'équipe.

git rebase prend vos commits, rebobine le pointeur de branche à la pointe de la branche cible, et rejoue vos commits par-dessus. Le résultat est une ligne droite de commits sans losanges de fusion. L'avantage est la lisibilité, git log est plus facile à suivre. L'inconvénient est que rebase réécrit les hashes de commits, ce qui crée des problèmes si quelqu'un d'autre a tiré ces commits. La règle : rebase sur les branches personnelles ou locales, merge sur les branches partagées.

git branch -d <branche> supprime une branche locale après la fusion. Git est conservateur ici et refusera de supprimer si la branche a des commits non fusionnés. Si vous voulez vraiment supprimer une branche non fusionnée, utilisez -D (majuscule). Le générateur inclut spécifiquement -d parce que c'est la version sûre.

Travailler avec les remotes

La catégorie Remote couvre les commandes qui touchent le serveur.

git fetch origin est subtilement différent de git pull. Fetch télécharge uniquement les nouveaux commits et branches depuis le remote, ne touche pas du tout à vos branches locales. Pull est un fetch suivi d'un merge. Je préfère d'abord fetcher et regarder ce qui a changé avant de merger, surtout sur des branches partagées actives. C'est une petite habitude qui m'a sauvé de conflits inattendus plus d'une fois.

git push -u origin <branche> est le premier push pour une nouvelle branche. Le flag -u établit la relation de suivi amont, donc après cela, git push et git pull sans arguments fonctionnent automatiquement sur cette branche. Si vous sautez -u sur le premier push, les appels git push suivants se plaindront qu'il n'y a pas d'amont configuré.

git remote -v est la commande "quel est mon setup". Sur tout dépôt inconnu, l'exécuter immédiatement vous dit où vont les fetches et les pushes. Vous seriez surpris de voir combien de fois cela révèle un remote pointant vers quelque part d'inattendu.

git cherry-pick <hash> mérite une mention. Il copie un seul commit de n'importe où dans l'historique sur votre branche actuelle. Le cas d'usage classique : un correctif a été fusionné dans main, mais vous travaillez sur une branche de fonctionnalité longue durée qui a également besoin de ce correctif. Cherry-pick le hash du commit et il atterrit sur votre branche sans le reste des changements de main.

Annuler les erreurs

C'est la catégorie que les gens recherchent le plus urgemment. Quelque chose a mal tourné et vous devez l'inverser sans aggraver les choses.

git reset --soft HEAD~1 est l'annulation la plus douce. Il déplace le pointeur de branche en arrière d'un commit mais laisse tous les changements indexés et prêts à être re-committés. Utilisez cela quand vous avez commité trop tôt et que vous voulez ajouter plus de changements ou réécrire le message.

git reset HEAD~1 (mode "mixed" par défaut) déplace le pointeur en arrière et désindexe les changements, mais les laisse dans votre arbre de travail. Utilisez cela quand vous voulez réexaminer ce que vous avez changé avant de réindexer.

git reset --hard HEAD~1 est l'option nucléaire. Il déplace le pointeur en arrière et supprime les changements entièrement. Il n'y a pas d'annulation intégrée pour cela, les changements disparaissent de l'arbre de travail. Utilisez-le uniquement quand vous êtes certain de ne pas vouloir ces changements.

git revert <hash> est le bon outil quand le commit que vous voulez annuler a déjà été poussé. Revert crée un nouveau commit qui applique l'inverse des changements originaux. L'historique est préservé. Vos coéquipiers qui ont tiré ne seront pas perturbés.

git restore <fichier> supprime les changements de l'arbre de travail sur un fichier spécifique. git restore --staged <fichier> désindexe un fichier sans toucher l'arbre de travail. Ces commandes ont été ajoutées dans Git 2.23 comme alternatives plus propres au git checkout et git reset surchargés.

Mettre en attente le travail en cours

Stash est la trappe de sortie "j'ai besoin de changer de contexte maintenant mais je ne suis pas prêt à commiter."

git stash sauvegarde vos changements non committés (indexés et non indexés) sur une pile et revert votre arbre de travail au dernier commit. Vous pouvez maintenant changer de branches, tirer des changements, corriger un bug, quoi que vous ayez besoin de faire. Quand vous revenez, git stash pop restaure vos changements.

git stash push -m "message descriptif" vaut la peine d'utiliser plutôt que le simple git stash dès que vous avez plus d'une entrée de stash. Le message facilite beaucoup l'identification des entrées quand vous exécutez git stash list plus tard. Une entrée de stash nommée WIP: refactoring du middleware d'auth est beaucoup plus utile que stash@{2}.

git stash apply stash@{1} applique une entrée spécifique sans la supprimer de la liste. Utile quand vous voulez appliquer le même stash à plusieurs branches.

Commandes avancées et moins courantes

La catégorie Advanced couvre les commandes qui apparaissent occasionnellement mais sont difficiles à mémoriser.

git log --oneline --graph --all est un favori que je recommande à tout le monde d'exécuter périodiquement sur leurs dépôts. Le graphe de branches ASCII vous donne une image visuelle de la façon dont vos branches sont liées, lesquelles ont divergé, où les fusions se sont produites, où sont les tags.

git bisect start commence une recherche binaire pour trouver quel commit a introduit un bug. Vous marquez un commit connu-bon avec git bisect good <hash> et un commit connu-mauvais avec git bisect bad <hash>, et git extrait le commit du point médian pour que vous le testiez. Vous continuez à marquer bon ou mauvais jusqu'à ce que git identifie le commit exact qui a tout cassé. Pour les bugs difficiles à reproduire sans exécuter le code, bisect est inestimable.

git blame <fichier> vous montre qui a modifié en dernier chaque ligne d'un fichier et dans quel commit. Le nom semble accusatoire, en pratique, il est généralement utilisé pour comprendre pourquoi une ligne de code est ainsi en cherchant le commit et en lisant son message et son diff.

git reflog est la commande de sauvetage. Même après un reset dur, git garde un journal interne de tous les endroits où HEAD a été. Si vous avez accidentellement détruit des commits dont vous aviez besoin, git reflog vous montrera le hash dont vous avez besoin pour les récupérer avec git reset --hard <hash-récupéré>.

Conseils pro pour un workflow Git plus fluide

Quelques habitudes qui font une vraie différence :

Écrivez les messages de commit à l'impératif. "Ajouter un middleware d'authentification" plutôt que "Middleware d'authentification ajouté." La convention existe parce que les messages générés par git (commits de fusion, reverts) utilisent l'impératif, donc vos messages s'intègrent naturellement.

Commitez petit et souvent. Les commits atomiques, un changement logique par commit, rendent git log lisible, facilitent la revue de code et rendent git bisect efficace. Commiter une fois par jour avec un énorme message "avancement" annule la plupart de la valeur de git.

Utilisez .gitignore agressivement. Les artefacts de build, les métadonnées d'IDE, les fichiers d'environnement, ceux-ci ne devraient jamais apparaître dans votre dépôt. Si git status est encombré de fichiers que vous n'allez jamais commiter, corrigez votre .gitignore.

Apprenez le flag --patch. git add --patch (ou git add -p) vous permet de sélectionner interactivement quels morceaux d'un fichier indexer. Quand un fichier a des changements pour deux objectifs différents, vous pouvez les diviser en commits séparés.

Outils à associer avec celui-ci

Parseur Cron — Les pipelines CI/CD ont souvent des jobs planifiés en plus des jobs déclenchés par des événements. Si votre pipeline de déploiement inclut un planning cron et que vous devez décoder ou construire une expression cron, cet outil le gère instantanément.

Encodeur URL — Les URLs remote Git contiennent parfois des caractères qui doivent être encodés, surtout quand des identifiants d'authentification ou des tokens sont intégrés dans l'URL.

FAQ

Quelle est la différence entre git fetch et git pull ? git fetch télécharge les nouveaux commits et branches depuis le remote mais ne touche pas à vos branches locales. git pull effectue un fetch suivi d'un merge. Fetch quand vous voulez inspecter d'abord, pull quand vous êtes prêt à intégrer.

Comment annuler un commit que j'ai déjà poussé ? Utilisez git revert <hash-du-commit> pour créer un nouveau commit qui annule les changements sans réécrire l'historique. git reset n'est sûr que pour les commits qui n'ont pas encore été poussés.

A quoi sert git stash ? Stash met temporairement de côté les changements non committés pour que vous puissiez changer de contexte, changer de branches, tirer des changements, appliquer un correctif, sans commiter un travail à moitié fait. git stash pop restaure les changements quand vous revenez.

Quand devrais-je utiliser rebase plutôt que merge ? Sur les branches personnelles où vous voulez un historique linéaire propre avant de fusionner dans main. Ne jamais rebaser des commits que d'autres ont déjà tirés, cela réécrit les hashes et cause des conflits.

Comment récupérer des commits après git reset --hard ? Exécutez git reflog pour voir l'historique des positions de HEAD. Trouvez le hash dont vous avez besoin et exécutez git reset --hard <ce-hash> pour le restaurer.

En conclusion

Git est l'un de ces outils qui récompense l'investissement en temps plus que presque tout le reste dans la boîte à outils d'un développeur. Les commandes qui semblent arcanes deviennent automatiques, les workflows qui nécessitaient autrefois un onglet de documentation deviennent une seconde nature.

Le Générateur de commandes Git est là pour la phase intermédiaire, quand vous savez ce que vous devez faire mais ne vous souvenez pas tout à fait de la syntaxe exacte. Mettez-le en favori, utilisez-le, et à force de l'avoir utilisé suffisamment de fois, vous aurez probablement de toute façon mémorisé les commandes.