4 commandes git avancées dont vous n'avez probablement pas entendu parler
Git est un énorme programme, avec près de 200 sous-commandes et d’innombrables options parmi elles. Vous n’en utilisez probablement qu’une poignée, ces piliers fiables comme init, add, commit et branch. Mais certaines commandes vont bien plus loin que les bases et peuvent radicalement améliorer votre vie de codage si vous apprenez à les connaître.
Sommaire
Utilisez git clean pour nettoyer au printemps votre arbre de travail
Nous commençons assez simplement, avec une commande pragmatique qui peut vous aider à garder votre référentiel propre. Cela semble évident avec le recul, mais vous avez probablement déjà fait cela manuellement, alors préparez-vous à gagner beaucoup de temps avec :
git clean
La commande git clean supprime les fichiers non suivis de l'arborescence de travail. Ainsi, tous les fichiers compilés, sauvegardes, fichiers Mac .DS_Store ou tout autre élément qui ne fait pas réellement partie de votre référentiel seront supprimés. Par exemple, ce référentiel simple contient un fichier non suivi :
L'exécution de git clean supprime ce fichier, mais laisse les autres seuls, y compris le fichier hello ignoré par git :
Par défaut, git clean laissera les répertoires non suivis seuls, mais vous pouvez utiliser l'option -d pour y accéder de manière récursive. Je recommande d'utiliser l'option -n pour effectuer d'abord un essai à sec, où git vous montrera les fichiers qu'il aurait supprimés, sans les supprimer réellement. Vous pouvez également utiliser le -i pour le mode interactif, ce qui vous donnera des choix plus précis pour gérer les fichiers :
Utilisez git bisect pour trouver quel commit a introduit un bug
La commande bisect vous aide à déterminer quel commit a introduit un bug ou une régression particulière. Sans cela, une telle tâche impliquerait de vérifier à plusieurs reprises chaque révision, peut-être avec quelques conjectures éclairées quant à savoir lequel pourrait en être le coupable. Dans une petite base de code, ou dans une base de code que vous maîtrisez parfaitement, cela n'est peut-être pas une telle épreuve. Avec des projets collaboratifs de plus grande envergure, cela pourrait facilement prendre beaucoup trop de temps précieux.
Pour être clair, git bisect est loin d’être magique. En fait, il offre une solution triviale au problème : la recherche binaire. La recherche binaire est une forme de résolution de problèmes « diviser pour mieux régner ». Dans le cas de git bisect, cela implique un processus simple :
-
Identifiez la première mauvaise révision, celle qui contient définitivement le problème. Il s'agit souvent de la révision actuelle (ou HEAD).
-
Identifiez la dernière bonne révision. C'est généralement un peu plus délicat, mais vous pouvez toujours commencer beaucoup plus tôt que nécessaire, même avec votre toute première révision.
-
Vérifiez une révision au milieu de ces deux-là. Si c'est bon, le bug doit être plus récent ; sinon, c'est plus vieux.
-
Continuez à répéter 3 jusqu'à ce que vous identifiiez le commit qui a introduit le bug.
Cet exemple montre un référentiel avec cinq commits et les commandes bisect start, bad et good définissant la portée :
A chaque étape, git bisect vérifie un nouveau commit que vous pouvez ensuite tester pour voir s'il contient le bug ou non :
Une fois toutes les possibilités épuisées, git bisect signale le premier mauvais commit trouvé en fonction de vos choix initiaux. Vous pouvez maintenant courir git bisect réinitialiser pour terminer le processus et résoudre le mauvais commit en conséquence.
Cela peut encore sembler un processus laborieux, mais c'est une correction de bug pour vous. C'est bien mieux que de se lancer dans des révisions au hasard, en essayant de cerner le problème. git bisect accélère vraiment la tâche, vous évitant d'inspecter les journaux git et de vérifier les commits individuels.
Découvrez git Cherry-pick et fusionnez moins qu'une branche
Habituellement, lorsque vous combinez le travail de deux branches distinctes, c'est une opération tout ou rien. La commande git merge crée un nouveau commit avec chaque commit d'une autre branche appliqué à la branche actuelle. Cela a beaucoup de sens pour de nombreux flux de travail, mais parfois, vous souhaitez être un peu plus nuancé.
La commande Cherry-pick vous permet de choisir un commit spécifique et d'appliquer ses modifications à votre branche actuelle, en tant que nouveau commit. Vous exécuterez généralement une sélection sélective sur un commit provenant d'une branche différente, c'est donc un excellent moyen d'apporter un changement singulier à partir d'une branche de fonctionnalités beaucoup plus grande, par exemple.
Par défaut, Cherry-pick réutilisera le message de validation, ce qui en fera une opération très rapide. Si vous le souhaitez, vous pouvez modifier le nouveau message de validation en utilisant git cerise-pick -e commit-id.
Si le commit ne s'applique pas proprement, Cherry-pick suivra une procédure similaire pour git merge et vous demandera de résoudre les conflits manuellement.
Essayez git revert pour annuler les commits indésirables
Avez-vous déjà regretté de vous être engagé après l'événement ? Si vous le faites et que vous le repérez assez tôt, git reset peut vous aider. Mais pour les commits isolés, ou si vous ne souhaitez pas détruire une partie de l'historique de votre dépôt, git revert est l'outil que vous devriez utiliser.
Utilisez git revert contre un commit spécifique et vous supprimez efficacement ce seul commit. Le référentiel se terminera exactement comme il l’aurait été si cette validation n’avait jamais eu lieu. Tous ses changements auront disparu.
Exécutez-le comme :
git revert
En réponse, Git créera un tout nouveau commit à l'opposé de
Comme pour le Cherry Pick, si votre restauration crée des conflits, il vous sera demandé de les résoudre manuellement avant d'exécuter git revert –continuer à confirmer.
