Commande git log avancée

Ainsi, vous pouvez vérifier que le commit du dessus a aussi été extrait (marqué par HEAD) et qu'il se situe à la pointe de la branche main. Le deuxième commit comporte une autre branche qui pointe dans sa direction, nommée feature. Enfin, le quatrième commit est marqué comme v0.9.

Les branches, les tags, HEAD et l'historique des commits constituent la grande majorité des informations contenues dans votre dépôt Git. Ainsi, vous avez une vision plus détaillée de la structure logique de votre dépôt.

La commande git log comporte de nombreuses fonctionnalités servant à afficher les différences pour chaque commit. Deux des options les plus courantes sont --stat et -p.

L'option --stat affiche le nombre d'ajouts et de suppressions effectués dans chaque fichier modifié par chaque commit (remarque : la modification d'une ligne est considérée à la fois comme un ajout et une suppression). Cette fonctionnalité est utile lorsque vous souhaitez obtenir un bref résumé des changements apportés par chaque commit. Par exemple, le commit suivant a ajouté 67 lignes au fichier hello.py et en a supprimé 38 :

Le nombre de signes + et - situés en regard du nom du fichier indique le nombre relatif de changements apportés à chaque fichier modifié par le commit. Vous obtenez ainsi un aperçu de l'emplacement des changements associés à chaque commit.

Si vous souhaitez consulter les changements réellement apportés par chaque commit, ajoutez l'option -p à git log. De cette manière, vous générez le patch entier qui représente ce commit :

La commande git shortlog constitue une version spécifique de git log destinée à créer des annonces de livraison. Elle regroupe les commits par auteur et affiche la première ligne de chaque message de commit. C'est une manière simple de voir qui a travaillé dessus.

Par exemple, si deux développeurs ont ajouté cinq commits à un projet, la sortie de git shortlog devrait se présenter comme suit :

Par défaut, la commande git shortlog trie les sorties par nom d'auteur, mais il vous est également possible d'ajouter l'option -n pour les trier selon le nombre de commits par auteur.

L'option --graph crée un graphique ASCII représentant la structure de branche de l'historique des commits. Elle est souvent utilisée en association avec les commandes --oneline et --decorate pour mieux visualiser à quelle branche un commit est associé, et vice versa :

Pour un dépôt simple qui ne comprend que deux branches, cette commande aura le résultat suivant :

L'astérisque indique la branche sur laquelle le commit était situé. Ainsi, le graphique ci-dessus nous apprend que les commits 23ad9ad et 16b36c6 sont sur une branche topic et que les autres se trouvent sur la branche main.

Si cette option est pratique en cas de dépôts simples, il est préférable d'utiliser un outil de visualisation plus complet comme gitk ou Sourcetree si vous travaillez sur des projets contenant beaucoup de branches.

Pour tous vos autres besoins de formatage git log, vous pouvez utiliser l'option --pretty=format:"". Vous pourrez ainsi afficher les commits au format de votre choix en utilisant des caractères génériques de type printf.

Par exemple, les caractères %cn, %h et %cd de la commande suivante sont respectivement remplacés par le nom du commiteur, l'empreinte abrégée du commit et la date du commiteur.

Le format de chaque commit sera donc le suivant :

Consultez la liste complète des caractères génériques dans la section Formats utiles de la page consacrée à git log.

L'option --pretty=format:"" vous permet non seulement d'accéder aux informations qui vous intéressent, mais elle est particulièrement utile lorsque vous souhaitez ajouter la sortie git log à une autre commande.

Maintenant que le formatage des commits n'a plus de secrets pour vous, vous avez parcouru la moitié du chemin pour connaître git log. Il ne vous reste plus qu'à apprendre à naviguer dans l'historique des commits. Le reste de cet article présente quelques fonctionnalités avancées de la commande git log qui vous permettent de sélectionner des commits spécifiques dans votre historique de projet. Toutes ces fonctionnalités peuvent être combinées avec chacune des options de formatage décrites ci-dessus.

Si vous recherchez un commit correspondant à une période précise, utilisez le flag --after ou --before pour filtrer les commits par date. Ces deux flags peuvent être paramétrés selon toutes sortes de formats de date. Par exemple, la commande suivante n'affiche que les commits créés après le 1er juillet 2014 (inclus) :

Vous pouvez y ajouter des références relatives, comme « il y a une semaine » et « hier » :

Pour rechercher des commits créés entre deux dates précises, indiquez les dates --before et --after. Par exemple, pour afficher tous les commits ajoutés entre le 1er et le 4 juillet 2014, exécutez la commande suivante :

Si vous recherchez uniquement des commits créés par un utilisateur en particulier, utilisez le flag --author. Celui-ci peut être défini dans une expression régulière. Il renvoie tous les commits dont l'auteur correspond au modèle. Si vous savez exactement quel utilisateur vous cherchez, utilisez une bête chaîne de caractères brute plutôt qu'une expression régulière.

Cela affiche tous les commits dont l'auteur inclut le nom John. Le nom de l'auteur ne doit pas correspondre exactement, il doit juste contenir la phrase spécifiée.

Vous pouvez également utiliser des expressions régulières pour créer des recherches plus complexes. Par exemple, la commande suivante recherche les commits par Marie ou Jean.

Notez que l'adresse e-mail de l'auteur est également incluse avec son nom. Vous pouvez donc utiliser cette option pour faire une recherche par adresse e-mail.

Si votre workflow fait la distinction entre les commiteurs et les auteurs, le flag --committer opérera de la même façon.

Pour filtrer les commits en fonction de leur message, utilisez le flag --grep. Celui-ci fonctionne exactement comme le flag --author mentionné ci-dessus, à cela près qu'il se base sur les messages de commit plutôt que sur les auteurs.

Par exemple, si votre équipe inclut des numéros de ticket correspondants dans chaque message de commit, vous pouvez utiliser une commande similaire à celle qui suit pour faire un pull de tous les commits liés à ce ticket :

Il vous est également possible d'ajouter le paramètre -i à git log pour que la commande ignore les différences de casse lorsque les modèles correspondent.

La plupart du temps, seuls les changements apportés à un fichier en particulier vous intéresseront. Pour afficher l'historique relatif à un fichier, il vous suffit d'ajouter le chemin d'accès. Par exemple, la commande suivante renvoie tous les commits qui affectaient soit le fichier foo.py ou bar.py :

Le paramètre -- permet de signaler à git log que les arguments ultérieurs sont des chemins d'accès, et non des noms de branches. Si aucune confusion avec une branche n'est possible, vous pouvez omettre --.

Il est également possible de rechercher des commits qui ajoutent ou suppriment une ligne de code source en particulier. Cet outil est appelé pioche, et il se présente sous la forme de -S"". Par exemple, si vous voulez savoir quand la chaîne Hello, World! a été ajoutée à un fichier du projet, utilisez la commande suivante :

Si vous souhaitez effectuer une recherche en utilisant une expression régulière plutôt qu'une chaîne, optez pour le flag -G"".

Il s'agit d'un outil de débogage très puissant qui vous permet de localiser tous les commits qui impactent une ligne de code spécifique. Vous pouvez également voir à quel moment une ligne a été copiée ou déplacée vers un autre fichier.

Ajoutez une plage de commits à git log pour n'afficher que les commits qui font partie de cette plage. La plage est spécifiée au format suivant, où et sont des références de commit :

Cette commande est particulièrement utile lorsque vous utilisez des références de branche en tant que paramètres. Il s'agit d'un moyen simple d'afficher les différences entre deux branches. Voyez la commande suivante :

La plage main..feature contient tous les commits qui se trouvent dans la branche feature, mais qui ne sont pas dans la branche main. En d'autres termes, il s'agit du niveau d'avancement de feature depuis la création d'un fork à partir de main. Ceci peut être visualisé comme suit :

Remarque : si vous changez l'ordre de la plage (feature..main), tous les commits apparaîtront dans main, mais pas dans feature. Si git log génère des commits pour les deux versions, cela signifie que votre historique a divergé.

Par défaut, la sortie de git log comporte des commits de merge. Cependant, si votre équipe est partisane du merge à tout prix (en d'autres termes, vous faites des merges des changements en amont dans des branches topic plutôt que de rebaser la branche topic sur la branche en amont), votre historique de projet comportera de nombreux commits de merge extérieurs.

Empêchez git log d'afficher ces commits de merge en ajoutant le flag --no-merges :

D'un autre côté, si seuls les commits de merge vous intéressent, utilisez le flag --merges :

Ceci renvoie tous les commits qui ont au moins deux parents.

À présent, vous ne devriez avoir aucun mal à utiliser les paramètres avancés de git log pour formater sa sortie et choisir les commits à afficher. Ainsi, vous avez les clés pour extraire des éléments précis de votre historique de projet.

Ces nouvelles connaissances constituent un volet important de votre champ de compétences Git. Souvenez-vous cependant que git log est souvent utilisée conjointement avec d'autres commandes Git. Une fois que vous aurez trouvé le commit que vous cherchiez, vous l'ajouterez généralement à git checkout, git revert ou à tout autre outil vous permettant de gérer votre historique de commits. Veillez donc à mettre vos connaissances à jour concernant les fonctionnalités avancées de Git.