Comprendre l’historique de Git

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Git stocke l’historique sous la forme d’un graphique d’instantanés, appelé validations, de l’ensemble du référentiel. Chaque validation contient également un pointeur vers une ou plusieurs validations précédentes. Les validations peuvent avoir plusieurs parents, créant un historique qui ressemble à un graphique au lieu d’une ligne droite. Cette différence dans l’histoire est incroyablement importante et est la principale raison pour laquelle les utilisateurs trouvent Git déroutant.

Notes

Si vous ne trouvez pas de modification dans votre historique Git que vous savez avoir fait, découvrez comment la simplification de l’historique Git fonctionne au niveau de Git a perdu mes modifications : en examinant la simplification de l’historique Git.

Notions de base de l’historique des validations

Commencez par un exemple d’historique simple : un référentiel avec 3 validations linéaires.

La validation A est le parent de la validation B et la validation B est le parent de la validation C. Cet historique ressemble beaucoup à un CVCS. La flèche pointant vers la validation C est une branche. Elle est nommée main, car il s’agit du nom par défaut de la branche de ligne principale dans un référentiel Git. Les branches sont des pointeurs vers des validations spécifiques, c’est pourquoi la branche est si légère et facile dans Git.

Une différence essentielle entre Git et CVCS est que je dispose de ma propre copie complète du référentiel. Je dois maintenir la synchronisation de mon référentiel local avec le référentiel distant en obtenant les validations les plus récentes à partir du référentiel distant. Pour ce faire, je vais extraire la branche principale avec la commande suivante :

git pull origin main

Cette opération copie (« extrait ») toutes les validations de la branche main du référentiel distant (appelée origin par défaut) vers la branche main du référentiel local. L’opération de tirage a copié une nouvelle validation, et la branche main dans le référentiel local pointe maintenant vers cette nouvelle validation.

Comprendre l’historique des branches

Maintenant, je veux apporter une modification à mon code. Il est courant d’avoir plusieurs branches actives où vous travaillez sur différentes fonctionnalités en parallèle. Cela contraste fortement avec CVCS où de nouvelles branches sont lourdes et rarement créées. La première étape consiste à passer à une nouvelle branche à l’aide de la commande suivante :

git checkout -b cool-new-feature

Il s’agit d’un raccourci combinant deux commandes : git branch cool-new-feature pour créer la branche suivie de git checkout cool-new-feature pour commencer à travailler dans la branche.

Deux branches pointent maintenant vers la même validation. Je vais apporter quelques modifications à la branche cool-new-feature dans deux nouvelles validations, E et F.

Mes validations sont accessibles par la branche cool-new-feature depuis que je les ai faites dans cette branche. J’ai terminé avec ma fonctionnalité et je veux la fusionner dans main. Pour ce faire, j’utiliserai la commande suivante :

git merge cool-feature main

La structure graphique de l’historique devient visible lorsqu’il existe une fusion. Git crée une validation lorsque j’ai fusionné ma branche dans une autre branche. Il s’agit d’une validation de fusion. Aucune modification n’est incluse dans cette validation de fusion, car je n’ai pas de conflits. Si j’avais des conflits, la validation de fusion inclurait les modifications nécessaires pour résoudre ces conflits.

Histoire dans le monde réel

Voici un exemple d’historique Git qui ressemble plus étroitement au code dans le développement actif sur une équipe. Il y a trois personnes qui fusionnent les validations de leurs propres branches dans la branche principale en même temps.

Maintenant que vous comprenez comment les branches et les fusions créent la forme du graphique, cela ne devrait pas être trop effrayant !