Que signifient ces mots dans Git: Repository, fork, branch, clone, track?

130

Je ne suis honnêtement pas clair sur la sémantique ici. Ils concernent tous des copies / variantes d'une unité de code + historique, mais après cela, je ne suis pas sûr de pouvoir le dire. Cette structure logique est-elle expliquée quelque part?

git branch clone Eric Anderson
la source
5
Je recommanderais de lire les deux premiers chapitres du livre Pro Git ( progit.org/book ).
ewall
61
+1. De nombreux tutoriels git vous montrent comment effectuer certaines tâches sans expliquer la signification de certains mots ou le fonctionnement de git. Demander une ressource qui traite de ces sujets est une question légitime.
Daniel Stutzbach
14
J'aimerais pouvoir attribuer +1 au commentaire de Daniel. Alors que la signification de certains termes (par exemple, référentiel) doit être évidente, leur relation n'est pas toujours (branche vs fourchette), et la vraie signification est facilement mal interprétée par quelqu'un habitué à un VCS centralisé. En outre, regardez "Qu'est-ce qu'une branche?" De Pro Git? section - un utilisateur basique veut-il vraiment connaître les blobs et les arbres, ou veut-il simplement savoir qualitativement ce qu'est une branche?
Cascabel
1
@DanielStutzbach, il est possible de soumettre des commentaires sur des choses qui ne sont pas claires dans le livre. (Je ne connais pas la terminologie correcte pour dire cela.) J'ai fait cela, j'ai dit que le livre doit définir ce qu'est un référentiel. Je conviens qu'il est assez difficile d'obtenir du matériel conceptuel de personnes qui comprennent très bien quelque chose. Ce livre parle (actuellement) des bases de données sans définir ce qu'elles sont dans ce contexte et ne dit rien sur ce que sont les référentiels.
user34660

Réponses:

146

Un référentiel est simplement un endroit où l'historique de votre travail est stocké. Il se trouve souvent dans un .gitsous - répertoire de votre copie de travail - une copie de l'état le plus récent des fichiers sur lesquels vous travaillez.

Pour bifurquer un projet (prendre la source du référentiel de quelqu'un à un certain moment et y appliquer vos propres modifications divergentes), vous cloneriez le référentiel distant pour en créer une copie, puis effectuez votre propre travail dans votre référentiel local et valider les modifications.

Dans un référentiel, vous avez des branches, qui sont en fait des fourches dans votre propre référentiel. Vos branches auront un commit ancêtre dans votre référentiel et divergeront de ce commit avec vos modifications. Vous pouvez ultérieurement fusionner vos modifications de branche. Les branches vous permettent de travailler sur plusieurs fonctionnalités disparates à la fois.

Vous pouvez également suivre des branches individuelles dans des référentiels distants. Cela vous permet d'extraire les modifications des branches d'un autre individu et de les fusionner dans une branche de votre choix. Cela peut être utile si vous et un ami travaillez ensemble sur une nouvelle fonctionnalité.

Il y a beaucoup de bons livres git en ligne. Jetez un œil à ProGit et Git Magic pour commencer, ainsi qu'aux didacticiels officiels et au livre de la communauté.

nfm
la source
Bien sûr, la lecture des manuels et tutoriels F est fondamentale. Mais cela me semble un excellent résumé de tout cela. Très appréciée!
brasofilo
Notez que vous pouvez basculer votre répertoire de travail local vers une nouvelle branche ("git checkout <new_branch>"). Dans ce cas, les fichiers de votre répertoire de travail local sont REMPLACÉS par le contenu de la branche vers laquelle vous basculez. Mais vous ne perdez pas votre travail: Git stocke toutes les modifications validées ("git commit") que vous avez faites sur la branche précédente dans la "base de données" de Git (dossier caché .git) et vous permettra de retourner vos fichiers.
KrisWebDev
3
Je pense que cela nécessite une mention spéciale du fait qu'historiquement, quel que soit le VCS que vous utilisiez, la fourche et le branchement étaient considérés comme deux choses distinctes. Le branchement a été considéré comme un accord favorable et implicite entre les développeurs. Le fork était plus sérieux car cela impliquait que les développeurs travaillant sur un projet n'étaient pas d'accord sur certaines choses et décidaient de se séparer. Les fourchettes réussies ont ensuite été généralement fusionnées en un seul projet plus tard, après que les deux parties se sont entendues. Depuis lors, Git (et GitHub) ont brouillé ces termes et les deux termes représentent fondamentalement la même idée mais de manière différente.
redteam316
Un référentiel ne contient donc pas les fichiers du projet? Vous dites un endroit où l'histoire de votre travail est stockée . Est-ce tout? Juste l'historique des fichiers mais pas les fichiers eux-mêmes?
user34660
13

Je vais répondre à ma propre question avec un RTFM.

Mais, lisez ce beau manuel. Comme le dit l'auteur:

«La conclusion que j'en tire est que vous ne pouvez vraiment utiliser Git que si vous comprenez comment fonctionne Git. Le simple fait de mémoriser les commandes à exécuter à quels moments fonctionnera à court terme, mais ce n'est qu'une question de temps avant de rester bloqué ou, pire, de casser quelque chose.

«La moitié des ressources existantes sur Git, malheureusement, adoptent exactement cette approche: elles vous guident à travers quelles commandes exécuter quand, et s'attendent à ce que vous fassiez bien si vous imitez simplement ces commandes. L'autre moitié passe par tous les concepts, mais d'après ce que j'ai vu, ils expliquent Git d'une manière qui suppose que vous comprenez déjà comment fonctionne Git. »

Eric Anderson
la source
Cette introduction semble avoir été déplacée vers sbf5.com/~cduan/technical/git . L'URL d'origine fonctionne toujours pour le moment.
Eric Anderson
1
Cela est vrai dans le contexte. Si vous devez être productif tout de suite ou simplement enregistrer du code, il est normal de ne pas avoir une compréhension approfondie du fonctionnement de git. Les tutoriels sont très bien. C'est comme ça que je suis entré dans git. Cependant, si ou quand vous avez besoin d'être plus avancé comme créer des branches, fork, rebase et d'autres tâches plus avancées, vous devez savoir comment git fonctionne, surtout si votre arrière-plan est dans un contrôle de source centralisé.
Phil
3

Ce GoogleTechTalk est une fantastique introduction à Git pour apprendre ce qui se passe réellement dans les coulisses tout en apprenant également la langue. Il a été donné par un des premiers contributeurs à Git et il a donné cette conférence en 2007 comme une introduction à Git. Si vous regardez cette conférence, vous saurez non seulement ce qu'est chaque mot, comme référentiel, fourchette, branche, etc., mais vous saurez également ce qui se passe dans les coulisses lorsque chacun d'entre eux est créé, fusionné, etc.

L'adresse est longue mais très informative. Il contraste également Git avec d'autres systèmes de contrôle de version, ce qui vous permet de comprendre pourquoi Git a été créé tel qu'il était et quels sont ses avantages comparatifs par rapport aux autres systèmes de contrôle. Même si le discours est ancien, il est très utile de se lancer. Je regarderais ceci avant de sauter dans les manuels. Les choses auront beaucoup plus de sens en conséquence, je crois.

Mat
la source