Voici une tentative de compléter votre glossaire (du haut de ma tête, en essayant d'utiliser mes propres mots) :
-
repo, dépôt : C'est votre base de données objet où sont stockés votre historique et votre configuration. Elle peut contenir plusieurs branches. Souvent, elle contient aussi un arbre de travail.
-
un git, "le git" : jamais entendu parler, désolé. "the git" décrit probablement le logiciel lui-même, mais je n'en suis pas sûr.
-
index, zone de transit : Il s'agit d'un "cache" entre votre arbre de travail et votre référentiel. Vous pouvez ajouter des changements à l'index et construire votre prochain commit étape par étape. Lorsque le contenu de votre index vous convient, vous pouvez créer un commit à partir de celui-ci. Il est également utilisé pour conserver des informations lors de fusions ratées (votre côté, le leur et l'état actuel).
-
clone : Un clone d'un référentiel ("juste un autre référentiel") ou l'action de le faire ("cloner un référentiel (crée un nouveau clone)")
-
commettre : Un état de votre projet à un moment donné. Contient un pointeur vers son commit parent (dans le cas d'une fusion : plusieurs parents) et un pointeur vers la structure du répertoire à ce moment précis.
-
branche : Une ligne de développement différente. Une branche dans git est juste une "étiquette" qui pointe vers un commit. Vous pouvez obtenir l'historique complet grâce aux pointeurs des parents. Une branche par défaut est seulement locale à votre dépôt.
-
arbre : Il s'agit en fait d'un répertoire. C'est juste une liste de fichiers (blobs) et de sous-répertoires (arbres). (La liste peut également contenir des commits si vous utilisez des submodules, mais c'est un sujet avancé).
-
en amont : Après avoir cloné un dépôt, on appelle souvent ce dépôt "original" "upstream". Dans git, il est aliasé en origin
-
une tête : Le commit supérieur d'une branche (le commit vers lequel pointe l'étiquette)
-
TÊTE : Un nom symbolique pour décrire le commit actuellement extrait. Souvent le commit le plus haut
-
version : Cela pourrait être la même chose qu'un engagement. Il peut également s'agir d'une version publiée de votre projet.
-
étiquette : Un nom descriptif donné à l'un de vos commits (ou arbres, ou blobs). Peut également contenir un message (ex. changelog). Les tags peuvent être signés cryptographiquement avec GPG.
-
archives : Une simple archive (.tar, .zip), rien de spécial par rapport à git.
-
patch : Un commit exporté au format texte. Peut être envoyé par email et appliqué par d'autres utilisateurs. Contient l'auteur original, le message du commit et les différences entre les fichiers.
-
soumission : aucune idée. Soumettre un patch à un projet peut-être ?
-
changeset : Synonyme de "commit" (engagement)
-
Cachette : Git vous permet de "mettre de côté" les modifications. Cela vous donne un arbre de travail propre sans aucune modification. Plus tard, ils peuvent être "sortis" pour être ramenés. Cela peut vous sauver la vie si vous devez travailler temporairement sur une modification sans rapport avec le projet (par exemple, la correction d'un bogue critique).
-
objet : peut être l'un des éléments suivants commit , tree , blob , tag . A un objet est associé son hash SHA1 par lequel il est référencé (le commit avec id deadbeaf l'arbre decaf ). Le hachage est identique entre tous les référentiels qui partagent le même objet. Il garantit également l'intégrité d'un dépôt : vous ne pouvez pas modifier les commits passés sans changer les hashs de tous les commits enfants.
-
(module,) sous-module : Un référentiel inclus dans un autre référentiel (par exemple, une bibliothèque externe). Trucs avancés.
-
revspec : Une revspec (ou expression revparse) décrit un certain objet git ou un ensemble de commits à travers ce que l'on appelle la syntaxe SHA1 étendue (ex. HEAD , master~4^2 , origin/master..HEAD , deadbeaf^! , )
-
refspec : Une refspec est un modèle décrivant le mappage à effectuer entre les références distantes et locales pendant les opérations Fetch ou Push.
-
l'histoire : Décrit tous les commits ancêtres avant un commit en remontant jusqu'au premier commit.
Des choses que vous n'avez pas mentionnées, mais qui sont probablement bonnes à savoir :
Tout ce que vous faites est local à votre dépôt (soit créé par git init o git clone git://url.com/another/repo.git ). Il n'y a que quelques commandes dans git qui interagissent avec d'autres dépôts (a.k.a. teh interwebz), notamment clone , fetch , pull , push .
Push & pull sont utilisés pour synchroniser les dépôts. Pull fetch es objets d'un autre dépôt et les fusionne avec votre branche actuelle. Push est utilisé pour prendre vos modifications et push vers un autre référentiel. Vous ne pouvez pas pousser des commits ou des changements uniques, vous pouvez seulement pousser un commit incluant son historique complet.
Un dépôt unique peut contenir plusieurs branches, mais ce n'est pas nécessaire. La branche par défaut dans git est appelée master . Vous pouvez créer autant de branches que vous le souhaitez, la fusion est un jeu d'enfant avec git. Les branches sont locales jusqu'à ce que vous exécutiez git push origin <branch> .
Un commit décrit un état complet du projet. Ces états peuvent être comparés les uns aux autres, ce qui produit un "diff" ( git diff origin/master master = voir les différences entre origin/master y master )
Git est assez puissant lorsqu'il s'agit de préparer vos commits. L'ingrédient clé ici est l'"index" (ou "staging area"). Vous pouvez ajouter des modifications uniques à l'index (en utilisant la commande git add ) jusqu'à ce que vous pensiez que l'indice est bon. git commit lance votre éditeur de texte et vous devez fournir un message de commit (pourquoi et comment vous avez fait cette modification) ; après avoir entré votre message de commit, git créera un nouveau commit - contenant le contenu de l'index - par-dessus le commit précédent (le pointeur parent est le SHA1 du commit précédent).
