7 Git commands that feel like cheating (and when not to use them)
La plupart des développeurs atteignent un point où certaines commandes Git commencent à sembler presque injustes. Ils éliminent des heures de confusion en quelques minutes et offrent un niveau de contrôle qui semble impossible la première fois que vous le voyez en action. Ma propre introduction à ces commandes explique pourquoi les utilisateurs expérimentés de Git décrivent l’outil comme à la fois intimidant et étrangement rassurant. Vous cassez quelque chose, vous sentez la panique monter, vous exécutez une courte séquence de commandes et tout le désordre se dissout comme s’il n’avait jamais existé.
Les commandes ci-dessous sont celles sur lesquelles je me suis appuyé pour mes projets personnels, mon travail et mes contributions open source. Ils sont faciles à apprendre, étonnamment puissants et capables d’économiser des journées entières d’efforts. Le même pouvoir les rend également risqués, il est donc utile de comprendre quand les utiliser et quand reculer.
Vous trouverez ci-dessous les commandes qui donnent vraiment l’impression de tricher, ainsi que les moments où elles causeront plus de mal que de bien :
git add -p : mettre en scène uniquement les bonnes parties
Lorsque je consulte l’historique Git de quelqu’un d’autre, je peux généralement repérer les développeurs qui ont appris l’outil par essais et erreurs. Leurs commits mélangent des modifications sans rapport, un travail à moitié terminé et des impressions de débogage glissées par erreur (j’ai fait la même chose plus de fois que je ne veux l’admettre). Ce dont ils ont vraiment besoin, c’est d’un moyen de séparer les modifications utiles des modifications accidentelles, et Git inclut déjà une fonctionnalité conçue exactement pour cela.
Le git ajouter -p divise vos fichiers modifiés en petites sections appelées morceaux, puis vous demande si vous souhaitez mettre en scène chacun d’entre eux. Il transforme vos modifications en une simple liste de contrôle, vous permettant d’inclure les éléments qui appartiennent à votre commit actuel tout en laissant les parties expérimentales ou compliquées pour plus tard. En pratique, cela ressemble à la possibilité de réécrire votre travail sur place sans rien modifier directement. Les commits propres deviennent une habitude naturelle (éventuellement), et tous ceux qui lisent votre historique en profitent, y compris votre futur moi qui se demandera un jour pourquoi vous avez glissé une variable parasite dans ce qui était censé être une correction de style de routine.
Quand ne pas l’utiliser
Si vous travaillez avec d’énormes fichiers générés automatiquement ou des bases de code où les modifications pilotées par les lignes n’ont pas de sens, la mise en scène interactive se transformera en une expérience lente et ennuyeuse. Il existe des situations dans lesquelles la préparation de fichiers entiers est non seulement plus propre, mais aussi plus précise.
git commit — amend : réécrire l’historique sans que personne ne le regarde
Chaque fois que vous avancez trop vite et exécutez git commit, vous remarquez généralement une erreur dès qu’il est trop tard. Parfois, j’oublie de mettre en scène un fichier ou je repère une simple faute de frappe qui s’est glissée. Plutôt que de créer un commit séparé pour quelque chose de trivial, vous pouvez corriger le précédent avec un seul git commit –amend commande qui met à jour les modifications échelonnées et vous permet de réécrire le message en une seule étape.
Son utilisation ressemble un peu à un voyage dans le temps contrôlé. L’ancien commit disparaît, une version corrigée prend sa place et l’historique suggère que l’erreur n’a jamais existé. Les évaluateurs évitent un flot de petites corrections et vous obtenez l’agréable illusion que vous fournissez systématiquement un travail parfait dès la première tentative.
Quand ne pas l’utiliser
Ne modifiez jamais un commit qui a déjà été transféré vers un référentiel partagé, sauf si vous êtes absolument sûr que tout le monde est à l’aise avec l’historique réécrit. Changer les engagements publics oblige les autres contributeurs à gérer des branches divergentes et des fusions déroutantes.
git reflog : récupérer les commits perdus
Quand les gens disent que Git perd rarement des données, ils font référence au reflog. Il conserve une trace de chaque changement subi par vos succursales. Si vous réinitialisez une branche, en supprimez une par erreur ou dépassez une validation lors d’un rebase, le reflog stocke chaque étape dans l’ordre. Cet enregistrement vous permet de retracer vos actions et de récupérer le travail qui semble avoir disparu.
La première fois que j’ai utilisé git reflog, je venais d’effectuer une réinitialisation qui supprimait plusieurs heures de travail. J’ai supposé que les modifications étaient perdues. Regarder le reflog a montré le commit exact dont j’avais besoin, et le vérifier a tout restauré. La situation s’est résolue rapidement et tout l’incident a changé ma façon de penser la récupération dans Git.
Quand ne pas l’utiliser
Les entrées de relog finissent par expirer, en particulier dans les clones superficiels ou lorsque le garbage collection s’est exécuté de manière agressive. Cela ne remplace pas des sauvegardes appropriées et vous ne devez pas vous y fier pour une récupération à long terme.
git Cherry-pick : prenez un commit et ignorez le reste
Le Cherry Picking vous permet de prendre un seul commit à n’importe quel moment de votre historique et de l’appliquer à votre branche actuelle. Le reste de la branche qui contient la validation n’est pas importé. Si vous n’avez besoin que d’un seul correctif d’une branche de fonctionnalité, vous pouvez l’appliquer sans fusionner l’ensemble des modifications.
Cela devient utile lorsqu’un problème de production apparaît et que vous vous souvenez que le correctif est déjà présent dans une branche de développement. Au lieu de fusionner une grande quantité de travail encore en cours, vous pouvez appliquer uniquement la validation qui résout le problème. Votre branche stable reste concentrée et vous évitez de forcer une fusion qui n’est pas prête à être révisée.
Quand ne pas l’utiliser
La sélection sélective crée de nouveaux hachages de validation et si vous effectuez une sélection fréquemment (ne le faites pas, vous savez que cela est méprisé ?) sur des branches de longue durée, vous pouvez créer des validations dupliquées qui provoquent plus tard des conflits de fusion ou des historiques déroutants.
4 commandes git avancées dont vous n’avez probablement pas entendu parler
Faites passer votre jeu Git au niveau supérieur.
git reset – dur : annulation nucléaire
La plupart des gens évitent cette commande et le problème est raisonnable car elle supprime toutes les modifications non planifiées, réinitialise le répertoire de travail et déplace le pointeur de branche vers la validation sélectionnée. C’est utile lorsque l’état actuel de votre travail ne vaut plus la peine d’être conservé et que vous souhaitez revenir à un répertoire propre le plus rapidement possible.
Les jours passés à expérimenter conduisent souvent à un arbre de travail rempli de tentatives abandonnées et de modifications partielles (le nettoyage à la main est beaucoup trop lent). Après avoir utilisé git ajouter -p pour garder vos commits concentrés, cette commande vous permet d’effacer le reste des modifications en une seule étape. Le résultat est un nouveau départ sans aucun bruit accumulé lors des travaux précédents.
Quand ne pas l’utiliser
N’utilisez jamais cette commande si vous avez un travail non engagé qui vous tient à cœur. Si vous souhaitez conserver votre travail mais le supprimer de la branche, utilisez git cachette plutôt. La réinitialisation matérielle n’est destinée qu’aux situations dans lesquelles vous souhaitez effacer l’état actuel sans hésitation.
git clean -fd : supprime tout ce qui n’a pas été validé
Parfois, le répertoire du projet collecte les fichiers restants tels que les artefacts de build, les journaux temporaires, les sauvegardes de l’éditeur et les binaires compilés. Git clean les supprime tous d’un seul coup. Il supprime tout fichier ou répertoire non suivi afin que vous puissiez revenir à un référentiel propre qui correspond à l’état réel du contrôle de version.
Lorsque vous travaillez avec des projets ou des frameworks volumineux qui génèrent des couches de fichiers de build, le nettoyage de l’espace de travail peut corriger des erreurs qui semblent sans rapport à première vue. C’est la méthode la plus rapide que je connaisse pour éliminer les déchets sans risquer les fichiers que j’ai réellement modifiés.
Quand ne pas l’utiliser
Veillez à ne pas l’exécuter dans un répertoire contenant des fichiers importants non suivis (je l’ai fait), tels que des fichiers de configuration que vous gardez intentionnellement hors du contrôle de version. Un rapide git propre -n affichera ce qui sera supprimé avant de continuer.
git rerere : réutiliser la résolution enregistrée
La première fois que j’ai entendu parler de Rerere, j’ai cru que c’était une blague. Le nom signifie réutilisation de la résolution enregistrée et il s’agit à la fois d’une fonctionnalité et d’une commande git. Git peut se souvenir de la manière dont vous avez résolu un conflit particulier et appliquer automatiquement la même résolution la prochaine fois que le même conflit apparaît. Si vous travaillez avec une branche de longue durée que vous rebasez souvent, cet outil vous fait gagner énormément de temps.
La meilleure partie est que rerere fonctionne silencieusement en arrière-plan. Vous résolvez un conflit une fois et Git note le modèle. Plus tard, lorsque vous fusionnez ou rebasez à nouveau, Git réutilise instantanément le correctif. C’est comme avoir un petit assistant qui prend des notes pendant vos batailles de fusion et intervient lorsque le même ennemi revient. Pour l’utiliser dans un dépôt, vous pouvez l’activer à l’aide des commandes suivantes :
git config rerere.enabled true
git config rerere.autoupdate true
Quand ne pas l’utiliser
Si vos résolutions de conflits changent fréquemment ou dépendent du contexte, rerere peut appliquer une résolution qui n’a plus de sens et gâcher les choses comme avec les autres commandes de cette liste, examinez-les avant de les utiliser.
Cette application Linux open source m’a amené à abandonner la commande git
C’est probablement le meilleur TUI que j’ai utilisé, et il a également l’air très bien.
Git vous encourage à traiter l’histoire comme quelque chose que vous pouvez façonner plutôt que comme quelque chose qui vous arrive. D’autres systèmes de contrôle de version fournissent également des fonctions d’annulation de base, mais Git vous propose des outils qui remodèlent complètement vos branches, récupèrent le travail perdu, prévisualisent les modifications ligne par ligne et voyagent dans le temps si nécessaire. Cependant, une grande puissance s’accompagne d’une grande confusion (à l’heure actuelle, la page de manuel de Git compte 1 514 lignes), c’est pourquoi de nombreux développeurs grandissent en craignant plus Git que leurs serveurs de production.
Le secret n’est pas d’utiliser ces commandes tout le temps mais de savoir quand elles vous donnent le plus d’influence avec le moins de risques. C’est comme tricher parce que vous prenez le dessus dans des situations qui étaient autrefois douloureuses. La solution n’est pas toujours évidente, mais une fois que vous connaissez la commande, votre confiance grandit rapidement.
