Français ▾ Topics ▾ Latest version ▾ gitglossary last updated in 2.51.0

NOM

gitglossary - Un glossaire de Git

SYNOPSIS

*

DESCRIPTION

base de données d’objets substituts

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".

dépôt nu

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 blob

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

branche

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.

cache

Obsolète pour : index.

chaîne

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).

ensemble de modifications

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.

extraction

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.

picorage

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.

propre

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

commit

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.

Comme verbe : le terme "valider" est utilisé en français. L’action de stocker un nouvel instantané de l’état du projet dans l’historique Git, en créant un nouveau commit représentant l’état actuel de l'index et en avançant la HEAD pour pointer vers le nouveau commit.

concept, représentations et utilisation du graphe de 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".

fichier de graphe de commit

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.

objet commit

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.

commit-esque (également commitesque)

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.

cœur Git

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

DAG

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).

objet en suspens

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.

déréférence

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.

Se référant à un objet étiquette : l’action d’accéder à l'objet pointé par une étiquette. Les étiquettes sont référencées de façon récursive en répétant l’opération sur l’objet du résultat jusqu’à ce que le résultat ait le type d’objet spécifié (le cas échéant) ou tout type d’objet non "étiquette". Un synonyme de "déréférencer récursivement" dans le contexte des étiquettes est peler".

Se référant à un objet commit : action d’accéder à l’objet arbre du commit. Les commits ne peuvent pas être déréférés de façon récursive.

Sauf indication contraire, "déréférencer" tel qu’il est utilisé dans le contexte des commandes ou des protocoles Git est implicitement récursif.

HEAD détaché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".

Notez que les commandes qui opèrent sur l’historique de la branche actuelle (par exemple git commit pour construire un nouvel historique par dessus) fonctionnent toujours même si la HEAD est détachée. Elles mettent à jour la HEAD pour pointer à l’extrémité de l’historique mis à jour sans affecter aucune branche. Les commandes qui mettent à jour ou demandent des informations sur la branche courante (par exemple git branch --set-upstream-to qui définit avec quelle branche de suivi à distance la branche actuelle s’intègre) ne fonctionnent évidemment pas, car il n’y a pas de branche actuelle (réelle) à demander dans cet état.

répertoire

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

sale

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

fusion maléfique

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

avance rapide

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

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].

système de fichiers

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.

Archives Git

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

fichier-git

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].

greffes

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.

Notez que le mécanisme de greffes est dépassé et peut conduire à des problèmes de transfert d’objets entre dépôts ; voir git-replace[1] pour un système plus flexible et plus robuste pour faire la même chose.

hachage

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

tête

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].)

HEAD

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.

réf. tête

Un synonyme de tête.

crochet

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.

index

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.

entrée d’index

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).

master

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.

fusionner

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.

Comme nom (fusion) : à moins qu’il ne s’agisse d’une avance rapide, une fusion réussie entraîne la création d’un nouveau commit représentant le résultat de la fusion, et ayant comme parents les sommets des branches fusionnées. Ce commit est appelé un "commit de fusion" , ou parfois simplement une "fusion".

objet

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é.

base de données d’objets

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/.

identifiant d’objet (oid)

Synonyme de nom d’objet.

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.

type d’objet

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

pieuvre

Pour fusionner plus de deux branches.

orphelin

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.

origine

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.

superposition

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.

paquet

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

index du paquet

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

spéc-de-chemin

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

Les spécifications de chemin sont utilisées sur la ligne de commande de "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout" et de nombreuses autres commandes pour limiter la portée des opérations à un sous-ensemble de l’arbre ou de l’arbre de travail. Consultez la documentation de chaque commande pour savoir si les chemins sont relatifs au répertoire courant ou au premier niveau. La syntaxe de spécificateurs de chemin est la suivante :

  • tout chemin correspond à lui-même

  • le spécificateur de chemin jusqu’à la dernière barre oblique représente un préfixe de répertoire. La portée de ce spécificateur de chemin est limitée à ce sous-arbre.

  • le reste du spécificateur de chemin est un motif pour le reste du nom de chemin. Les chemins relatifs au préfixe du répertoire seront comparés à ce motif en utilisant fnmatch(3) ; en particulier, * et ? peuvent correspondre aux séparateurs de répertoire.

Par exemple, Documentation/*.jpg correspondra à tous les fichiers .jpg du sous-arbre Documentation, y compris Documentation/chapitre_1/figure_1.jpg.

Un spécificateur de chemin qui commence par un deux-points : a une signification particulière. Dans la forme courte, le deux-points de tête : sont suivis par zéro ou plusieurs lettres de la "signature magique" (qui se termine éventuellement par un autre deux-points :), et le reste est le motif à faire correspondre au chemin. La "signature magique" est constituée de symboles ASCII qui ne sont ni des caractères alphanumériques, ni des glob, ni des caractères spéciaux de regex, ni des deux-points. Le deux-points facultatif qui termine la "signature magique" peut être omis si le motif commence par un caractère qui n’appartient pas au jeu de symboles de la "signature magique" et qui n’est pas un deux-points.

Dans la forme longue, le deux-points de tête : est suivi d’une parenthèse ouverte (, d’une liste de zéro ou plus de "mots magiques" séparée par des virgules, et d’une parenthèse fermée ), et le reste est le motif à comparer au chemin.

Un spécificateur de chemin avec seulement un deux-points signifie "il n’y a pas de spécificateur de chemin". Cette forme ne doit pas être combinée avec d’autres spécificateurs de chemin.

top

Le mot magique top (signature magique : /) fait correspondre le motif à partir de la racine de l’arbre de travail, même si vous exécutez la commande depuis un sous-répertoire.

literal

Les caractères génériques dans le motif tels que * ou ? sont traités comme des caractères littéraux.

icase

Correspondance insensible à la casse.

glob

Git traite le motif comme un glob shell qui peut être utilisé par fnmatch(3) avec l’option FNM_PATHNAME : les caractères génériques du motif ne correspondent pas à un / dans le chemin d’accès. Par exemple, "Documentation/*.html" ; correspond à "Documentation/git.html" ; mais pas à "Documentation/ppc/ppc.html" ; ou à "tools/perf/Documentation/perf.html" ;.

Deux astérisques consécutifs ("**") dans les motifs comparés au nom de chemin complet peuvent avoir une signification spéciale :

  • Un "**" suivi d’une barre oblique signifie une correspondance dans tous les répertoires. Par exemple, "**/foo" correspond au fichier ou au répertoire "foo" n’importe où. "**/foo/bar" correspond au fichier ou au répertoire "bar" n’importe où, directement sous le répertoire "foo".

  • Un "/**" de queue correspond à tout ce qui se trouve à l’intérieur. Par exemple, "abc/**" correspond à tous les fichiers du répertoire "abc", relativement à l’emplacement du fichier .gitignore, avec une profondeur infinie.

  • Une barre oblique suivie de deux astérisques consécutifs puis d’une barre oblique correspond à zéro ou plusieurs répertoires. Par exemple, "a/**/b" correspond à "a/b", "a/x/b", "a/x/y/b" et ainsi de suite.

  • Les autres astérisques consécutifs sont considérés comme non valides.

    La correspondance globale est incompatible avec la correspondance littérale.

attr

Après attr: vient une liste, séparée par des espaces, d'« exigences d’attribut », qui doivent tous être satisfaits pour que le chemin soit considéré comme une correspondance ; ceci est en plus de la correspondance habituelle des motifs non-magiques de spécificateur de chemin. Voir gitattributes[5].

Chacun des attributs requis pour le chemin prend l’une de ces formes :

  • "ATTR" exige que l’attribut ATTR soit défini.

  • "-ATTR" exige que l’attribut ATTR soit désactivé.

  • "ATTR=VALEUR" exige que l’attribut ATTR soit défini comme la chaîne de caractères VALEUR.

  • "!ATTR" exige que l’attribut ATTR soit non spécifié.

    Notez que lors de la correspondance avec un objet arbre, les attributs sont toujours obtenus à partir de l’arbre de travail, et non de l’objet arbre donné.

exclude

Après qu’un chemin corresponde à un spécificateur de chemin non exclu, il sera parcouru par tous les spécificateurs de chemin exclus (signature magique : ! ou son synonyme ^). S’il correspond, le chemin est ignoré. S’il n’y a pas de chemin d’accès non exclu, l’exclusion est appliquée au résultat comme si elle était invoquée sans spécificateur de chemin.