Name: Tremplin Numérique
Price range: $$$

Le programme git prend en charge tellement de sous-commandes qu'il est presque impossible de toutes les maîtriser. La plupart d’entre eux sont de bas niveau et effectuent des tâches simples comme valider des modifications de code ou changer de branche. Mais certains des plus obscurs offrent des fonctionnalités surprenantes qui dépassent largement la norme.

Sommaire

git blâme : découvrez qui a changé quoi

Personnellement, je pense que git blâme pourrait utiliser un nom plus positif : git credit, peut-être ? Quoi qu'il en soit, quelle que soit la manière dont vous choisissez de l'utiliser, cette commande vous indiquera exactement qui est responsable de chaque ligne de code dans un fichier :

Ce que vous verrez par défaut, ce sont chaque ligne de votre fichier, précédée des détails du dernier commit qui l'a modifié. Ces détails incluent l'ID de validation, la date et l'heure de cette validation, ainsi que l'auteur qui a effectué cette modification.

Si vous travaillez sur un projet plus vaste avec de nombreux contributeurs, cela peut être un moyen précieux de suivre des modifications de code spécifiques. Vous pouvez l'utiliser pour découvrir pourquoi quelqu'un les a créés, ou consulter sur une éventuelle mise à jour.

Blame est une fonctionnalité également prise en charge par GitHub : accédez à n'importe quel fichier individuel et vous verrez un onglet « Blame » à côté de la valeur par défaut, « Code : »

Notez que GitHub code utilement les validations par âge afin que vous puissiez rapidement parcourir la liste et trouver les modifications récentes.

git archive : package à partir de n'importe quel moment de l'historique

Travailler avec un projet Git implique généralement le clonage de référentiels, l'extraction de branches et la validation des modifications. Mais parfois, vous souhaitez travailler uniquement avec les fichiers du projet : lorsque vous exécutez une démo ou effectuez des tests occasionnels, par exemple.

La commande git archive vous offre une collection propre de fichiers de projet, sans rien lié à Git, à n'importe quel point de validation de votre référentiel :

git archive HEAD

Cette commande affiche le contenu de tous les fichiers de la branche actuelle, au format tar. Vous souhaiterez probablement enregistrer cette sortie, et il existe deux façons de le faire. Vous pouvez utiliser la redirection de fichier shell pour envoyer la sortie vers un fichier :

git archive HEAD > project.tar

Vous pouvez également utiliser l'option –output pour envoyer la sortie vers un fichier nommé :

git archive --output=project.tar HEAD

Le principal avantage de cette approche est que Git sélectionnera intelligemment le format en fonction de votre nom de fichier. Par défaut, il sera affiché au format tar, mais il en prend en charge d'autres, comme .tar.gz et zip :

git archive --output=project.zip 428d235

N'oubliez pas de spécifier le commit souhaité à l'aide d'un pointeur tel que HEAD, d'un ID de balise ou d'un ID de commit. Vous pouvez même passer un sous-répertoire pour archiver juste une partie de votre projet :

git archive --output=project.tar.gz v1.1 docs

Dans un certain sens, la commande git archive est anti-magique : elle supprime toutes les données magiques Git de votre référentiel, les convertissant en un simple ensemble de fichiers. Mais créer une archive instantanée de votre projet à partir de n’importe quel moment de son histoire est une astuce assez spéciale à mon avis.

git stash : enregistre les modifications sans les valider

À maintes reprises, j'ai été confronté à cette situation : vous êtes occupé à travailler sur une branche, puis quelque chose d'autre nécessite votre attention. Il s'agit peut-être d'une fonctionnalité qui doit être peaufinée ou d'une branche qui nécessite une correction rapide d'un bug. Vous avez enregistré vos fichiers, mais changer de branche maintenant supprimera ces modifications.

Quand je ne savais pas mieux, j'enregistrais généralement mes modifications, dans l'espoir de nettoyer l'historique des validations plus tard (et échouais probablement). Mais cela nécessite beaucoup d’administration et laisse le référentiel dans un état désordonné, même si ce n’est que pour une brève période. Mais maintenant je connais git stash :

Une fois que vous avez exécuté git stash, vous vous retrouverez avec un arbre de travail propre, vous pourrez donc changer de branche en toute sécurité et travailler sur autre chose. Lorsque vous êtes prêt à revenir, vous pouvez restaurer vos fichiers :

git stash pop

Comme par magie, vos fichiers sont de retour, avec toutes les modifications que vous avez apportées prêtes à être archivées. Le nom de cette commande reflète la nature de la réserve basée sur la pile. Si vous devez stocker plusieurs fois, vos modifications seront enregistrées sur une pile, de sorte que le stockage le plus récent sera renvoyé lorsque vous en demanderez un.

git grep : recherchez votre base de code dans toutes les branches

La sous-commande git grep recherche dans les fichiers et imprime les lignes qui correspondent à un modèle. Cela peut ne pas sembler très impressionnant au début ; après tout, n'est-ce pas exactement ce que fait grep ? Ce qui est magique, c'est la façon dont Git intègre cette alternative grep.

Par défaut, git grep recherche dans tous les fichiers suivis de votre arborescence de travail. C'est la principale différence entre la commande grep standard et la version Git : grep recherche les fichiers, tandis que git grep recherche le contenu des fichiers qui ont été validés dans votre référentiel.

Par défaut, git grep recherche la version actuelle du référentiel dans votre arborescence de travail. Mais vous pouvez également rechercher le contenu d'autres branches ou du référentiel lors d'un commit spécifique :

git grep TODO 4415c19

Sans git grep, vous devrez vérifier la révision spécifique avant de la rechercher et prendre en compte les fichiers ignorés, les fichiers non suivis et la récursivité. Vous pouvez même effectuer une recherche dans plusieurs révisions, y compris dans tout l'historique de votre dépôt, si vous vous sentez courageux :

git grep strcat $(git rev-list --all)

git worktree : travailler sur le même référentiel plusieurs fois

Si vous pensiez que git stash était bon, voici quelque chose d'encore mieux : git worktree. Bien que le stockage soit acceptable pour un travail à court terme, cela peut devenir gênant si vous travaillez sur des fichiers sur une période plus longue ou à partir de plusieurs branches différentes à la fois.

La fonctionnalité Worktree offre un moyen plus permanent de travailler simultanément sur plusieurs branches. Pour ce faire, il vous donne un dossier de travail supplémentaire : c'est-à-dire une autre collection de fichiers du référentiel.

Comme pour la plupart des fonctionnalités de Git, vous pouvez adapter les arbres de travail en fonction de votre processus, mais voici un exemple simple de comment démarrer :

git worktree add

Dans un référentiel existant, utilisez la sous-commande worktree pour créer un nouveau répertoire attaché à une branche spécifique. La dernière partie de votre chemin sera utilisée pour le nom de la branche, qui peut être une branche existante :

Toutes les branches extraites dans les arbres de travail liés seront mises en évidence en cyan et marquées d'un signe plus :

Vous pouvez alors travailler dans chaque répertoire, sur des branches spécifiques, sans avoir à basculer continuellement entre elles, ce qui rend les arbres de travail parfaits pour les multitâches.