Structure d'un référentiel Git

Désolé s'il s'agit d'un doublon, j'ai regardé.

Nous déménageons à Git. Dans Subversion, j'ai l'habitude d'avoir des dossiers \ trunk, \ branches et \ tags.

Avec Git, le basculement entre les branches remplacera le contenu du répertoire de travail, donc ai-je raison de supposer que la façon dont nous travaillions ne s'applique tout simplement pas avec Git?

Je suppose que j'aurais un dossier de dépôt avec peut-être un gitignore et un fichier readme.txt, puis les dossiers des projets qui composent le dépôt, et c'est tout.

Vous aurez "tronc", maintenant appelé "maître", vous aurez "branches" maintenant appelé "têtes" et vous aurez "balises", encore appelées "balises", mais elles ne seront pas des dossiers , elles seront " refs ", les libellés des révisions qui vivent dans un espace de noms distinct à l'intérieur du référentiel.

Subversion et Git ont différentes façons de créer des branches. Le modèle de subversion de base consiste à avoir une arborescence de répertoires avec une seule chronologie globale et si vous souhaitez créer une branche, vous copiez une sous-arborescence dans un autre répertoire.

D'un autre côté, Git a une arborescence de répertoires avec des révisions qui définissent chacune ses parents, mais chaque révision peut avoir plusieurs parents (une fusion) et plusieurs enfants (branches). Ainsi, au lieu d'avoir des répertoires pour les branches, vous obtenez des révisions créées indépendamment. Les "refs" ne sont que des noms associés à la dernière révision pour une "branche" donnée.

Cette différence est fondamentale pour le contrôle de version distribué. Git (et d'autres systèmes distribués) ne dispose d'aucune autorité centrale pour maintenir l'historique linéaire, de sorte que les révisions peuvent être créées indépendamment sur plusieurs référentiels sans se connaître et que le système doit les prendre en compte. Il s'avère que la généralisation rend la ramification et la fusion beaucoup plus faciles en général.

Notez que dans Git, les révisions ne concernent aucune branche. Ils sont juste et les branches les contiennent. Mais une fois que la branche est fusionnée, ou s'avère être une allée morte, vous pouvez simplement supprimer le "ref" qui la pointe et l'oublier complètement (si vous jetez les anciens essais, ils seront éventuellement récupérés avec git gc). Cela vous aide à éviter d'être submergé par de vieilles expériences dont personne ne se souvient plus de quoi il s'agissait.

Pensez simplement à Git comme une vue 3D des mêmes données que vous voyez en 2D dans SVN - c'est-à-dire qu'avec SVN vous branchez votre racine et elle apparaît comme une copie montrée comme un nouveau dossier dans l'arborescence. Avec Git, lorsque vous vous branchez, il apparaît comme une copie montrée comme une "couche" au-dessus de votre arbre existant. Une fois que vous vous rendez compte que c'est assez facile de conceptualiser la différence.

Avec SVN, vous pouvez toujours travailler de la même manière que Git - le commutateur entre les branches remplacera la vue unique de la base de code par la vue ramifiée, ceci s'applique que vous utilisiez le commutateur svn ou la vérification de git.

Évidemment, vous pouvez obtenir une copie d'une branche dans SVN en extrayant la branche vers son emplacement de dossier, ce qui revient à cloner un dépôt git vers un emplacement différent sur votre disque.

Il en va de même pour les balises - vous pouvez étiqueter une révision git, ou vous pouvez créer une branche pour une version. Les balises SVN sont les mêmes que les branches, sa seule convention qu'elles sont appelées «balises». Vous pouvez également étiqueter (enfin, enregistrer le numéro de révision) d'un dépôt SVN pour obtenir également un instantané d'une version.

Les différences entre git et svn sont davantage liées à la façon dont les enregistrements et les extractions se produisent, pas aux principes fondamentaux du contrôle des sources. La vue du code peut être différente (vous ne verrez jamais une seule vue de l'arborescence de code qui inclut des branches dans git, et vous pouvez brancher un référentiel partiel dans SVN, mais ce sont finalement des différences mineures)