Terminologie utilisée par Git

il semble que je dois apprendre à utiliser git. Ce qui est probablement une bonne chose (TM). Cependant, en lisant des guides en ligne et des pages de manuel, je n’arrive pas à comprendre la terminologie. Tout est toujours défini en termes d’eux-mêmes ou d’autres termes inexpliqués (faites un “homme git” et vous voyez ce que je veux dire).

Y a-t-il une structure de définitions de termes plus similaire à celle du DAG, y compris certaines des suivantes (toutes issues de la ou des pages git man!). Peut-être utiliser un système de fichiers comme sharepoint départ et ne pas supposer que le lecteur connaît bien svn (ce que je ne suis pas).

  • repo
  • repository
  • un git
  • “le git”
  • indice
  • cloner
  • commettre
  • twig
  • arbre
  • en amont
  • devant
  • TÊTE
  • version
  • marque
  • archiver
  • pièce
  • soumission
  • changeset
  • planque
  • archiver
  • object
  • module
  • sous-module
  • refspec
  • Une histoire

Tandis que je peux trouver des explications pour certains, ils sont généralement en termes de l’autre. Aussi quelques autres termes que je connais d’autres contextes (comme un diff UNIX). Cependant, un autre je pensais que je savais …

J’ai compris qu’il existe des référentiels (similaires aux gits? Et / ou aux arbres? En amont?), Que vous copiez (clone? Branche?) Pour transférer physiquement les fichiers sur votre disque dur. Ensuite, il existe des twigs (similaires aux changesets?), Des balises et des commits (similaires aux patches?), Mais leur distinction n’est pas claire. Quels fichiers font quoi modifier? Qu’est-ce qui fait que mes fichiers restnt locaux et qu’est-ce qui pourrait (Dieu nous en préserve) soumettre mon code aux internets?

Quelle est la méthode de travail recommandée pour les twigs, les balises et les commits? Il est donc facile de passer d’une version à une autre et d’importer des mises à jour à partir de gits disponibles publiquement.

// T, se mordant la langue pour contrôler sa frustration …

Voici une tentative pour compléter votre glossaire (du haut de ma tête, en essayant d’utiliser mes propres mots):

  • repo, repository : Ceci est votre firebase database d’objects si votre historique et votre configuration sont stockés. Peut contenir plusieurs twigs. Souvent, il contient aussi un worktree.

  • un git, “le git”: jamais entendu parler de, désolé. “le git” décrit probablement le logiciel lui-même, mais je ne suis pas sûr

  • index, zone de transfert : Ceci est un “cache” entre votre worktree et votre référentiel. Vous pouvez append des modifications à l’index et créer votre prochain engagement étape par étape. Lorsque votre contenu d’index est à vos goûts, vous pouvez en créer un. Également utilisé pour conserver des informations lors de fusions échouées (côté, état et état actuel)

  • clone: un clone d’un repository (“juste un autre repository”) ou l’acte de le faire (“cloner un référentiel (crée un nouveau clone)”)

  • commit: état de votre projet à un moment donné. Contient un pointeur sur la validation de son parent (en cas de fusion: plusieurs parents) et un pointeur sur la structure de répertoire à ce stade.

  • twig: une ligne de développement différente. Une twig dans git est juste un “label” qui pointe vers un commit. Vous pouvez obtenir l’historique complet via les pointeurs parents. Une twig par défaut est uniquement locale à votre référentiel.

  • tree: Fondamentalement, 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 sous-modules, mais c’est un sujet avancé)

  • en amont: Après avoir cloné un référentiel, vous appelez souvent ce référentiel “original” “en amont”. Dans git c’est alias à l’ origin

  • a head: La validation supérieure d’une twig (valide les points d’étiquette)

  • HEAD: Un nom symbolique pour décrire le commit actuellement extrait. Souvent le plus haut engagement

  • version: Peut être identique à un commit. Cela pourrait également signifier une version publiée de votre projet.

  • tag: Un nom descriptif donné à l’un de vos commits (ou arbres, ou blobs). Peut également contenir un message (par exemple, changelog). Les balises peuvent être cryptographiquement signées avec GPG.

  • archive: Une archive simple (.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’auther d’origine, le message de validation et les différences de fichiers

  • soumission: aucune idée. Soumettre un patch à un projet peut-être?

  • changeset: Synonyme de “commit”

  • stash: Git vous permet de “ranger” les modifications. Cela vous donne un arbre de travail propre sans aucun changement. Plus tard, ils peuvent être “sautés” pour être ramenés. Cela peut vous sauver la vie si vous avez besoin de travailler temporairement sur une modification sans rapport (par exemple, correction de bogue critique dans le temps).

  • object: peut être un de commit , tree , blob , tag . Un object a 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 partageant le même object. Il garantit également l’intégrité d’un référentiel: vous ne pouvez pas modifier les validations passées sans modifier les hachages 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). Des trucs avancés

  • revspec: une revspec (ou expression revparse) décrit un certain object git ou un ensemble de commits via ce qu’on appelle la syntaxe SHA1 étendue (ex. HEAD , master~4^2 , origin/master..HEAD , deadbeaf^! … )

  • refspec: un refspec est un modèle décrivant le mappage à effectuer entre les références distantes et locales lors des opérations d’extraction ou d’extraction.

  • history: Décrit tous les commits d’ancêtres avant une validation revenant au premier commit.


Les choses que vous n’avez pas mentionnées, mais qui sont probablement bonnes à savoir:

Tout ce que vous faites est local dans votre référentiel (créé par git init ou git clone git://url.com/another/repo.git ). Il y a seulement quelques commandes dans git qui interagissent avec d’autres repositorys (aka teh interwebz), y compris clone , fetch , pull , push .

Push & Pull sont utilisés pour synchroniser les référentiels. Tirez sur les objects de fetch depuis un autre référentiel et fusionnez-les avec votre twig actuelle. Push est utilisé pour prendre vos modifications et les push dans un autre référentiel. Vous ne pouvez pas pousser des validations ou des modifications simples, vous ne pouvez que pousser un commit incluant son historique complet.

Un seul référentiel peut contenir plusieurs twigs, mais pas nécessairement. La twig par défaut de git s’appelle master . Vous pouvez créer autant de twigs que vous le souhaitez, la fusion est un jeu de git. Les twigs sont locales jusqu’à ce que vous git push origin .

Une validation 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 et master )

Git est assez puissant pour préparer vos commits. L’ingrédient clé ici est “l’index” (ou “zone de transit”). Vous pouvez append des modifications uniques à l’index (en utilisant git add ) jusqu’à ce que vous pensiez que l’index semble correct. git commit lance votre éditeur de texte et vous devez fournir un message de validation (pourquoi et comment vous avez apporté cette modification); Après avoir entré votre message de validation, git créera un nouveau commit – contenant le contenu de l’index – en plus du commit précédent (le pointeur parent est le SHA1 du commit précédent).

Git est livré avec la documentation pour exactement ce que vous recherchez.

 $ git help glossary 

J’ai trouvé ce livre (gratuit) très utile pour apprendre à utiliser git: http://progit.org/ . Le livre existe également sous forme imprimée.

Je pense que le moyen le plus rapide d’apprendre git est probablement de choisir un livre ou un tutoriel qui vous apprend les concepts et les termes de base.

Une autre bonne ressource pour apprendre Git est Git Immersion d’ Edgecase. Tenter d’apprendre Git à travers les pages de manuel est probablement très difficile, il faut d’abord surmonter une courbe d’apprentissage courte et abrupte. Vous devez d’abord connaître le concept d’un système DCVS (Dissortingbuted Version Control System).

Progit tel que recommandé par @fulhack est également très bon.

Je peux également recommander fortement Think Like A Git . L’explication de rebase ici vaut son pesant d’or.

Le meilleur que j’ai trouvé pour comprendre git est The Git Parable

Imaginez que vous ayez un ordinateur qui ne contient rien d’autre qu’un éditeur de texte et quelques commandes de système de fichiers. Imaginez maintenant que vous avez décidé d’écrire un logiciel de grande taille sur ce système. Étant donné que vous êtes un développeur de logiciels responsable, vous décidez que vous devez inventer une méthode quelconque pour garder une trace des versions de votre logiciel afin de pouvoir récupérer le code que vous avez précédemment modifié ou supprimé. Ce qui suit est une histoire sur la façon dont vous pourriez concevoir un tel système de contrôle de version (VCS) et le raisonnement derrière ces choix de conception …

Je pense que vous pourriez aimer cet article: Git for Computer Scientists

Et un autre aspect important à comprendre lorsque vous utilisez git est le workflow. Lire ce merveilleux article de blog: modèle de twigment Git