Comprendre l'historique de Git

Git représente l’historique d’une manière fondamentalement différente des systèmes de contrôles de version centralisés (CVCS) tels que Team Foundation Version Control, Perforce ou Subversion. Les systèmes centralisés stockent un historique distinct pour chaque fichier d’un dépôt. Git stocke l’historique sous forme de graphique d’instantanés de l’ensemble du dépôt. Ces instantanés, appelés validations dans Git, peuvent avoir plusieurs parents, créant un historique qui ressemble à un graphique au lieu d’une ligne droite. Cette différence dans l’historique est incroyablement importante et est la principale raison pour laquelle les utilisateurs familiers avec CVCS trouvent Git déroutant.

Notions de base de l’historique des validations

Commencez par un exemple d’historique simple : un dépôt avec trois 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. 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 clé dans Git par rapport à CVCS est que le développeur a sa propre copie complète du dépôt. Ils doivent garder leur dépôt local synchronisé avec le dépôt distant en obtenant les dernières validations du dépôt distant. Pour ce faire, ils tirent la branche principale avec la commande suivante :

git pull origin main

Cela fusionne toutes les modifications de la branche principale dans le dépôt distant, que Git nomme origin par défaut. Cette extraction a apporté une nouvelle validation et la branche principale dans le dépôt local passe à cette validation.

Comprendre l’historique des branches

Maintenant, il est temps d’apporter une modification au code. Il est courant d’avoir plusieurs branches actives lorsque 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
• git checkout cool-new-feature pour commencer à travailler dans la branche

Deux branches pointent maintenant vers la même validation. Supposons qu’il y ait quelques modifications sur la cool-new-feature branche dans deux nouvelles validations, E et F.

Les validations sont accessibles par la cool-new-feature branche, car elles ont été validées dans cette branche. Maintenant que la fonctionnalité est terminée, elle doit être fusionnée dans la branche principale. Pour ce faire, utiliser la commande suivante :

git merge cool-new-feature main

La structure graphique de l’historique devient visible lorsqu’il existe une fusion. Git crée une validation lorsque la branche est fusionnée dans une autre branche. Il s’agit d’une validation de fusion. Il n’y a pas de modifications incluses dans cette validation de fusion car il n’y a pas eu de conflits. S’il y avait des conflits, la validation de fusion inclurait les modifications nécessaires pour les résoudre.

Histoire dans le monde réel

Voici un exemple d’historique Git qui ressemble davantage au code en développement actif au sein d’une équipe. Il y a trois personnes qui fusionnent les validations de leurs propres branches dans la main branche à peu près au même moment.

Étapes suivantes

En savoir plus sur l’utilisation de l’historique Git dans GitHub et Azure Repos ou la simplification de l’historique des journaux Git.