Grâce au mécanisme des substituts, un dépôt peut hériter d’une partie de sa base de données d’objets d’une autre base de données d’objets, qui est appelée un "substitut".

Un dépôt nu est normalement un répertoire nommé de manière appropriée avec un suffixe .git qui n’a pas de copie locale de tous les fichiers sous contrôle de révision. C’est-à-dire que tous les fichiers d’administration et de contrôle de Git qui seraient normalement présents dans le sous-répertoire caché .git sont directement présents dans le répertoire repository.git à la place, et aucun autre fichier n’est présent et extrait. Habituellement, les éditeurs de dépôts publics mettent à disposition des dépôts nus.

Objet non typé, par exemple le contenu d’un fichier.

Une "branche" est une ligne de développement. Le commit le plus récent sur une branche est appelé sommet de cette branche. Le sommet de la branche est référencé par une tête de branche, qui avance au fur et à mesure que des développements supplémentaires sont effectués sur la branche. Un seul dépôt Git peut suivre un nombre arbitraire de branches, mais votre arbre de travail est associé à une seule d’entre elles (la branche "actuelle" ou "extraite"), et HEAD pointe vers cette branche.

Obsolète pour : index.

Une liste d’objets, où chaque objet de la liste contient une référence à son successeur (par exemple, le successeur d’un commit pourrait être un de ses parents).

BitKeeper/cvsps parlent de "commit". Puisque Git ne stocke pas les modifications, mais les états, cela n’a pas vraiment de sens d’utiliser le terme "ensemble de modifications" avec Git.

L’action de mettre à jour tout ou partie de l'arbre de travail avec un objet arbre ou un blob de la base de données des objets, et en mettant à jour l' index et la HEAD si l’ensemble de l’arbre de travail a été dirigé vers une nouvelle branche.

Dans le jargon SCM, "picorage" signifie choisir un sous-ensemble de modifications dans une série de modifications (généralement des commits) et les enregistrer comme une nouvelle série de modifications sur une base de code différente. Dans Git, cela est effectué par la commande "git cherry-pick" pour extraire la modification introduite par un commit existant et pour l’enregistrer en fonction du sommet de la branche actuelle en tant que nouveau commit.

Un arbre de travail est propre, s’il correspond à la révision référencée par la tête courante. Voir aussi "sale".

En tant que substantif : Un point unique dans l’historique de Git ; l’historique complet d’un projet est représenté comme un ensemble de commits interconnectés. Le mot "commit" est souvent utilisé par Git aux mêmes endroits où d’autres systèmes de contrôle de révision utilisent les mots "revision" ou "version". Également utilisé comme raccourci pour objet commit.

Un synonyme de la structure DAG (Directed Acyclic Graph : graphe dirigé acyclique) formée par les commits de la base de données des objets, référencés par les sommets de branches, en utilisant leur chaîne de commits liés. Cette structure est le graphe de commits définitif. Le graphe peut être représenté d’autres façons, par exemple par le fichier "commit-graph".

Le fichier "commit-graph" (normalement avec un trait d’union) est une représentation supplémentaire du graphe de commit qui accélère les parcours du graphe de commit. Le fichier "commit-graph" est stocké soit dans le répertoire .git/objects/info, soit dans le répertoire info d’une base de données d’objets alternative.

Un objet qui contient les informations sur une révision particulière, telles que ses parents, validateur, auteur, date et le objet arbre qui correspond au répertoire racine de la révision stockée.

Un objet commit ou un objet qui peut être déréférencé récursivement vers un objet commit. Les éléments suivants sont tous des objets commit : un objet commit, un objet étiquette qui pointe vers un objet commit, un objet étiquette qui pointe vers un objet étiquette qui pointe vers un objet commit, etc.

Structures de données fondamentales et utilitaires de Git. N’expose que des outils limités de gestion du code source.

Graphe acyclique dirigé ('Directed Acyclique Graph"). Les objets commit forment un graphe acyclique dirigé, car ils ont des parents (dirigés), et le graphe des objets commit est acyclique (il n’y a pas de chaîne qui commence et se termine par le même objet).

Un objet inatteignable qui n’est pas joignable même à partir d’autres objets inatteignables ; un objet en suspens n’a aucune référence vers lui à partir de n’importe quelle référence ou objet dans le dépôt.

Se référant à une référence symbolique  : l’action d’accéder à la référence pointée par une réf symbolique. Le déréférencement récursif implique de répéter le processus susmentionné sur la réf résultante jusqu’à ce qu’une référence non symbolique soit trouvée.

Normalement, la HEAD stocke le nom d’une branche et les commandes qui opèrent sur l’historique que représente le HEAD opèrent sur l’historique menant au sommet de la branche vers laquelle pointe la HEAD. Cependant, Git vous permet également d' extraire un commit arbitraire qui n’est pas nécessairement le sommet d’une branche particulière. La HEAD dans un tel état est appelé "détachée".

La liste que vous obtenez avec "ls" :-)

Un arbre de travail est dit "sale" s’il contient des modifications qui n’ont pas été validées dans la branche actuelle.

Une fusion maléfique est une fusion qui introduit des modifications qui n’apparaissent dans aucun des parents.

Une avance rapide est un type spécial de fusion où vous avez une révision et vous "fusionnez" les modifications d’une autre branche qui se trouvent être descendantes de ce que vous avez. Dans ce cas, vous ne faites pas un nouveau commit de fusion mais vous mettez simplement à jour votre branche pour qu’elle pointe vers la même révision que la branche que vous fusionnez. Cela se produit fréquemment sur une branche de suivis à distance d’un dépôt distant.

Récupérer une branche signifie obtenir la référence head de la branche à partir d’un dépôt distant, pour trouver quels objets manquent dans la base de données d’objets locale, et les obtenir également. Voir aussi git-fetch[1].

Linus Torvalds a conçu à l’origine Git pour être un système de fichiers en espace utilisateur, c’est-à-dire l’infrastructure pour contenir les fichiers et les répertoires. Cela garantissait l’efficacité et la rapidité de Git.

Synonyme de dépôt (pour les utilisateurs d’Arch).

Un simple fichier .git à la racine d’un arbre de travail qui pointe vers le répertoire qui est le vrai dépôt. Pour une utilisation appropriée voir git-worktree[1] ou git-submodule[1]. Pour la syntaxe voir gitrepository-layout[5].

Les greffes permettent de relier deux lignes de développement différentes en enregistrant de fausses informations d’ascendance pour les commits. De cette façon, vous pouvez faire croire à Git que l’ensemble des parents d’un commit est différent de ce qui a été enregistré lors de la création du commit. Configuré via le fichier .git/info/grafts.

Dans le contexte de Git, synonyme de nom de l’objet.

Une référence nommée au commit au sommet d’une branche. Les têtes sont stockées dans un fichier dans le répertoire $GIT_DIR/refs/heads/, sauf lors de l’utilisation de refs empaquetées. (Voir git-pack-refs[1].)

La branche actuelle. Plus en détail : Votre arbre de travail est normalement dérivé de l’état de l’arbre auquel fait référence HEAD. HEAD est une référence à l’un des têtes de votre dépôt, sauf si vous utilisez une HEAD détachée, auquel cas elle fait directement et librement référence à un commit.

Un synonyme de tête.

Au cours de l’exécution normale de plusieurs commandes Git, des appels sont faits à des scripts optionnels qui permettent à un développeur d’ajouter des fonctionnalités ou des vérifications. Typiquement, les crochets permettent de pré-vérifier une commande et de l’interrompre éventuellement, et permettent une post-notification une fois l’opération effectuée. Les scripts de crochet se trouvent dans le répertoire $GIT_DIR/hooks/, et sont activés en retirant simplement le suffixe .sample du nom du fichier. Dans les versions précédentes de Git, vous deviez les rendre exécutables.

Une collection de fichiers contenant des informations sur les statuts, dont le contenu est stocké sous forme d’objets. L’index est une version stockée de votre arbre de travail. À vrai dire, il peut aussi contenir une deuxième, voire une troisième version d’un arbre de travail, qui sont utilisées lors de fusions.

Les informations concernant un fichier particulier, stockées dans l'index. Une entrée d’index peut être non-fusionnée, si une fusion a été lancée, mais pas encore terminé (c’est-à-dire si l’index contient plusieurs versions de ce fichier).

La branche de développement par défaut. Chaque fois que vous créez une dépôt Git, une branche nommée "master" est créée et devient la branche active. Dans la plupart des cas, elle contient le développement local, bien que cela soit purement par convention et ne soit pas nécessaire.

Apporter le contenu d’une autre branche (éventuellement d’un dépôt externe) dans la branche actuelle. Dans le cas où la branche fusionnée provient d’un dépôt différent, cela est fait en commençant par récupérer la branche distante et en fusionnant ensuite le résultat dans la branche actuelle. Cette combinaison d’opérations de récupération et de fusion est appelée une tirage. La fusion est effectuée par un processus automatique qui identifie les modifications apportées depuis que les branches ont divergé, puis applique toutes ces modifications ensemble. Dans les cas où les modifications entrent en conflit, une intervention manuelle peut être nécessaire pour effectuer la fusion.

L’unité de stockage dans Git. Il est identifié de manière unique par le SHA-1 de son contenu. Par conséquent, un objet ne peut pas être modifié.

Stocke un ensemble d' "objets", et un objet individuel est identifié par son nom d’objet. Les objets se trouvent généralement dans $GIT_DIR/objects/.

Synonyme de nom d’objet.

L’identifiant unique d’un objet. Le nom de l’objet est généralement représenté par une chaîne hexadécimale de 40 caractères. Aussi appelé familièrement SHA-1.

Un identificateur parmi "commit", "arbre (tree)", "étiquette (tag)" ou "blob" décrivant le type d’un objet.

Pour fusionner plus de deux branches.

L’acte de se mettre sur une branche qui n’existe pas encore (c.-à-d. une branche non-née). Après une telle opération, le commit créé devient un commit sans parent, commençant un nouvel historique.

Le dépôt amont par défaut. La plupart des projets ont au moins un projet amont qu’ils suivent. Par défaut, le nom origin est utilisé à cette fin. Les nouvelles mises à jour amont seront récupérées dans des branches de suivi à distance nommées origin/nom-de-la-branche-amont, que vous pouvez voir en utilisant git branch -r.

Ne fait que mettre à jour et ajouter des fichiers dans le répertoire de travail, mais ne les supprime pas, de la même manière que cp -R mettrait à jour le contenu du répertoire de destination. C’est le mode par défaut de l'extraction lors de l’extraction de fichiers depuis l'index ou un arbresque. En revanche, le mode sans superposition supprime également les fichiers suivis qui ne sont pas présents dans la source, de manière similaire à rsync --delete.

Un ensemble d’objets qui ont été compressés en un seul fichier (pour gagner de l’espace ou pour les transmettre efficacement).

La liste des identifiants, et d’autres informations, des objets dans un paquet, pour aider à accéder efficacement au contenu d’un paquet.

Motif utilisé pour limiter les chemins dans les commandes Git.

Un objet commit contient une liste (éventuellement vide) du ou des prédécesseurs logiques dans la ligne de développement, c’est-à-dire ses parents.

L’action de récursivement déréférencer un objet étiquette.

Le terme pioche fait référence à une option des routines diffcore qui aide à sélectionner les modifications qui ajoutent ou suppriment une chaîne de texte donnée. Avec l’option --pickaxe-all, elle peut être utilisée pour afficher la totalité des ensembles de modifications qui ont introduit ou supprimé, disons, une ligne de texte particulière. Voir git-diff[1].

Nom mignon pour core Git.

Nom mignon pour les programmes et les suites de programmes dépendant de core Git, présentant une interface de haut niveau au noyau Git. Les porcelaines exposent une interface plus SCM que la la plomberie.

Les références qui sont par-arbre-de-travail, plutôt que globales. Il ne s’agit actuellement que de HEAD et de toutes les références qui commencent par refs/bisect/, mais pourraient ultérieurement inclure d’autres références inhabituelles.

Les pseudorefs sont une classe de fichiers sous $GIT_DIR qui se comportent comme des refs à des fins de rev-parse, mais qui sont traités spécialement par git. Les pseudorefs ont des noms qui sont à la fois tout en majuscules et commencent toujours par une ligne composée d’un SHA-1 suivi d’un espace blanc. Donc, HEAD n’est pas une pseudoref, car c’est parfois une ref symbolique. Elles peuvent éventuellement contenir des données supplémentaires. « MERGE_HEAD » et « CHERRY_PICK_HEAD » en sont des exemples. Contrairement aux refs-par-arbre-de-travail, ces fichiers ne peuvent pas être des refs symboliques et n’ont jamais de reflogs. Ils ne peuvent pas non plus être mis à jour via la machinerie de mise à jour de référence normale. Au lieu de cela, ils sont mis à jour en écrivant directement dans les fichiers. Cependant, ils peuvent être lus comme s’il s’agissait de refs, donc git rev-parse MERGE_HEAD fonctionnera.

Tirer une branche signifie la récupérer et la fusionner. Voir aussi git-pull[1].

Pousser une branche signifie obtenir la la référence de tête à partir d’un d’un dépôt distant, savoir s’il s’agit d’un ancêtre de la référence de tête locale de la branche et, dans ce cas, placer tous les objets, qui sont accessibles de la référence de tête locale et qui sont manquants dans le dépôt distant, dans la la base de données d’objets distante et mettre à jour la référence de tête distante. Si la la tête distante n’est pas un ancêtre de la tête locale, la poussée échoue.

Tous les ancêtres d’un commit donné sont dits « accessibles » à partir de ce commit. Plus généralement, un objet est accessible depuis un autre si nous pouvons atteindre l’un de l’autre par une chaîne qui suit les étiquettes à tout ce qu’ils marquent, les commits à leurs parents ou arbres, et les arbres aux arbres ou les blobs qu’ils contiennent.

Les bitmaps d’accessibilité stockent des informations sur l'accessibilité d’un ensemble sélectionné de commits dans un fichier paquet, ou un index multi-paquet (MIDX), pour accélérer la recherche d’objets. Les bitmaps sont stockés dans un fichier ".bitmap". Un dépôt peut avoir au maximum un fichier bitmap en cours d’utilisation. Le fichier bitmap peut appartenir soit à un paquet, soit à l’index multi-paquet du dépôt (s’il existe).

Réappliquer une série de modifications d’une branche à une autre base et réinitialiser la tête de cette branche au résultat.

Un nom qui commence par refs/ (par exemple refs/heads/master) qui pointe vers un nom d’objet ou une autre réf (cette dernière est appelée réf symbolique). Pour plus de commodité, une réf peut parfois être abrégée lorsqu’elle est utilisée comme argument pour une commande Git ; voir gitrevisions[7] pour plus de détails. Les références sont stockées dans le dépôt.

Un reflog montre l'« historique » local d’une référence. En d’autres termes, il peut vous dire quelle était la 3ème dernière révision dans ce dépôt, et quel était l’état actuel dans ce dépôt, hier à 21h14. Voir git-reflog[1] pour plus de détails.

Un "refspec" est utilisé par fetch et push pour décrire la correspondance entre le réf distant et le réf local.

Un dépôt qui est utilisé pour suivre le même projet mais qui réside ailleurs. Pour communiquer avec les distants, voir recupérer ou poussée.

Une réf qui est utilisée pour suivre les changements d’un autre dépôt. Elle ressemble typiquement à refs/remotes/foo/bar (indiquant qu’elle suit une branche nommée bar dans un dépôt distant nommé foo), et correspond au côté droit d’un refspec configuré. Une branche de suivi à distance ne doit pas contenir de modifications directes ou avoir des commits locaux effectués sur elle.

Une collection de refs accompagnée d’une base de données d’objets contenant tous les objets qui sont joignables à partir des refs, éventuellement accompagnés de métadonnées provenant d’une ou plusieurs porcelaines. Un dépôt peut partager une base de données d’objets avec d’autres dépôts via des mécanismes alternatifs.

L’action de réparer manuellement ce que l’échec d’une fusion automatique a laissé derrière lui.

Synonyme de commit (le nom).

Jeter une partie du développement, c’est-à-dire affecter la tête à une révision antérieure.

Gestion du code source (Source Code Management en anglais).

"Secure Hash Algorithm 1" une fonction de hachage cryptographique. Dans le contexte de Git, utilisé comme synonyme de nom d’objet.

Principalement un synonyme de dépôt superficiel mais la phrase rend plus explicite qu’il a été créé en exécutant la commande git clone --depth=....

Un dépôt superficiel a un historique incomplet dont certains commits ont des parents « cautérisés » (en d’autres termes, on dit à Git de prétendre que ces commits n’ont pas de parents, même s’ils sont enregistrés dans le l’objet commit). Ceci est parfois utile lorsque vous n’êtes intéressé que par l’historique récent d’un projet même si l’historique réel enregistré dans l’amont est beaucoup plus important. Un dépôt superficiel est créé en donnant l’option --depth à git-clone[1], et son historique peut être approfondi plus tard avec git-fetch[1].

Un objet utilisé pour stocker temporairement le contenu d’un répertoire de travail sale et l’index pour une réutilisation future.

Une réf qui a une sémantique différente des réfs normales. Ces réfs peuvent être accédées par des commandes Git normales mais peuvent ne pas se comporter comme une réf normale dans certains cas.

Un dépôt qui contient l’historique d’un projet séparé à l’intérieur d’un autre dépôt (ce dernier est appelé superprojet).

Un dépôt qui fait référence aux dépôts d’autres projets dans son arbre de travail comme sous-modules. Le superprojet connaît les noms des objets commit des sous-modules contenus (mais n’en détient pas de copie).

Référence symbolique : au lieu de contenir l’identifiant SHA-1 lui-même, elle est au format ref:refs/quelque/chose et lorsqu’elle est référencée, elle déréférence récursivement vers cette référence. HEAD est un excellent exemple de symref. Les références symboliques sont manipulées avec la commande git-symbolic-ref[1].

Une réf sous l’espace de noms refs/tags/ qui pointe vers un objet d’un type arbitraire (typiquement, une étiquette pointe vers un objet tag ou un objet commit). Contrairement à une tête, une étiquette n’est pas mise à jour par la commande commit. Une étiquette Git n’a rien à voir avec un tag Lisp (qui serait appelé un type d’objet dans le contexte de Git). Une étiquette est le plus souvent utilisée pour marquer un point particulier dans la chaîne d’ascendance de commits.

Un objet contenant une réf pointant vers un autre objet, qui peut contenir un message tout comme un objet commit. Il peut également contenir une signature (PGP), auquel cas il est appelé un "objet étiquette signé".

Une branche régulière de Git qui est utilisée par un développeur pour identifier une ligne conceptuelle de développement. Comme les branches sont très faciles et peu coûteuses, il est souvent souhaitable d’avoir plusieurs petites branches qui contiennent chacune des concepts très bien définis ou de petits changements incrémentiels mais liés.

Soit un arbre de travail, soit un objet arbre avec les blob et objets arbre dépendants (c’est-à-dire une représentation stockée d’un arbre de travail).

Un objet contenant une liste de noms et de modes de fichiers ainsi que des références aux objets blob et/ou arbres associés. Un arbre est équivalent à un répertoire.

Un objet arbre ou un objet qui peut être déréférencé récursivement vers un objet arbre. Le déréférencement d’un objet commit donne l’objet arbre correspondant au répertoire racine de la révision. Les éléments suivants sont tous des arbres-esques : un commit-esque, un objet arbre, un objet étiquette qui pointe vers un objet arbre, un objet étiquette qui pointe vers un objet étiquette qui pointe vers un objet arbre, etc.

L'HEAD peut pointer à une branche qui n’existe pas encore et qui n’a pas encore de commit sur elle, et une telle branche est appelée une branche non-née. La façon la plus typique que les utilisateurs rencontrent une branche non-née est de créer un dépôt nouvellement créé sans clonage depuis ailleurs. La HEAD pointerait sur la branche main (ou master, selon votre configuration) qui n’est pas encore née. En outre, certaines opérations peuvent vous obtenir sur une branche non-née avec leur option orpheline.

Un index qui contient des entrées d’index non fusionnées.

Un objet qui n’est pas joignable à partir d’une branche, d’une étiquette, ou de toute autre référence.

La branche par défaut qui est fusionnée dans la branche en question (ou sur laquelle la branche en question est rebasée). Elle est configurée via branch.<nom>.remote et branch.<nom>.merge. Si la branche amont de A est origin/B on dit parfois "A suit origin/B".

L’arbre des fichiers effectivement extraits. L’arbre de travail contient normalement le contenu de l’arbre du commit HEAD, plus toutes les modifications locales que vous avez faites mais pas encore validées.

Un dépôt peut avoir zéro (c’est-à-dire un dépôt nu) ou un ou plusieurs arbres de travail attachés à lui. Un "arbre-de-travail" consiste en un "arbre de travail" et des métadonnées de dépôt, dont la plupart sont partagées entre les autres arbres-de-travail d’un même dépôt, et dont certaines sont maintenues séparément par arbre-de-travail (par exemple l’index, HEAD et les pseudoréfs comme MERGE_HEAD, les réfs par arbre-de-travail et le fichier de configuration par arbre-de-travail).