Effectuer l’analyse comparative des dépôts locaux et distants
Git est un système distribué où le code source est situé sur la machine de chaque développeur. Cela inclut l’historique complet avec toutes les validations effectués sur un projet donné. C’est ce qu’on appelle un dépôt local.
Il permet au développeur de travailler dans son propre environnement isolé sans craindre que quelqu’un ne casse son code lorsqu’il est en train de développer une fonctionnalité. Il vous permet également de comparer du code aux versions précédentes, restaurer du code, fusionner du code, etc. Vous pouvez même le faire sans connexion réseau.
La plupart du travail qu’un développeur réalise avec Git est effectué sur un dépôt local. Git prend en charge (et facilite) le branchement. Le branchement sera abordé dans un module distinct, mais la plupart des branches sont également créées sur un dépôt local.
Dans une phase ultérieure, vous devrez partager vos modifications ou nouvelles fonctionnalités avec l’équipe de développement. Par conséquent, Git utilise un dépôt distant. Un dépôt local peut également être associé à plusieurs dépôts distants si nécessaire. Le dépôt distant permet non seulement de partager facilement du code avec d’autres membres de l’équipe, mais aussi de configurer des pipelines de build. Ces pipelines créent le code qui est transmis au dépôt distant. Une transmission peut être le déclencheur pour démarrer le pipeline.
Dépôt local
Dans le dépôt local, nous pouvons distinguer trois zones ou répertoires différent(e)s :
Répertoire de travail : il s’agit d’une extraction unique d’une version du code. Le répertoire de travail contient le code que vous utilisez activement. Vous pouvez modifier les fichiers à l’aide de la commande checkout. Chaque fois que vous modifiez la branche de travail active, les fichiers de votre répertoire de travail sont modifiés pour ressembler à la version spécifique du code. Les fichiers que vous pouvez voir dans votre Explorateur Windows sont des fichiers du répertoire de travail.
Zone d’indexation : cette zone est utilisée comme zone entre votre répertoire de travail et le répertoire Git. Avant de pouvoir valider un fichier du répertoire de travail dans le répertoire Git, vous devez d’abord indexer ce fichier. Le fichier tel quel est alors marqué pour la prochaine validation. Vous pouvez continuer à utiliser le fichier. Aucune modification apportée à ce fichier et non indexée n’est ajoutée lors de la prochaine validation. Seul le contenu du fichier indexé est ajouté. Ceci est utile si vous travaillez sur une fonctionnalité, mais que vous n’avez pas encore complètement terminé votre travail. Vous pouvez indexer vos modifications et continuer à travailler. Si vous devez effectuer une validation en fin de journée, vous pouvez toujours valider une version de travail (la version de la zone d’indexation), sans risquer de valider un fichier à moitié développé.
Répertoire Git : le répertoire Git contient toutes les métadonnées et la base de données d’objets. Chaque fichier que vous validez dans le répertoire Git y est stocké. Si vous activez l’option Éléments masqués dans l’Explorateur Windows, un dossier .git s’affiche. Ce dossier contient des sous-dossiers avec les objets, mais aussi avec des informations de pointeur. Si vous supprimez ce dossier, votre dépôt Git local disparaît. Cela facilite également la sauvegarde de votre dépôt local sur une clé USB afin de pouvoir l’emporter avec vous et l’utiliser sur d’autres ordinateurs. Ne jouez pas avec ce répertoire, sinon votre dépôt local risque de ne plus fonctionner correctement. Il s’agit également du répertoire qui permet d’effectuer une synchronisation avec le dépôt distant.
Avec cette configuration, le statut d’un fichier dans Git peut être l’un des trois suivants :
Non modifié et stocké dans le répertoire Git : le fichier est validé.
Modifié et dans la zone d’indexation : le fichier est indexé.
Modifié et hors de la zone d’indexation : le fichier est modifié.
Cycle de vie des fichiers Git
Le schéma suivant présente le cycle de vie complet d’un fichier. La première fois qu’un nouveau fichier est créé ou ajouté à un dossier dans votre Explorateur Windows, le fichier se voit affecter le statut non suivi. Ce fichier ne fait pas partie du cycle de vie Git. Utilisez la commande add pour ajouter ce fichier à la zone d’indexation, où il deviendra indexé. Plus tard, vous pourrez utiliser la commande commit pour ajouter le fichier au répertoire Git. Ensuite, le fichier se voit affecter le statut non modifié. Chaque fois que vous modifiez un fichier, il se voit affecter le statut modifié ou non suivi lorsque vous le supprimez du répertoire Git. Utilisez la commande rm pour supprimer un fichier. La suppression d’un fichier du répertoire Git ne signifie pas qu’il est également supprimé sur le disque. Il s’agit d’une action que vous devez effectuer manuellement en tant que développeur.
Dépôt distant
Le dépôt distant est ensuite utilisé au moyen des commandes push et pull pour effectuer une synchronisation avec votre dépôt local. Ainsi, même lorsque vous partagez du code ou recevez des mises à jour de votre équipe, cela se fait à partir de commandes qui mettent à jour votre dépôt local. Comme chaque dépôt est autonome, son propriétaire est chargé de le tenir à jour avec les modifications des autres.
Le schéma suivant illustre comment deux développeurs peuvent utiliser le dépôt distant pour partager des modifications. Le développeur A valide des modifications dans le dépôt local, puis utilise la commande push pour les charger dans le dépôt distant. Le développeur B peut utiliser la commande pull pour les télécharger et peut transmettre des modifications.
