Comment fonctionne Git : instantanés, branches et historique

Comment fonctionne Git : instantanés, branches et historique

Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.

Comment lire ce visuel

• Lisez les trois colonnes de gauche à droite : Modifier, Valider, Partager.
• Les clusters à quatre voies constituent un pipeline : du répertoire de travail vers le transfert vers le local vers le distant ; chaque flèche rapproche le changement d’un pas vers le partage.
• Le message « Deux personnes ont changé les mêmes lignes ? » la décision est la seule branche, et les deux sorties convergent vers l’histoire commune à la fin.

Montage et mise en scène

"Le développeur modifie les fichiers dans le répertoire de travail" est la réalité non validée : les fichiers sur le disque ne font pas encore partie de l'historique. "git add déplace les modifications dans la zone de préparation" est l'étape intermédiaire délibérée : la mise en scène vous permet de créer une validation à partir des modifications sélectionnées plutôt que de tout ce que vous avez touché. Le visuel les sépare dans leurs propres clusters, car c'est la validation en deux étapes qui donne à Git sa précision.

Validation de l'instantané

"git commit instantanés des modifications par étapes" est l'endroit où un changement devient permanent. "Git stocke le commit avec un pointeur vers son parent" rend le graphique explicite : chaque commit (sauf le premier) nomme le commit qui le précède, ce qui rend l'historique uniquement en ajout et auditable. "Le pointeur de branche se déplace vers le nouveau commit" complète l'acte : une branche n'est qu'un pointeur, donc s'engager sur une branche déplace ce pointeur. Rien dans le commit lui-même ne se soucie de la branche sur laquelle il se trouve.

Partager l'historique

"git push envoie les commits au cluster distant" passe du "dépôt local" au cluster "dépôt distant": le seul endroit où les données quittent votre machine. « Le référentiel distant enregistre le nouvel historique » est la copie partagée, et « Deux personnes ont modifié les mêmes lignes ? » modélise la fusion : Git fusionne automatiquement les historiques divergents à moins que les mêmes lignes n'aient été modifiées, auquel cas "Conflit de fusion : le développeur le résout manuellement" rend la décision humaine explicite avant que "L'historique est partagé et à jour" ne ferme le flux.

Relations et enseignements clés

• Un commit est un instantané complet lié à son parent, ce qui fait de l'historique un graphique à ajout uniquement.
• Une branche est un pointeur vers une validation, pas un conteneur de modifications : créer et changer de branche est bon marché pour cette raison.
• La mise en scène est l'étape intermédiaire délibérée qui vous permet de choisir ce que contient un commit.
• Git est distribué : tout le monde détient l'historique complet localement, et le push/pull n'échange que les pièces manquantes.
• Les conflits sont l’exception, pas la règle, et lorsqu’ils surviennent, un humain les résout explicitement.

Quand utiliser ce visuel

• Enseigner le modèle d'instantané à une équipe qui n'a jamais utilisé Git que comme séquence de commandes.
• Expliquer les branches, les fusions et les conflits via le modèle de pointeur plutôt que par des commandes mémorisées.
• Fonder un examen du flux de travail de validation et de branchement d'une équipe sur la façon dont l'historique est réellement structuré.

Comment cela fonctionne

1. Suivez le véritable flux de travail de votre équipe

   Annotez les cases avec les commandes que votre équipe utilise réellement (branches de fonctionnalités, demandes d'extraction, rebase ou fusion) afin que le diagramme documente votre pratique, et non celle d'un manuel.

2. Ajouter le modèle de branche

   Insérez les lignes de branche fonctionnelle et de branche principale dans le cluster de référentiel local et dessinez les flèches de fusion entre elles, se terminant par l'historique partagé.

3. Dessinez la porte de demande de tirage

   Ajoutez une décision entre le push local et l'enregistrement à distance : une révision et une vérification CI qui doivent réussir avant que la branche ne soit fusionnée dans main.

4. Ajouter les chemins de récupération

   Incluez les branches d'annulation (annuler une validation, modifier un message, réinitialiser à un état antérieur) chacune se terminant par un résultat explicite, car la récupération représente la moitié de l'utilisation réelle de Git.

Questions fréquentes

Qu’est-ce que Git et en quoi est-il différent des autres contrôles de version ?

Git est un système de contrôle de version distribué basé sur des instantanés. Chaque commit stocke une image complète du référentiel plus un pointeur vers son parent, plutôt qu'une simple liste de modifications de fichiers. Étant donné que chaque développeur dispose de l'historique complet localement, la plupart des opérations fonctionnent hors ligne et la collaboration consiste à échanger des validations avec des distants.

Qu’est-ce qu’une branche dans Git ?

Une branche est un pointeur mobile vers un commit. Lorsque vous effectuez une validation sur une branche, le pointeur avance vers la nouvelle validation ; le commit lui-même ne sait pas sur quelle branche il se trouve et ne se soucie pas de celle-ci. C'est pourquoi la création d'une branche est instantanée et pourquoi le basculement entre les branches ne modifie que l'instantané affiché par votre répertoire de travail.

Pourquoi Git a-t-il une zone de transit ?

La zone de préparation vous permet de créer délibérément un commit. Vous pouvez modifier plusieurs fichiers, transférer uniquement ceux qui vont ensemble et valider cette sélection, en laissant les travaux non liés non validés. Le répertoire de travail, la zone de préparation et le référentiel sont trois états distincts, qui correspondent exactement au pipeline dessiné par le visuel.

Comment Git résout-il les conflits de fusion ?

Lorsque deux branches modifient des fichiers différents ou des lignes différentes, Git les fusionne automatiquement. Lorsqu'ils modifient les mêmes lignes, Git ne peut pas deviner quelle version est la bonne, il marque donc le conflit et demande à un humain de choisir. Le conflit est une décision, pas un échec, c’est pourquoi le visuel le dirige vers une étape de résolution explicite avant que l’histoire ne soit partagée.

Modifier ce visuel dans QueryChart (FlowJam)

Ouvrez ce canevas Git exact en tant que votre propre graphique, renommez les voies en fonction de votre flux de travail et tracez votre propre historique.

Modifier ce visuel dans QueryChart (FlowJam)