Fermer

mars 27, 2020

Comment rendre la vie plus facile lors de l'utilisation de Git


À propos de l'auteur

Shane Hudson est un développeur front-end indépendant du Royaume-Uni qui a travaillé sur une variété de projets allant d'un service national de triage des soins de santé en ligne…
En savoir plus sur
Shane
…

Vous n'avez pas besoin de connaître vos arbres à partir de vos taches pendantes, si vous utilisez Git tous les jours et que vous avez l'impression que c'est un acte de jonglage, voici quelques trucs et astuces pour vous faciliter la vie lors de l'utilisation

Git est sorti il ​​y a presque 15 ans. Pendant ce temps, il est passé d'outsider à champion invaincu, git init est souvent la première commande exécutée sur un nouveau projet. C'est sans aucun doute un outil important que beaucoup d'entre nous utilisent au quotidien… et pourtant, il est souvent perçu comme magique: brillant, mais effrayant.

Il y a beaucoup d'écrits sur le démarrage de git, comprendre comment git fonctionne sous le capot ou techniques pour de meilleures stratégies de ramification. Dans cet article, nous ciblerons spécifiquement les choses qui améliorent simplement votre vie d'une petite manière.

Finding Your Old Socks

L'intérêt de git est de pouvoir sauvegarder votre travail, changer de contexte et faire autre chose. Il pourrait s'agir de sauvegarder le code pour l'avenir, ou de pouvoir progresser de manière asynchrone sur quelques fonctionnalités différentes. Ce serait horrible de devoir jeter v2 juste parce qu'il y avait un bogue dans v1 il serait tout aussi dommage d'avoir des fichiers nommés comme v1_final_bug_fixed qui

Nous savons que la vie est plus facile, dans une certaine mesure, avec nos mises à jour soigneusement compartimentées en branches git qui peuvent être partagées avec d'autres membres de l'équipe. Cependant, je suis sûr que vous êtes d'accord, il y a souvent des moments où vous avez changé de contexte et lorsque vous revenez en arrière, il est impossible de trouver la bonne branche. At-il déjà été commis? Peut-être qu'il était caché? Peut-être que ce n'était pas engagé et maintenant le travail est dans la mauvaise branche et tout va mal et je suis affreux dans mon travail! Nous avons tous été là.

Trier les branches par date

Ma première tentative pour trouver comment trouver du travail perdu, dans un court article de blog intitulé « Comment trouver la branche que vous avez perdue dans git »Était de trier les branches par date. Cela génère chaque branche que vous avez localement, en commençant par la plus récente. Ce n'est pas compliqué ni surprenant, mais cela m'a aidé à plusieurs reprises.

 # Pour trier les branches par date de validation
git branch --sort = -committerdate

Branche précédente

Que pouvez-vous faire si vous ne vous êtes pas engagé, si vous avez changé de branche et que vous souhaitez y revenir? Vous pourriez probablement travailler sur la liste des branches de toute façon, si vous avez une idée du nom de la branche. Mais que se passe-t-il s'il ne s'agit pas d'une branche, s'il s'agit d'une «tête détachée», d'un commit spécifique.

Il s'avère qu'il existe un moyen de le faire facilement:

 # Checkout previous branch
git checkout -

Le - agit comme un raccourci pour @ {- 1} qui est une syntaxe que vous pouvez utiliser pour revenir en arrière pour un montant donné de retraits. Par exemple, si vous avez extrait la branche feature / thing-a puis feature / thing-b puis bugfix / thing-c vous pouvez utiliser @ {- 2} pour revenir à fonctionnalité / chose-a .

 # Checkout branch N number of checkouts ago
git checkout @ {- N}

Afficher des informations sur toutes les branches

Si vous cherchez un moyen de voir quel était le dernier commit dans chaque branche, vous pouvez utiliser les indicateurs d'option v pour afficher une liste de toutes les branches avec le dernier ID de validation et message de chacun. Si vous le faites deux fois ( vv ), il affichera également la branche distante en amont à laquelle il est lié.

 # Liste des branches avec l'ID de validation, le message de validation et la télécommande
git branch -vv

Ce seul fichier

Nous l'avons tous fait: D'une manière ou d'une autre, un seul fichier a été laissé dans la mauvaise branche. Avez-vous besoin de refaire tout votre travail, ou de copier-coller entre les deux branches? Non, heureusement, il existe un moyen de le faire.

C'est un peu étrange, surtout compte tenu de git checkout - remonte à une branche précédente; si vous utilisez - après un nom de branche lors du paiement, il vous permettra de spécifier le fichier spécifique que vous recherchez. Ce n'est pas quelque chose que vous devinez, mais vraiment pratique une fois que vous le savez.

 Fonctionnalité de vérification de git / my-other-branch - thefile.txt

Rendre le statut plus facile à lire

Dans un tweet Tomasz Łakomy a mentionné la réduction de la sortie du statut git à l'aide des drapeaux -sb et a déclaré: «J'ai utilisé git pendant des années et personne ne m'a parlé de cela. " Il ne s'agit pas strictement de rechercher des fichiers perdus, mais il existe des cas où la simplification de la sortie pourrait faciliter la vue de ce qui a été modifié.

La plupart des commandes git ont des indicateurs comme celui-ci, il vaut donc toujours la peine d'examiner comment vous pouvez utiliser les pour personnaliser votre flux de travail! 

 # Habituellement, nous utilisons l'état git pour vérifier quels fichiers ont changé
statut git

# Les sorties:
Sur le maître de branche
Modifications non planifiées pour la validation:
  (utilisez "git add  ..." pour mettre à jour ce qui sera validé)
  (utilisez "git checkout -  ..." pour ignorer les modifications dans le répertoire de travail)

    modifié: README.md

Fichiers non suivis:
  (utilisez "git add  ..." pour inclure dans ce qui sera commis)

    un autre fichier
    mon-nouveau-fichier

# En utilisant les drapeaux -sb, nous pouvons raccourcir la sortie
git status -sb

# Les sorties:
## Maître
 M README.md
?? un autre fichier
?? mon-nouveau-fichier

Voir tout ce qui s'est passé

Il y a des moments où quelque chose se passe complètement mal – comme rejeter accidentellement des changements par étapes avant de les valider. Lorsque git log ne suffit pas pour revenir à ce que vous avez fait en dernier et qu'aucune des astuces ci-dessus n'est utile, alors il y a git reflog .

Tout ce que vous faites dans git change où HEAD @ {} pointe vers (tel que push / pull / branch / checkout / commit ) mettra à jour le journal de référence afin qu'il agisse essentiellement comme un historique de tout ce que vous avez fait, quelle que soit la branche vous êtes sur. Cela contraste avec git log qui est tout ce qui a changé au fil du temps pour la branche particulière.

Vue d'ensemble en un seul endroit

Avec l'ID de validation, vous pouvez faire git show pour voir le changement et si c'est définitivement le celui que vous voulez, vous pouvez utiliser git checkout ou même sélectionner un fichier spécifique comme indiqué ci-dessus.

 # Voir le journal de référence de votre activité
git reflog --all

# Regardez la TETE à un point donné de reflog
git show HEAD @ {2}

# Check the HEAD, pour revenir à ce point
git checkout HEAD @ {2}

Fichiers intermédiaires qui n'ont jamais été engagés

Dans le cas extrême où git reflog ne peut pas vous aider à récupérer vos fichiers (par exemple, si vous avez effectué une réinitialisation matérielle avec des fichiers intermédiaires), il y a encore un truc dans votre sac. Chaque modification est stockée dans .git / objects qui sur un projet actif serait plein de fichiers et impossible à déchiffrer. Il existe cependant une commande git appelée git fsck qui est utilisée pour vérifier l'intégrité (rechercher les fichiers corrompus) dans un référentiel. Nous pouvons utiliser cette commande avec l'indicateur - lost-found pour rechercher tous les fichiers qui ne sont pas liés à une validation;

Il trouvera également des «arbres pendants» et des «commissions pendantes» – vous pouvez utiliser - pendantes si vous voulez mais - perdu- found a l'avantage d'extraire tous les fichiers appropriés dans un dossier .git / lost-found . Sur un projet actif, il est probable que vous ayez beaucoup de ces fichiers pendant sans même le savoir; git a une commande de nettoyage des ordures qui s'exécute régulièrement pour s'en débarrasser.

Donc, en utilisant - lost-found vous pouvez alors lister les fichiers et voir l'heure / la date à laquelle ils ont été créés, ce qui permet de voir plus facilement les fichiers que vous recherchez. Notez que chaque fichier individuel sera toujours un fichier individuel (vous ne pouvez pas utiliser l'extraction) et que tous les fichiers auront des noms non reconnaissables (un hachage), vous devrez donc copier les fichiers que vous voulez.

 # Ceci trouvera toute modification qui était mis en scène mais n'est pas attaché à l'arbre git
git fsck --lost-found

# Voir les dates des fichiers
ls -lah .git / lost-found / autre /

# Copiez les fichiers appropriés où vous le souhaitez, par exemple:
cp .git / lost-found / other / 73f60804ac20d5e417783a324517eba600976d30 index.html

Git en équipe

Utiliser Git en tant qu'utilisateur unique est une chose mais lorsque vous faites partie d'une équipe de personnes – généralement avec un mélange d'horizons et de technologies – Git peut devenir à la fois une bénédiction et une malédiction. Il peut être puissant pour partager la même base de code, obtenir des révisions de code et voir les progrès de toute l'équipe. Mais en même temps, tout le monde doit avoir une compréhension commune de la façon dont l'équipe a l'intention de l'utiliser. Qu'il s'agisse de conventions de dénomination de branche, de la façon dont vous structurez un message de validation ou exactement quels fichiers sont validés, il est essentiel d'avoir une bonne communication et de parler de la façon dont vous utiliserez tous l'outil .

Il est toujours important de considérez à quel point il est facile d'intégrer un nouveau développeur, que se passerait-il s'il commençait à s'engager sans connaître certains des principes et conventions convenus? Ce ne serait pas la fin du monde, mais cela provoquerait probablement une certaine confusion et prendrait du temps pour ramener les choses à l'approche convenue.

Cette section contient quelques trucs et astuces pour que le référentiel connaisse les conventions, pour automatiser et déclarer autant que possible. Dans le cas idéal, tout nouvel contributeur fonctionnerait presque immédiatement de la même manière que le reste de l'équipe.

Même fin de ligne

Par défaut, Windows utilise les fins de ligne DOS r n (CRLF) tandis que Mac et Linux utilisent tous deux des fins de ligne UNIX n (LF) et des versions très anciennes de Mac utilisaient r (CR). Ainsi, au fur et à mesure qu'une équipe grandit, il devient plus probable que les fins de ligne non appariées deviennent un problème. Habituellement, ce sont des inconvénients; ils (probablement) ne briseront pas votre code, mais les validations et les pull-pulls montreront toutes sortes de changements non pertinents. Très souvent, les gens les ignorent – c'est assez compliqué à passer et à changer.

Il existe une solution à cela: vous pouvez demander à tout le monde dans l'équipe de définir leurs configurations locales sur des fins de ligne automatiques.

 # This vous permettra de configurer les fins de ligne sur une base individuelle
git config core.eol lf
entrée git config core.autocrlf

Bien sûr, cela signifierait s’assurer que le nouveau contributeur le fait et il est si facile d’oublier de le lui dire. Alors, comment ferions-nous pour toute l'équipe? Eh bien, la façon dont Git fonctionne est qu'il recherche un fichier de configuration dans le référentiel à .git / config, puis il vérifie la configuration à l'échelle du système de l'utilisateur à ~ / .git / config puis vérifie la configuration globale à / etc / gitconfig . Ceux-ci sont tous utiles à certains moments, mais il s'avère qu'aucun de ceux-ci ne peut être défini via le référentiel lui-même. Vous pouvez ajouter des configurations spécifiques au référentiel mais qui ne seront pas transférées aux autres membres de l'équipe.

Il existe cependant un fichier qui est validé dans le référentiel. Cela s'appelle .gitattributes . Vous n'en aurez pas par défaut, alors créez un nouveau fichier et enregistrez-le sous "* .gitattributes *". Ce fichier est utilisé pour définir des attributs par fichier; par exemple, vous pouvez faire en sorte que git diff utilise des données exif pour les fichiers image au lieu d'essayer de diff un fichier binaire. Dans ce cas, nous pouvons utiliser un caractère générique pour que le paramètre fonctionne pour tous les fichiers, agissant essentiellement comme un fichier de configuration à l'échelle de l'équipe.

 # L'ajout de ceci à votre fichier .gitattributes rendra tous les fichiers
# sont archivés à l'aide des fins de ligne UNIX tout en permettant à n'importe qui dans l'équipe
# modifier les fichiers à l'aide des fins de ligne par défaut de leur système d'exploitation local.
* text = auto

Auto-Collapse

C'est une solution bien connue pour ajouter des fichiers gérés par package (comme node_modules / ) au fichier .gitignore afin de conserver les fichiers compilés localement et ne pas les ajouter au référentiel. Cependant, il existe parfois des fichiers que vous souhaitez archiver, mais que vous ne souhaitez pas voir à chaque fois dans la demande d'extraction. votre fichier .gitattributes et archivez ce fichier à la racine du référentiel. Cela réduira les fichiers dans la demande d'extraction, vous pourrez donc toujours voir qu'ils ont été modifiés sans le contenu complet de la modification.

Tout ce qui peut réduire le stress et la charge cognitive de la révision de code va aider à améliorer la qualité des révisions de code. et réduisez le temps nécessaire.

Par exemple, si vous avez un projet Unity, vous voudrez archiver vos fichiers de ressources mais ne vous souciez pas vraiment d'eux afin que vous puissiez l'ajouter au fichier d'attributs comme ceci: [19659011] *. actif généré par le linguiste

Utilisez plus souvent Git Blame

Voici une astuce que Harry Roberts a suggérée dans son article sur Git, « Petites choses que j'aime faire avec Git .» Il dit à alias git blame à git louange pour que cela ressemble à une action positive. Cela ressemble à de la sémantique – renommer quelque chose ne change pas du tout ce qu'il fait. Mais chaque fois que j'ai vu une équipe parler de l'utilisation de la fonction de blâme de Git, tout le monde se crispe, et moi aussi, certainement. C'est une réaction naturelle de penser que c'est une chose négative… ça ne devrait vraiment pas être le cas!

C'est une fonctionnalité puissante qui sait qui a touché en dernier le code que vous regardez. Pas pour les blâmer ni même pour les féliciter, mais simplement pour poser les bonnes questions à la bonne personne et pour gagner du temps à savoir à qui parler.

Non seulement vous devriez considérer le blâme comme une bonne chose (appelez-le «louange»). si vous le souhaitez), mais vous devez le considérer comme un outil de communication qui aidera toute l'équipe à réduire la confusion et à éviter de perdre du temps à déterminer qui sait quoi. Certains IDE tels que Visual Studio incluent cette fonctionnalité sous forme d'annotations (sans aucune connotation négative) de chaque fonction afin que vous puissiez voir instantanément qui l'a modifiée en dernier (et donc à qui en parler).

Git Blame For A Missing Fichier

Récemment, j'ai vu un développeur de l'équipe essayer de comprendre qui a supprimé un fichier, quand il l'a été et pourquoi il a été supprimé. Cela semble être un moment utile pour git blame mais cela fonctionne sur la base des lignes d'un fichier; cela n'aide pas avec les choses qui n'existent plus. Il existe cependant une solution. L'ancien journal git fidèle. Si vous regardez le journal sans arguments, vous verrez une longue liste de toutes les modifications sur la branche actuelle. Vous pouvez ajouter un ID de validation pour voir le journal de cette validation spécifique, mais si vous utilisez - (que nous avons déjà utilisé pour cibler un fichier spécifique), vous pouvez obtenir le journal d'un fichier – même celui qui n'existe plus.

 # En utilisant - pour un fichier spécifique,
# git log peut trouver les journaux des fichiers qui ont été supprimés lors de validations antérieures
journal git - fichier_manquant.txt

Modèle de message de validation

Une chose qui finit par être mentionnée au sein des équipes est que les messages de validation pourraient être améliorés. Peut-être qu'ils pourraient faire référence à l'ID d'un outil de gestion de projet pour le bogue corrigé ou peut-être que vous souhaitez encourager un texte au lieu d'un message vide.

Celui-ci doit être exécuté manuellement chaque fois que quelqu'un clone le référentiel (sous forme de fichiers de configuration git ne sont pas validées dans le référentiel), mais c'est pratique car vous pouvez avoir un fichier partagé dans le référentiel (nommé tout ce que vous voulez) qui peut agir comme modèle de message de validation.

 # Ceci définit le modèle de validation sur le fichier donné ,
# cela doit être exécuté pour chaque contributeur au référentiel.
git config commit.template ./template-file

Git As Automation

Git est puissant pour l'automatisation. Ce n'est pas immédiatement évident, mais si vous considérez qu'il connaît toutes vos activités passées dans le référentiel – ainsi que celles d'autres contributeurs – il contient beaucoup d'informations qui peuvent être très utiles.

Git Hooks

Assez souvent, vous constatera qu'au sein d'une équipe, vous voulez tous effectuer des tâches répétées pendant que vous travaillez. Cela pourrait garantir que les tests et les linters de code passent avant de vous permettre de pousser à l'aide du hook de pré-push, ou d'appliquer une stratégie de dénomination de branche à l'aide du hook de pré-validation. Ici, dans Smashing Magazine, Konstantinos Leimonis a écrit un article intitulé « Comment faciliter le flux de travail de développement de votre équipe avec des crochets Git » qui vise à améliorer le flux de travail à l'aide de crochets Git.

Automatisation manuelle

L'une des les principales fonctions d'automatisation de Git sont git bisect . C'est quelque chose dont beaucoup de gens ont entendu parler mais probablement pas utilisé. Le but est de parcourir l'arbre git (l'historique des validations) et de déterminer où un bug a été introduit. La façon la plus simple de le faire est manuellement; vous exécutez git bisect start donnez-lui les bons et mauvais ID de validation, puis git bisect good ou git bisect bad pour chaque validation.

Ceci est plus puissant qu'il n'y paraît au premier abord car il n'itère pas de manière linéaire dans le journal git, ce que vous pourriez faire manuellement et ce serait un processus répétitif. Au lieu de cela, il utilise une recherche binaire, c'est donc un moyen efficace de parcourir les validations avec le moins d'étapes.

 # Commencez la bissect
git bisect start

# Dit à git quel commit n'a pas le bug
git bissect bon c5ba734

# Dites à git quel commit a le bug
git bisect bad 6c093f4

# Ici, faites votre test pour le bug.
# Cela pourrait être d'exécuter un script, de faire un voyage sur un site Web, un test unitaire, etc.

# Si le commit actuel a un bug:
git bissect bad

# Si le commit actuel n'a pas le bug
git bissect bon

# Cela se répétera jusqu'à ce qu'il trouve le premier commit avec le bogue
# Pour quitter la bissect, soit:

# Retour à la branche d'origine:
git bisect reset

# Ou s'en tenir à la TÊTE actuelle
git bisect reset HEAD

# Ou vous pouvez quitter la bissect à un commit spécifique
git bisect reset

Aller plus loin: automatisation de la méthode scientifique

Dans son exposé « Débogage avec la méthode scientifique », Stuart Halloway a expliqué comment la fonctionnalité de bissecte de Git pouvait être utilisée pour automatiser le débogage. Il se concentre sur Clojure mais vous n'avez pas besoin de connaître cette langue pour trouver la conversation intéressante et utile.

«Git bisect est en fait une automatisation partielle de la méthode scientifique. Vous écrivez un petit programme qui testera quelque chose et git rebondira et coupera le monde en quatre à chaque fois jusqu'à ce qu'il trouve la frontière à laquelle votre test change. »

– Stuart Halloway

Au début, git bissect peut se sentir intéressant et assez cool mais au final pas très utile. Le discours de Stuart montre en grande partie comment il est contre-productif de déboguer comme la plupart d'entre nous le font habituellement. Si, au lieu de cela, vous vous concentrez sur les faits empiriques, que le test réussisse ou non, vous pouvez l'exécuter contre toutes les validations depuis une version de travail et réduire le type de débogage «se sentir dans le noir» auquel nous sommes habitués.

Alors, comment automatiser git bissect? Nous lui transmettons un script à exécuter pour chaque commit approprié. Auparavant, je disais que nous pouvons exécuter manuellement un script à chaque étape de la bissect mais si nous lui passons une commande à exécuter, il exécutera automatiquement le script à chaque étape. Cela pourrait être un script que vous écrivez spécifiquement pour déboguer ce problème particulier, ou ce pourrait être un test (unité, fonctionnel, intégration, tout type de test pourrait être utilisé). Vous pouvez donc écrire un test pour vous assurer que la régression ne se reproduira plus et utiliser ce test lors des validations précédentes.

 # Commencez la bissect
git bisect start

# Dit à git quel commit n'a pas le bug
git bissect bon c5ba734

# Dites à git quel commit a le bug
git bisect bad 6c093f4

# Dites à git d'exécuter un script spécifique sur chaque commit
# Par exemple, vous pouvez exécuter un script spécifique:
git bisect run ./test-bug

# Ou utilisez un lanceur de test
git bisect run jest

On Every Commit In The Past

L'une des forces de git bisect est l'utilisation efficace des recherches binaires pour parcourir l'histoire de manière non linéaire. Cependant, parfois, une analyse linéaire de l'historique est exactement ce dont vous avez besoin. Vous pouvez écrire un script qui lit le journal git et parcourt chaque code d'exécution de validation, mais il existe une commande familière qui peut le faire pour vous git rebase.

Kamran Ahmed a écrit un tweet sur l'utilisation de rebase pour exécuter une suite de tests sur chaque commit pour voir quel commit échoue au test:

Nous avons déjà envisagé d'utiliser git bissect pour le faire efficacement c'est donc généralement plus utile pour ce cas d'utilisation, mais que se passe-t-il si nous pouvions avoir tous les autres cas d'utilisation exécutant un script pour un ensemble de validations donné?

Il y a de la place pour être créatif ici. Peut-être que vous voulez un moyen de générer un rapport sur la façon dont votre code a changé au fil du temps (ou peut-être afficher l'historique des tests) et analyser le journal git n'est pas suffisant. C'est peut-être l'astuce la moins directement utile dans cet article, mais elle est intéressante et soulève la possibilité de faire des choses que nous ne réaliserions peut-être pas.

 # Cela fonctionnera pour chaque validation entre l'actuel et l'ID de validation donné
git rebase -i --exec ./my-script

Lectures complémentaires

Il est impossible de plus que gratter la surface de git dans un article – ce serait un livre! Dans cet article, j'ai choisi de petites astuces qui pourraient être nouvelles même pour quelqu'un qui utilise git depuis des années.

Il y a tellement plus à Git depuis les fondations jusqu'aux scripts complexes, aux configurations précises et à l'intégration dans le terminal, alors ici Voici quelques ressources pour voir si cela a suscité votre intérêt:

Editorial fracassant (ra, il)



Le meilleur outil 2023 pour ta croissance Instagram !



Source link