Comprendre la simplification de l’historique Git

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

La simplification de l'historique Git peut être un véritable casse-tête. 99% du temps, vous ne saurez même pas qu'il existe, mais parfois, il sautera des coins sombres de Git et vous mordra. Dans cet article, nous allons explorer la simplification de l’historique et comment cela peut entraîner une confusion lors de l’analyse de l’historique des fichiers.

Commençons par un scénario courant :

1. Vous envoyez une modification à un fichier, puis fusionnez la modification en principal.
2. Certains de vos collègues fusionnent également leurs branches vers la branche principale.
3. Vous revenez un peu plus tard et remarquez que vos modifications sont manquantes.
4. Vous recherchez le coupable, vous allez regarder l’historique des fichiers et remarquer... vos modifications ne sont même pas répertoriées !?

L’historique des validations Git est une arborescence. Parfois, l’historique chronologique n’est pas identique à l’historique réel de l’arborescence de fichiers. Cette situation se produit le plus souvent lorsqu’une validation de fusion rétablit un fichier à son état d’origine. Dans ce cas, la vue d’historique par défaut n’affiche pas réellement toutes les modifications, car techniquement le fichier n’a pas changé. Dans ce scénario, Git réalise qu’il peut simplifier l’historique et les « modifications » que vous recherchez probablement sont supprimés du journal.

À moins que vous ne l'ayez déjà rencontré, vous serez peut-être frustré, en vous demandant Où sont passés mes changements ?

Simplification de l’historique : activé par défaut

Par défaut, l’exécution de la commande de journal sur un fichier git log file.txt simplifie automatiquement l’historique, en masquant éventuellement certaines validations de sa sortie. Pour plus d’informations, consultez la page de manuel git log.

Ce qui ajoute à la confusion, c'est que la simplification de l'historique ne se produit pas si vous exécutez simplement git log. En effet, comme vous examinez tous les changements, il n’y a rien à simplifier.

Pour désactiver la simplification de l’historique, vous devez utiliser le commutateur --full-historyde ligne de commande.

Exemple de simplification de l’histoire

Pour mieux comprendre le fonctionnement de la simplification, nous créons notre propre exemple de simplification de l’histoire. Tout d’abord, examinons un diagramme de l’historique que nous allons créer :

Comme vous pouvez le voir, nous allons :

1. Créez un fichier.
2. Ajoutez une ligne à ce fichier dans une branche (animaux).
3. Ajoutez une autre ligne à ce fichier dans une autre branche (fruit).
4. Fusionner la branche animaux avec la branche principale.
5. Fusionnez la branche fruit dans la branche principale, puis prenez la copie complète du fichier à partir de la branche fruit.
6. Vérifiez l’historique du fichier.

Git va simplifier l’historique pour nous. L’étape 5 est la clé ici. Nous avons ignoré tous les changements de la branche animal . Git remarquera que notre fichier n’a pas changé essentiellement entre l’étape 1 et l’étape 5. Il ne nous affichera donc que deux entrées d’historique.

Tout d’abord, nous créons le fichier et l’ajoutons à notre dépôt :

> cd sample
> git init
> echo "some content" > test.txt
> git add test.txt
> git commit -m "Initial commit"

Nous décidons maintenant d’ajouter le texte « ânes » au fichier dans une branche animale :

> git checkout -b animals
> echo "donkeys" >> test.txt
> git commit -am "We have added an animal"

Alors que nous expérimentons, nous décidons peut-être d’aller avec des fruits dans notre fichier à la place, donc nous créons une branche différente et ajoutons le texte « bananes » à la fin du fichier à la place :

> git checkout main -b fruit
> echo "bananas" >> test.txt
> git commit -am "We have added a fruit"

Se sentant satisfait de nos changements, nous décidons de fusionner notre branche animale en main :

> git checkout main
> git merge animals

Examinons maintenant le journal de notre test.txt fichier :

> git log test.txt
    
    commit 6b33d99b996c430a60c9552b79245d1aa8320339
        Date:   Mon Feb 15 10:45:33 2016 -0500

        We have added an animal

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

Jusqu'ici tout va bien, n'est-ce pas ? Rien ne paraît hors de l’ordinaire dans notre journal de log. Maintenant, supposons que nous avons changé d’avis et avons décidé de fusionner notre branche fruitière :

>git merge fruit
    
    Auto-merging test.txt
    CONFLICT (content): Merge conflict in test.txt
    Automatic merge failed; fix conflicts and then commit the result.

Uh-oh, un conflit de fusion. Après quelques considérations, nous décidons d’utiliser l’intégralité test.txt du fichier de notre branche fruitière. En règle générale, vous utiliseriez un type d’éditeur de texte ou d’outil de fusion, mais nous allons simplement recréer l’intégralité du fichier, car il ne s’agit que de deux lignes :

> echo "some content" > test.txt
> echo "bananas" >> test.txt
> git commit -am "Fixed merge conflict"

Examinons maintenant l’historique de notre test.txt fichier :

> git log test.txt
    
    commit fdd4dfd816c4efebc5bdb240f49e934e299db581
        Date:   Mon Feb 15 10:51:06 2016 -0500

        We have added a fruit

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

Bien sûr, nous ne voyons aucune modification de notre première expérience dans le fichier journal, ni notre fusion ! Sont-ils toujours là ? Git a-t-il complètement éliminé les modifications ?

> git log --full-history test.txt

Comme vous pouvez le voir, même s’il a simplifié le journal sans l’indicateur full-history , Git a conservé toutes nos modifications :

> commit 5d0bb77a24e265dc154654fb3b5be331b53bf977
    Merge: 6b33d99 fdd4dfd
        Date:   Mon Feb 15 10:59:34 2016 -0500

        Fixed merge conflict

    commit fdd4dfd816c4efebc5bdb240f49e934e299db581
        Date:   Mon Feb 15 10:51:06 2016 -0500

        We have added a fruit

    commit 6b33d99b996c430a60c9552b79245d1aa8320339
        Date:   Mon Feb 15 10:45:33 2016 -0500

        We have added an animal

    commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
        Date:   Mon Feb 15 10:44:18 2016 -0500

        Initial commit

Résumé de la simplification de l’historique Git

La chose à propos de la simplification de l’histoire est que la plupart du temps vous ne le remarquerez jamais. Mais quand un conflit de fusion se produit mal et que vous souhaitez savoir ce qui s’est passé, vous pouvez vous retrouver à regarder l’historique des journaux Git et vous demander où vos modifications sont passées.

Maintenant, au lieu de paniquer, vous savez que :

• La simplification de l’historique pour les fichiers est activée par défaut
• L’indicateur --full-history vous donnera un historique de fichiers plus complet

Mise à jour : Depuis que j’ai écrit cet article, Azure DevOps Services a introduit un certain nombre d’options d’affichage d’historique impressionnantes sur le web. Cela signifie que si vous ne souhaitez pas parcourir la ligne de commande, vous pouvez simplement extraire le fichier pour lequel vous souhaitez afficher l’historique dans notre Explorateur et vous serez présenté avec le filtre d’historique ci-dessous dans lequel vous pouvez spécifier des vues d’historique simples ou non simples :

(c) 2016 Microsoft Corporation. Tous droits réservés. Ce document est fourni «as-is». Les informations et les vues exprimées dans ce document, y compris l’URL et d’autres références de site Web Internet, peuvent changer sans préavis. Vous risquez de l’utiliser.

Ce document ne vous donne aucun droit légal sur aucune propriété intellectuelle dans les produits Microsoft. Vous pouvez copier et utiliser ce document pour votre information uniquement.