Comprendre l’historique 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 référentiel. Git stocke l’historique sous forme de graphique d’instantanés de l’ensemble du référentiel. Ces captures instantanées, appelées 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’histoire est incroyablement importante et est la principale raison pour laquelle les utilisateurs familiarisés 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 maintenir la synchronisation de leur 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, ils extrayent la branche principale avec la commande suivante :

git pull origin main

Cela fusionne toutes les modifications de la branche principale dans le référentiel distant, que Git nomme origin par défaut. Cette commande a ajouté un nouveau commit et la branche principale dans le dépôt local se déplace vers ce commit.

Comprendre l’historique des branches

Maintenant, il est temps d’apporter une modification au code. Il est courant d’avoir plusieurs branches actives lors de l’utilisation de 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 succursale

Deux branches pointent maintenant vers la même validation. Supposons qu’il existe quelques modifications sur la branche cool-new-feature dans deux nouveaux commits, 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, utilisez la commande suivante :

git merge cool-new-feature main

Fusionner une branche

La structure graphique de l’historique devient visible lorsqu’il existe une fusion. Git crée un commit lorsque la branche est fusionnée avec une autre branche. Il s’agit d’une validation de fusion. Aucune modification n’a été apportée à cette validation de fusion, car il n’y avait pas de conflits. En cas de conflit, 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 plus étroitement au code dans le développement actif d’une équipe. Il y a trois personnes qui fusionnent des commits de leurs propres branches dans la branche main autour de la même période.

É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.