Man » Manuel git en ligne - documentation en ligne détaillée pour la page de manuel git

🌍 ☰

git - le système de suivi de contenu idiot

SYNOPSIS

git [-v | --version] [-h | --help] [-C <chemin>] [-c <nom>=<valeur>]
[--exec-path[=<chemin>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
[--no-optional-locks] [--no-advice] [--bare] [--git-dir=<chemin>]
[--work-tree=<chemin>] [--namespace=<nom>] [--config-env=<nom>=<variable_environnement>]
<commande> [<arguments>]

DESCRIPTION

Git est un système de contrôle de version distribué, rapide et évolutif, doté d'un ensemble de commandes exceptionnellement riche qui fournit à la fois des opérations de haut niveau et un accès complet aux internes.

Consultez gittutorial(7) pour commencer, puis consultez giteveryday(7) pour un ensemble minimal de commandes utiles. Le manuel d'utilisation de Git[1] propose une introduction plus approfondie.

Après avoir maîtrisé les concepts de base, vous pouvez revenir à cette page pour découvrir les commandes que Git propose. Vous pouvez en apprendre davantage sur les commandes Git individuelles avec "git help commande". La page de manuel gitcli(7) vous donne un aperçu de la syntaxe des commandes en ligne.

Une copie formatée et hyperliée de la dernière documentation Git peut être consultée à l'adresse
https://git.github.io/htmldocs/git.html ou https://git-scm.com/docs.

OPTIONS

-v, --version

Affiche la version de la suite Git à partir de laquelle provient le programme git.

Cette option est convertie en interne en git version ... et accepte les mêmes options que la commande git-version(1). Si --help est également donné, il prime sur --version.

-h, --help

Affiche le synopsis et une liste des commandes les plus couramment utilisées. Si l'option --all ou -a est donnée, toutes les commandes disponibles sont affichées. Si une commande Git est nommée, cette option ouvre la page de manuel pour cette commande.

D'autres options sont disponibles pour contrôler la façon dont la page de manuel est affichée. Consultez git-help(1) pour plus d'informations, car git --help ... est converti en interne en git help ....

-C <chemin>

Exécute comme si git avait été démarré dans au lieu du répertoire de travail actuel. Lorsque plusieurs options -C sont données, chaque option -C non absolu suivante est interprétée comme relative au -C précédent. Si est présent mais vide, par exemple -C "", le répertoire de travail actuel reste inchangé.

Cette option affecte les options qui attendent un nom de chemin, comme --git-dir et --work-tree, en ce sens que leurs interprétations des noms de chemin seraient effectuées par rapport au répertoire de travail causé par l'option -C. Par exemple, les invocations suivantes sont équivalentes :

git --git-dir=a.git --work-tree=b -C c status
git --git-dir=c/a.git --work-tree=c/b status

-c <nom>=<valeur>

Transmet un paramètre de configuration à la commande. La valeur donnée remplacera les valeurs des fichiers de configuration. Le est censé être dans le même format que celui affiché par git config (les sous-clés sont séparées par des points).

Notez que l’omission du signe = dans git -c foo.bar ... est autorisée et définit foo.bar sur la valeur booléenne true (tout comme [foo]bar le ferait dans un fichier de configuration). L’inclusion du signe égal mais avec une valeur vide (comme dans git -c foo.bar= ...) définit foo.bar sur une chaîne vide, ce que la commande git config --type=bool convertira en false.

^ -config-env=<name>=<envvar> Comme -c <name\>=<value>, affecte une valeur à la variable de configuration <name>, où <envvar> est le nom d’une variable d’environnement à partir de laquelle récupérer la valeur. Contrairement à -c, il n’existe pas de raccourci pour définir directement la valeur sur une chaîne vide ; au lieu de cela, la variable d’environnement elle-même doit être définie sur une chaîne vide. Il y a une erreur si <envvar> n’existe pas dans l’environnement. <envvar> ne peut pas contenir de signe égal pour éviter toute ambiguïté avec <name> qui en contiendrait un.

Ceci est utile dans les cas où vous souhaitez transmettre des options de configuration transitoires à Git, mais que vous le faites sur des systèmes d’exploitation où d’autres processus peuvent être en mesure de lire votre ligne de commande (par exemple, /proc/self/cmdline), mais pas votre environnement (par exemple, /proc/self/environ). Ce comportement est la valeur par défaut sur Linux, mais peut ne pas l’être sur votre système.

Notez que cela peut ajouter une sécurité pour les variables telles que http.extraHeader où les informations sensibles font partie de la valeur, mais pas par exemple pour url.<base>.insteadOf où les informations sensibles peuvent faire partie de la clé.

^ -exec-path[=<path>] Chemin d’accès à l’emplacement où vos programmes Git principaux sont installés. Ceci peut également être contrôlé en définissant la variable d’environnement GIT_EXEC_PATH. Si aucun chemin n’est donné, Git affichera le paramètre actuel puis se terminera.

^ -html-path Affiche le chemin, sans barre oblique de fin, où la documentation HTML de Git est installée, puis se termine.

^ -man-path Affiche le manpath (voir [man]({filename}../../man)(1)) pour les pages de manuel de cette version de Git, puis se termine.

^ -info-path Affiche le chemin où les fichiers Info documentant cette version de Git sont installés, puis se termine.

^ p, --paginate Envoie toutes les sorties à less (ou, si défini, $PAGER) si la sortie standard est un terminal. Cela annule les options de configuration pager.<cmd> (voir la section « Mécanisme de configuration » ci-dessous).

^ P, --no-pager N’envoie pas la sortie Git à un paginateur.

^ -git-dir=<path> Définit le chemin d’accès au dépôt (répertoire .git). Ceci peut également être contrôlé en définissant la variable d’environnement GIT_DIR. Il peut s’agir d’un chemin absolu ou d’un chemin relatif au répertoire de travail actuel.

La spécification de l’emplacement du répertoire .git à l’aide de cette option (ou de la variable d’environnement GIT_DIR) désactive la découverte du dépôt qui tente de trouver un répertoire avec un sous-répertoire .git (ce qui permet de découvrir le dépôt et le niveau supérieur de l’arborescence de travail), et indique à Git que vous vous trouvez au niveau supérieur de l’arborescence de travail. Si vous ne vous trouvez pas au niveau supérieur du répertoire de l’arborescence de travail, vous devez indiquer à Git où se trouve le niveau supérieur de l’arborescence de travail à l’aide de l’option --work-tree=<path> (ou de la variable d’environnement GIT_WORK_TREE).

Si vous souhaitez simplement exécuter git comme si celui-ci avait été démarré dans <path>, utilisez git -C <path>.

--work-tree=<path>
Définit le chemin d’accès à l’arborescence de travail. Il peut s’agir d’un chemin absolu ou d’un chemin relatif au répertoire de travail actuel. Ceci peut également être contrôlé en définissant la variable d’environnement GIT_WORK_TREE et la variable de configuration core.worktree (voir core.worktree dans gitconfig(1) pour une discussion plus détaillée).

--namespace=<path>
Définit l’espace de noms Git. Voir gitnamespaces(7) pour plus de détails. Équivalent à définir la variable d’environnement GIT_NAMESPACE.

--bare
Traite le dépôt comme un dépôt nu. Si la variable d’environnement GIT_DIR n’est pas définie, elle est définie sur le répertoire de travail actuel.

--no-replace-objects
N’utilisez pas les références de remplacement pour remplacer les objets Git. Cela équivaut à exporter la variable d’environnement GIT_NO_REPLACE_OBJECTS avec n’importe quelle valeur. Voir git-replace(1) pour plus d’informations.

--no-lazy-fetch
Ne récupérez pas les objets manquants à partir du référentiel promesseur à la demande. Utile en combinaison avec git cat-file -e <object\> pour vérifier si l’objet est disponible localement. Cela équivaut à définir la variable d’environnement GIT_NO_LAZY_FETCH à 1.

--no-optional-locks
N’effectuez pas d’opérations facultatives qui nécessitent des verrous. Cela équivaut à définir la variable GIT_OPTIONAL_LOCKS à 0.

--no-advice
Désactive tous les messages d’aide qui sont affichés.

--literal-pathspecs
Traitez les pathspecs littéralement (c’est-à-dire, pas de globbing, pas de magie des pathspecs). Cela équivaut à définir la variable d’environnement GIT_LITERAL_PATHSPECS à 1.

--glob-pathspecs
Ajoutez une magie « glob » à tous les pathspecs. Cela équivaut à définir la variable d’environnement GIT_GLOB_PATHSPECS à 1. La désactivation du globbing sur des pathspecs individuels peut être effectuée à l’aide de la magie des pathspecs « :(literal) ».

--noglob-pathspecs
Ajoutez une magie « literal » à tous les pathspecs. Cela équivaut à définir la variable d’environnement GIT_NOGLOB_PATHSPECS à 1. L’activation du globbing sur des pathspecs individuels peut être effectuée à l’aide de la magie des pathspecs « :(glob) ».

--icase-pathspecs
Ajoutez une magie « icase » à tous les pathspecs. Cela équivaut à définir la variable d’environnement GIT_ICASE_PATHSPECS à 1.

--list-cmds=<group>[,\<group>...]
Affiche les commandes par groupe. Il s’agit d’une option interne/expérimentale et peut changer ou être supprimée à l’avenir. Les groupes pris en charge sont : builtins, parseopt (commandes intégrées qui utilisent parse-options), main (toutes les commandes dans le répertoire libexec), others (toutes les autres commandes dans $PATH qui ont le préfixe git), list-\<category> (voir les catégories dans command-list.txt), nohelpers (exclure les commandes d’assistance), alias et config (récupérer la liste des commandes à partir de la variable de configuration completion.commands).

--attr-source=<tree-ish>
Lisez les attributs git à partir de <tree-ish> au lieu de l’arborescence de travail. Voir gitattributes(5). Cela équivaut à définir la variable d’environnement GIT_ATTR_SOURCE.

COMMANDES GIT

Nous divisons Git en commandes de haut niveau (« porcelain ») et en commandes de bas niveau (« plumbing »).

COMMANDES DE HAUT NIVEAU (PORCELAINE)

Nous séparons les commandes de porcelaine en commandes principales et en quelques utilitaires utilisateur supplémentaires.

Commandes de porcelaine principales

git-add(1)

Ajoute le contenu des fichiers à l’index.

git-am(1)

Applique une série de correctifs provenant d’une boîte aux lettres.

git-archive(1)

Crée une archive de fichiers à partir d’un arbre nommé.

git-backfill(1)

Télécharge les objets manquants dans un clone partiel.

git-bisect(1)

Utilise une recherche binaire pour trouver la validation qui a introduit un bogue.

git-branch(1)

Liste, crée ou supprime des branches.

git-bundle(1)

Déplace les objets et les références à l’aide d’une archive.

git-checkout(1)

Change de branche ou restaure les fichiers de l’arborescence de travail.

git-cherry-pick(1)

Applique les modifications introduites par certaines validations existantes.

git-citool(1)

Alternative graphique à git-commit.

git-clean(1)

Supprime les fichiers non suivis de l’arborescence de travail.

git-clone(1)

Clone un dépôt dans un nouveau répertoire.

git-commit(1)

Enregistre les modifications dans le dépôt.

git-describe(1)

Donne à un objet un nom lisible par un humain en fonction d’une référence disponible.

git-diff(1)

Affiche les modifications entre les validations, la validation et l’arborescence de travail, etc.

git-fetch(1)

Télécharge les objets et les références à partir d’un autre dépôt.

git-format-patch(1)

Prépare des correctifs pour une soumission par e-mail.

git-gc(1)

Nettoie les fichiers inutiles et optimise le dépôt local.

git-grep(1)

Affiche les lignes correspondant à un modèle.

git-gui(1)

Interface graphique portable pour Git.

git-init(1)

Crée un dépôt Git vide ou réinitialise un dépôt existant.

git-log(1)

Affiche les journaux de validation.

git-maintenance(1)

Exécute des tâches pour optimiser les données du dépôt Git.

git-merge(1)

Fusionne deux ou plusieurs historiques de développement.

git-mv(1)

Déplace ou renomme un fichier, un répertoire ou un lien symbolique.

git-notes(1)

Ajoute ou inspecte les notes d’objet.

git-pull(1)

Extrait et intègre à partir d’un autre dépôt ou d’une branche locale.

git-push(1)

Met à jour les références distantes ainsi que les objets associés.

git-range-diff(1)

Compare deux plages de validation (par exemple, deux versions d’une branche).

git-rebase(1)

Réapplique les validations sur un autre sommet de base.

git-reset(1)

Réinitialise HEAD actuel à l’état spécifié.

git-restore(1)

Restaure les fichiers de l’arborescence de travail.

git-revert(1)

Annule certaines validations existantes.

git-rm(1)

Supprime les fichiers de l’arborescence de travail et de l’index.

git-shortlog(1)

Résume la sortie de git log.

git-show(1)

Affiche divers types d’objets.

git-sparse-checkout(1)

Réduit votre arborescence de travail à un sous-ensemble de fichiers suivis.

git-stash(1)

Met en attente les modifications dans un répertoire de travail sale.

git-status(1)

Affiche l’état de l’arborescence de travail.

git-submodule(1)

Initialise, met à jour ou inspecte les sous-modules.

git-switch(1)

Change de branche.

git-tag(1)

Crée, liste, supprime ou vérifie un objet de balise signé avec GPG.

git-worktree(1)

Gère plusieurs arborescences de travail.

gitk(1)

Le navigateur de dépôt Git.

scalar(1)

Un outil pour gérer les grands dépôts Git.

Commandes auxiliaires

Manipulateurs :

git-config(1)

Obtient et définit les options de dépôt ou globales.

git-fast-export(1)

Exportateur de données Git.

git-fast-import(1)
Interface pour les importations de données Git rapides.

git-filter-branch(1)
Réécriture des branches.

git-mergetool(1)
Exécution d’outils de résolution de conflits de fusion pour résoudre les conflits de fusion.

git-pack-refs(1)
Regroupement des branches et des étiquettes pour un accès efficace au dépôt.

git-prune(1)
Suppression de tous les objets inaccessibles de la base d’objets.

git-reflog(1)
Gestion des informations du journal des références.

git-refs(1)
Accès de bas niveau aux références.

git-remote(1)
Gestion de l’ensemble des dépôts suivis.

git-repack(1)
Regroupement des objets non empaquetés dans un dépôt.

git-replace(1)
Création, affichage et suppression de références pour remplacer des objets.

Interrogateurs :

git-annotate(1)
Annotation des lignes de fichier avec des informations sur les commits.

git-blame(1)
Affichage de la révision et de l’auteur ayant modifié pour la dernière fois chaque ligne d’un fichier.

git-bugreport(1)
Collecte d’informations pour que l’utilisateur puisse signaler un bug.

git-count-objects(1)
Comptage du nombre d’objets non empaquetés et de leur consommation d’espace disque.

git-diagnose(1)
Génération d’une archive compressée d’informations de diagnostic.

git-difftool(1)
Affichage des modifications à l’aide d’outils de comparaison courants.

git-fsck(1)
Vérification de la connectivité et de la validité des objets dans la base de données.

git-help(1)
Affichage d’informations d’aide sur Git.

git-instaweb(1)
Navigation instantanée dans votre dépôt de travail dans gitweb.

git-merge-tree(1)
Effectue une fusion sans toucher à l’index ou à l’arbre de travail.

git-rerere(1)
Réutilisation de la résolution enregistrée des fusions conflictuelles.

git-show-branch(1)
Affichage des branches et de leurs commits.

git-verify-commit(1)
Vérification de la signature GPG des commits.

git-verify-tag(1)
Vérification de la signature GPG des étiquettes.

git-version(1)
Affichage des informations de version de Git.

git-whatchanged(1)
Affichage des journaux avec les différences introduites par chaque commit.

gitweb(1)
Interface web Git (interface web pour les dépôts Git).

Interagir avec d’autres systèmes

Ces commandes permettent d’interagir avec des systèmes de contrôle de version externes et avec d’autres personnes via des patchs envoyés par e-mail.

git-archimport(1)
Importation d’un dépôt GNU Arch dans Git.

git-cvsexportcommit(1)
Exportation d’un seul commit vers une zone de travail CVS.

git-cvsimport(1)
Récupération de vos données à partir d’un autre système de contrôle de version que les gens aiment détester.

git-cvsserver(1)
Émulateur de serveur CVS pour Git.

git-imap-send(1)
Envoi d’un ensemble de patchs à partir de l’entrée standard vers un dossier IMAP.

git-p4(1)
Importation et soumission à des dépôts Perforce.

git-quiltimport(1)
Application d’un ensemble de patchs Quilt à la branche actuelle.

git-request-pull(1)
Génération d’un résumé des modifications en attente.

git-send-email(1)
Envoi d’un ensemble de patchs par e-mail.

git-svn(1)
Fonctionnement bidirectionnel entre un dépôt Subversion et Git.

Réinitialisation, restauration et annulation

Il existe trois commandes avec des noms similaires : git reset, git restore et git revert.

git-revert(1) permet de créer un nouveau commit qui annule les modifications apportées par d’autres commits.

git-restore(1) permet de restaurer des fichiers dans l’arbre de travail à partir de l’index ou d’un autre commit. Cette commande ne met pas à jour votre branche. La commande peut également être utilisée pour restaurer des fichiers dans l’index à partir d’un autre commit.

git-reset(1) permet de mettre à jour votre branche, de déplacer la pointe afin d’ajouter ou de supprimer des commits de la branche. Cette opération modifie l’historique des commits.

git reset peut également être utilisé pour restaurer l’index, ce qui chevauche les fonctionnalités de git restore.

COMMANDES DE BAS NIVEAU (PLUMBING)

Bien que Git inclue sa propre couche de commandes conviviales (porcelain), ses commandes de bas niveau sont suffisantes pour prendre en charge le développement de couches de commandes alternatives. Les développeurs de ces couches de commandes pourraient commencer par lire la documentation sur git-update-index(1) et git-read-tree(1).

L’interface (entrée, sortie, ensemble d’options et sémantique) de ces commandes de bas niveau est conçue pour être beaucoup plus stable que celle des commandes de haut niveau, car ces commandes sont principalement destinées à être utilisées dans des scripts. L’interface des commandes de haut niveau est, en revanche, susceptible de changer afin d’améliorer l’expérience utilisateur.

La description suivante divise les commandes de bas niveau en commandes qui manipulent les objets (dans le dépôt, l’index et l’arborescence de travail), les commandes qui interrogent et comparent les objets, et les commandes qui déplacent les objets et les références entre les dépôts.

Commandes de manipulation

git-apply(1)

Applique un patch aux fichiers et/ou à l’index.

git-checkout-index(1)

Copie les fichiers de l’index vers l’arborescence de travail.

git-commit-graph(1)

Écrit et vérifie les fichiers de graphe de commit Git.

git-commit-tree(1)

Crée un nouvel objet de commit.

git-hash-object(1)

Calcule l’ID d’objet et crée éventuellement un objet à partir d’un fichier.

git-index-pack(1)

Crée un fichier d’index de paquet pour une archive de paquet existante.

git-merge-file(1)

Effectue une fusion de fichiers à trois voies.

git-merge-index(1)

Effectue une fusion pour les fichiers nécessitant une fusion.

git-mktag(1)

Crée un objet de tag avec une validation supplémentaire.

git-mktree(1)

Construit un objet d’arborescence à partir d’un texte formaté ls-tree.

git-multi-pack-index(1)

Écrit et vérifie les multi-index de paquets.

git-pack-objects(1)

Crée une archive de paquets d’objets.

git-prune-packed(1)

Supprime les objets supplémentaires qui sont déjà dans les fichiers de paquet.

git-read-tree(1)

Lit les informations d’arborescence dans l’index.

git-replay(1)

EXPÉRIMENTAL : Rejoue les commits sur une nouvelle base, fonctionne également avec les dépôts nus.

git-symbolic-ref(1)

Lit, modifie et supprime les références symboliques.

git-unpack-objects(1)

Décompresse les objets d’une archive de paquets.

git-update-index(1)

Enregistre les contenus des fichiers de l’arborescence de travail dans l’index.

git-update-ref(1)

Met à jour en toute sécurité le nom d’objet stocké dans une référence.

git-write-tree(1)

Crée un objet d’arborescence à partir de l’index actuel.

Commandes d’interrogation

git-cat-file(1)

Fournit le contenu ou les détails des objets du dépôt.

git-cherry(1)

Trouve les commits qui doivent encore être appliqués à la branche principale.

git-diff-files(1)

Compare les fichiers de l’arborescence de travail et de l’index.

git-diff-index(1)

Compare une arborescence avec l’arborescence de travail ou l’index.

git-diff-pairs(1)

Compare le contenu et le mode de paires de blobs fournis.

git-diff-tree(1)

Compare le contenu et le mode des blobs trouvés via deux objets d’arborescence.

git-for-each-ref(1)

Affiche des informations sur chaque référence.

git-for-each-repo(1)

Exécute une commande Git sur une liste de dépôts.

git-get-tar-commit-id(1)

Extrait l’ID de commit d’une archive créée à l’aide de git-archive.

git-ls-files(1)

Affiche des informations sur les fichiers dans l’index et l’arborescence de travail.

git-ls-remote(1)

Affiche les références d’un dépôt distant.

git-ls-tree(1)

Affiche le contenu d’un objet d’arborescence.

git-merge-base(1)

Trouve les ancêtres communs les plus pertinents pour une fusion.

git-name-rev(1)

Trouve des noms symboliques pour les révisions données.

git-pack-redundant(1)

Trouve les fichiers d’archive redondants.

git-rev-list(1)

Liste les objets de validation dans l’ordre chronologique inverse.

git-rev-parse(1)

Extrait et traite les paramètres.

git-show-index(1)

Affiche l’index d’archive.

git-show-ref(1)

Affiche les références d’un dépôt local.

git-unpack-file(1)

Crée un fichier temporaire avec le contenu d’un blob.

git-var(1)

Affiche une variable logique Git.

git-verify-pack(1)

Valide les fichiers d’archive Git.

En général, les commandes d’interrogation ne modifient pas les fichiers de l’arborescence de travail.

Synchronisation des dépôts

git-daemon(1)

Un serveur très simple pour les dépôts Git.

git-fetch-pack(1)

Reçoit les objets manquants d’un autre dépôt.

git-http-backend(1)

Implémentation côté serveur de Git sur HTTP.

git-send-pack(1)

Envoie des objets via le protocole Git vers un autre dépôt.

git-update-server-info(1)

Met à jour le fichier d’informations auxiliaires pour aider les serveurs simples.

Les commandes suivantes sont des commandes d’assistance utilisées par les commandes ci-dessus ; les utilisateurs finaux ne les utilisent généralement pas directement.

git-http-fetch(1)

Télécharge depuis un dépôt Git distant via HTTP.

git-http-push(1)

Envoie des objets via HTTP/DAV vers un autre dépôt.

git-receive-pack(1)

Reçoit ce qui est envoyé au dépôt.

git-shell(1)

Shell de connexion restreint pour l’accès Git uniquement via SSH.

git-upload-archive(1)

Envoie une archive au programme git-archive.

git-upload-pack(1)

Envoie des objets sous forme d’archive au programme git-fetch-pack.

Commandes d’assistance internes

Ce sont des commandes d’assistance internes utilisées par d’autres commandes ; les utilisateurs finaux ne les utilisent généralement pas directement.

git-check-attr(1)

Affiche les informations gitattributes.

git-check-ignore(1)

Débogage des fichiers gitignore / exclude.

git-check-mailmap(1)

Affiche les noms et adresses électroniques canoniques des contacts.

git-check-ref-format(1)

Garantit qu’un nom de référence est bien formé.

git-column(1)

Affiche les données en colonnes.

git-credential(1)

Récupère et stocke les informations d’identification de l’utilisateur.

git-credential-cache(1)

Assistant pour stocker temporairement les mots de passe en mémoire.

git-credential-store(1)

Assistant pour stocker les informations d’identification sur le disque.

git-fmt-merge-msg(1)

Produit un message de validation de fusion.

git-hook(1)

Exécute les hooks Git.

git-interpret-trailers(1)

Ajoute ou analyse des informations structurées dans les messages de validation.

git-mailinfo(1)

Extrait le patch et l’auteur d’un seul message électronique.

git-mailsplit(1)

Programme simple de fractionnement de boîte aux lettres UNIX.

git-merge-one-file(1)

Le programme d’assistance standard à utiliser avec git-merge-index.

git-patch-id(1)

Calcule un ID unique pour un patch.

git-sh-i18n(1)

Code de configuration i18n de Git pour les scripts shell.

git-sh-setup(1)

Code de configuration commun pour les scripts shell Git.

git-stripspace(1)

Supprime les espaces inutiles.

GUIDES

La documentation suivante contient des guides sur les concepts Git.

gitcore-tutorial(7)
Un tutoriel Git pour les développeurs.

gitcredentials(7)
Fournir les noms d’utilisateur et les mots de passe à Git.

gitcvs-migration(7)
Git pour les utilisateurs de CVS.

gitdiffcore(7)
Personnalisation de la sortie de diff.

giteveryday(7)
Un ensemble minimum de commandes utiles pour l’utilisation quotidienne de Git.

gitfaq(7)
Foire aux questions sur l’utilisation de Git.

gitglossary(7)
Un glossaire Git.

gitnamespaces(7)
Les espaces de noms Git.

gitremote-helpers(7)
Programmes d’assistance pour interagir avec les dépôts distants.

gitsubmodules(7)
Monter un dépôt dans un autre.

gittutorial(7)
Une introduction à Git.

gittutorial-2(7)
Une introduction à Git : deuxième partie.

gitworkflows(7)
Un aperçu des flux de travail recommandés avec Git.

RÉPERTOIRE, COMMANDES ET INTERFACES DE FICHIER

Cette documentation porte sur les répertoires et les interfaces de commande avec lesquelles les utilisateurs sont censés interagir directement. Voir --user-formats dans git-help(1) pour plus de détails sur les critères.

gitattributes(5)
Définir les attributs par chemin.

gitcli(7)
Interface en ligne de commande Git et conventions.

githooks(5)
Hooks utilisés par Git.

gitignore(5)
Spécifie les fichiers intentionnellement non suivis à ignorer.

gitmailmap(5)
Mapper les noms et/ou adresses e-mail de l’auteur/du validateur.

gitmodules(5)
Définir les propriétés des sous-modules.

gitrepository-layout(5)
Disposition du dépôt Git.

gitrevisions(7)
Spécifier les révisions et les plages pour Git.

FORMATS DE FICHIER, PROTOCOLES ET AUTRES INTERFACES POUR DÉVELOPPEURS

Cette documentation porte sur les formats de fichier, les protocoles de communication et les autres interfaces Git pour développeurs. Voir --developer-interfaces dans git-help(1).

gitformat-bundle(5)
Le format de fichier de bundle.

gitformat-chunk(5)
Formats de fichier basés sur des blocs.

gitformat-commit-graph(5)
Format du graphe de commit Git.

gitformat-index(5)
Format de l’index Git.

gitformat-pack(5)
Format de pack Git.

gitformat-signature(5)
Formats de signature cryptographique Git.

gitprotocol-capabilities(5)
Capacités des protocoles v0 et v1.

gitprotocol-common(5)
Éléments communs à divers protocoles.

gitprotocol-http(5)
Protocoles Git basés sur HTTP.

gitprotocol-pack(5)
Comment les packs sont transférés sur le réseau.

gitprotocol-v2(5)
Protocole réseau Git, version 2.

MÉCANISME DE CONFIGURATION

Git utilise un format de texte simple pour stocker les personnalisations par dépôt et par utilisateur. Un tel fichier de configuration peut ressembler à ceci :

#
# Un caractère « # » ou « ; » indique un commentaire.
#

; variables du noyau
[core]
; ne pas faire confiance aux modes de fichier
filemode = false

; identité de l’utilisateur
[user]
name = "Junio C Hamano"
email = "_"

Diverses commandes lisent le fichier de configuration et ajustent leur fonctionnement en conséquence. Voir git-config(1) pour une liste et plus de détails sur le mécanisme de configuration.

TERMINOLOGIE DES IDENTIFICATEURS

<object>
Indique le nom de l’objet pour tout type d’objet.

<blob>
Indique un nom d’objet blob.

<tree>
Indique un nom d’objet arborescent.

<commit>
Indique un nom d’objet de commit.

<tree-ish>
Indique un nom d’objet arborescent, de commit ou de balise. Une commande qui prend un argument <tree-ish> souhaite en fin de compte fonctionner sur un objet <tree>, mais déréférence automatiquement les objets <commit> et <tag> qui pointent vers un <tree>.

<commit-ish>

Indique le nom d’un objet de type commit ou tag. Une commande qui prend un argument souhaite finalement opérer sur un objet mais déréférence automatiquement les objets qui pointent vers un .

<type>

Indique qu’un type d’objet est requis. Actuellement, il peut s’agir de : blob, tree, commit ou tag.

<file>

Indique un nom de fichier, presque toujours relatif à la racine de la structure d’arborescence que décrit GIT_INDEX_FILE.

IDENTIFICATEURS SYMBOLIQUES

Toute commande Git acceptant un <object> peut également utiliser la notation symbolique suivante :

HEAD
indique la tête de la branche actuelle.

<tag>
un nom de tag valide (c’est-à-dire une référence refs/tags/<tag>).

<head>
un nom de tête valide (c’est-à-dire une référence refs/heads/<head>).

Pour une liste plus complète des manières de spécifier les noms d’objets, consultez la section « SPECIFYING REVISIONS » de gitrevisions(7).

STRUCTURE DE FICHIERS/RÉPERTOIRES

Veuillez consulter le document gitrepository-layout(5).

Consultez githooks(5) pour plus de détails sur chaque hook.

Les SCM de niveau supérieur peuvent fournir et gérer des informations supplémentaires dans le répertoire $GIT_DIR.

TERMINOLOGIE

Veuillez consulter gitglossary(7).

VARIABLES D’ENVIRONNEMENT

Diverses commandes Git tiennent compte des variables d’environnement et modifient leur comportement. Les variables d’environnement marquées comme « Booléennes » prennent leurs valeurs de la même manière que les variables de configuration booléennes, c’est-à-dire que « true », « yes », « on » et les nombres positifs sont considérés comme « oui », tandis que « false », « no », « off » et « 0 » sont considérés comme « non ».

Voici les variables :

Système

HOME

Spécifie le chemin d’accès au répertoire personnel de l’utilisateur. Sous Windows, si elle n’est pas définie, Git définira une variable d’environnement de processus égale à : $HOMEDRIVE$HOMEPATH si $HOMEDRIVE et $HOMEPATH existent ; sinon, $USERPROFILE si $USERPROFILE existe.

Le dépôt Git

Ces variables d’environnement s’appliquent à toutes les commandes Git principales. Remarque : il convient de noter qu’elles peuvent être utilisées ou remplacées par des SCM situés au-dessus de Git. Veillez donc à faire attention si vous utilisez une interface utilisateur tierce.

GIT_INDEX_FILE

Cette variable d’environnement spécifie un fichier d’index alternatif. Si elle n’est pas spécifiée, la valeur par défaut $GIT_DIR/index est utilisée.

GIT_INDEX_VERSION

Cette variable d’environnement spécifie la version d’index à utiliser lors de l’écriture du fichier d’index. Elle n’affectera pas les fichiers d’index existants. Par défaut, la version 2 ou 3 du fichier d’index est utilisée. Consultez git-update-index(1) pour plus d’informations.

GIT_OBJECT_DIRECTORY

Si le répertoire de stockage des objets est spécifié via cette variable d’environnement, les répertoires sha1 sont créés en dessous ; sinon, le répertoire par défaut $GIT_DIR/objects est utilisé.

GIT_ALTERNATE_OBJECT_DIRECTORIES

En raison de la nature immuable des objets Git, les anciens objets peuvent être archivés dans des répertoires partagés en lecture seule. Cette variable spécifie une liste de répertoires d’objets Git séparés par des deux-points (sous Windows, séparés par des points-virgules) qui peuvent être utilisés pour rechercher des objets Git. Les nouveaux objets ne seront pas écrits dans ces répertoires.

Les entrées commençant par " (guillemet double) seront interprétées comme des chemins de style C entre guillemets, en supprimant les guillemets doubles au début et à la fin et en respectant les séquences d’échappement de la barre oblique inversée. Par exemple, la valeur "chemin-avec-\"-et-:-dedans":chemin-vanilla a deux chemins : chemin-avec-"-et-:-dedans et chemin-vanilla.

GIT_DIR

Si la variable d’environnement GIT_DIR est définie, elle spécifie un chemin à utiliser au lieu de .git par défaut pour la base du dépôt. L’option de ligne de commande --git-dir définit également cette valeur.

GIT_WORK_TREE

Définit le chemin de l’arborescence de travail. Ceci peut également être contrôlé par l’option de ligne de commande --work-tree et la variable de configuration core.worktree.

GIT_NAMESPACE

Définit l’espace de noms Git ; voir gitnamespaces(7) pour plus de détails. L’option de ligne de commande --namespace définit également cette valeur.

GIT_CEILING_DIRECTORIES

Il doit s’agir d’une liste de chemins absolus séparés par des deux-points. Si elle est définie, il s’agit d’une liste de répertoires dans lesquels Git ne doit pas effectuer de changement de répertoire supérieur lors de la recherche d’un répertoire de dépôt (utile pour exclure les répertoires réseau à chargement lent). Elle n’exclura pas le répertoire de travail actuel ou un GIT_DIR défini dans la ligne de commande ou dans l’environnement. Normalement, Git doit lire les entrées de cette liste et résoudre les liens symboliques qui peuvent y être présents afin de les comparer au répertoire actuel. Toutefois, si même cet accès est lent, vous pouvez ajouter une entrée vide à la liste pour indiquer à Git que les entrées suivantes ne sont pas des liens symboliques et n’ont pas besoin d’être résolus ; par exemple, GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.

GIT_DISCOVERY_ACROSS_FILESYSTEM

Lorsqu’il est exécuté dans un répertoire qui ne contient pas de répertoire de dépôt « .git », Git tente de trouver un tel répertoire dans les répertoires parents afin de trouver le sommet de l’arborescence de travail, mais par défaut, il ne traverse pas les limites du système de fichiers. Cette variable booléenne peut être définie sur true pour indiquer à Git de ne pas s’arrêter aux limites du système de fichiers. Comme GIT_CEILING_DIRECTORIES, cela n’affectera pas un répertoire de dépôt explicite défini via GIT_DIR ou sur la ligne de commande.

GIT_COMMON_DIR

Si cette variable est définie sur un chemin, les fichiers qui ne font pas partie de l’arborescence de travail et qui se trouvent normalement dans $GIT_DIR seront prélevés dans ce chemin à la place. Les fichiers spécifiques à l’arborescence de travail, tels que HEAD ou l’index, sont prélevés dans $GIT_DIR. Voir gitrepository-layout(5) et git-worktree(1) pour plus de détails. Cette variable a une priorité inférieure à d’autres variables de chemin telles que GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY, etc.

GIT_DEFAULT_HASH

Si cette variable est définie, l’algorithme de hachage par défaut pour les nouveaux dépôts sera défini sur cette valeur. Cette valeur est ignorée lors du clonage et le paramètre du dépôt distant est toujours utilisé. La valeur par défaut est « sha1 ». Voir --object-format dans git-init(1).

GIT_DEFAULT_REF_FORMAT

Si cette variable est définie, le format par défaut du backend de référence pour les nouveaux dépôts sera défini sur cette valeur. La valeur par défaut est « files ». Voir --ref-format dans git-init(1).

GIT_AUTHOR_EMAIL

L’adresse e-mail utilisée pour l’identité de l’auteur lors de la création d’objets de commit ou de balises, ou lors de l’écriture des reflogs. Elle remplace les paramètres de configuration user.email et author.email.

GIT_AUTHOR_DATE

La date utilisée pour l’identité de l’auteur lors de la création d’objets de commit ou de balises, ou lors de l’écriture des reflogs. Voir git-commit(1) pour les formats valides.

GIT_COMMITTER_NAME

Le nom lisible par l’homme utilisé pour l’identité du committer lors de la création d’objets de commit ou de balises, ou lors de l’écriture des reflogs. Elle remplace les paramètres de configuration user.name et committer.name.

GIT_COMMITTER_EMAIL

L’adresse e-mail utilisée pour l’identité du committer lors de la création d’objets de commit ou de balises, ou lors de l’écriture des reflogs. Elle remplace les paramètres de configuration user.email et committer.email.

GIT_COMMITTER_DATE

La date utilisée pour l’identité du committer lors de la création d’objets de commit ou de balises, ou lors de l’écriture des reflogs. Voir git-commit(1) pour les formats valides.

EMAIL

L’adresse e-mail utilisée pour les identités de l’auteur et du committer si aucune autre variable d’environnement ou aucun autre paramètre de configuration pertinent n’est défini.

Diffs Git

GIT_DIFF_OPTS

Le seul paramètre valide est "--unified=?" ou "-u=?" pour définir le nombre de lignes de contexte affichées lorsqu’une diff unifiée est créée. Cela a la priorité sur toute valeur d’option "-U" ou "--unified" passée dans la ligne de commande Git diff.

GIT_EXTERNAL_DIFF

Lorsque la variable d’environnement GIT_EXTERNAL_DIFF est définie, le programme désigné par celle-ci est appelé pour générer des diffs, et Git n’utilise pas son mécanisme de diff intégré. Pour un chemin qui est ajouté, supprimé ou modifié, GIT_EXTERNAL_DIFF est appelé avec 7 paramètres :

path old-file old-hex old-mode new-file new-hex new-mode

où :

<old|new>-file
sont des fichiers que GIT_EXTERNAL_DIFF peut utiliser pour lire le contenu de <old|new>,

<old|new>-hex
sont les hachages SHA-1 à 40 hexadécimaux,

<old|new>-mode
sont la représentation octale des modes de fichier.

Les paramètres de fichier peuvent pointer vers le fichier de travail de l’utilisateur (par exemple, new-file dans "git-diff-files"), /dev/null (par exemple, old-file lorsqu’un nouveau fichier est ajouté) ou un fichier temporaire (par exemple, old-file dans l’index). GIT_EXTERNAL_DIFF ne doit pas se soucier de supprimer le fichier temporaire ; il est supprimé lorsque GIT_EXTERNAL_DIFF se termine.

Pour un chemin qui n’est pas fusionné, GIT_EXTERNAL_DIFF est appelé avec 1 paramètre, .

Pour chaque chemin pour lequel GIT_EXTERNAL_DIFF est appelé, deux variables d’environnement, GIT_DIFF_PATH_COUNTER et GIT_DIFF_PATH_TOTAL, sont définies.

GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE

Si cette variable d’environnement booléenne est définie sur true, la commande GIT_EXTERNAL_DIFF doit renvoyer le code de sortie 0 si elle considère que les fichiers d’entrée sont égaux ou 1 si elle les considère comme différents, comme diff(1). Si elle est définie sur false, ce qui est la valeur par défaut, la commande doit renvoyer le code de sortie 0, quel que soit l’égalité. Tout autre code de sortie fait que Git signale une erreur fatale.

GIT_DIFF_PATH_COUNTER
Un compteur basé sur 1, incrémenté de 1 pour chaque chemin.

GIT_DIFF_PATH_TOTAL
Le nombre total de chemins.

other
GIT_MERGE_VERBOSITY
Un nombre qui contrôle la quantité de sortie affichée par la stratégie de fusion récursive. Remplace
merge.verbosity. Voir git-merge(1).

GIT_PAGER
Cette variable d’environnement remplace $PAGER. Si elle est définie sur une chaîne vide ou sur la valeur
« cat », Git ne lancera pas de paginateur. Voir également l’option core.pager dans git-config(1).

GIT_PROGRESS_DELAY
Un nombre qui contrôle le nombre de secondes de délai avant d’afficher les indicateurs de progression optionnels.
Par défaut, il est de 2.

GIT_EDITOR
Cette variable d’environnement remplace $EDITOR et $VISUAL. Elle est utilisée par plusieurs commandes Git
lorsqu’un éditeur doit être lancé en mode interactif. Voir également git-var(1) et l’option
core.editor dans git-config(1).

GIT_SEQUENCE_EDITOR
Cette variable d’environnement remplace l’éditeur Git configuré lors de la modification de la liste de tâches
d’une rebase interactive. Voir également git-rebase(1) et l’option sequence.editor dans git-config(1).

GIT_SSH, GIT_SSH_COMMAND
Si l’une de ces variables d’environnement est définie, alors git fetch et git push utiliseront la
commande spécifiée au lieu de ssh lorsqu’ils doivent se connecter à un système distant. Les
paramètres de ligne de commande transmis à la commande configurée sont déterminés par la variante ssh.
Voir l’option ssh.variant dans git-config(1) pour plus de détails.

$GIT_SSH_COMMAND a la priorité sur $GIT_SSH, et est interprétée par le shell, ce qui permet d’inclure des arguments supplémentaires.  $GIT_SSH, en revanche, doit simplement être le chemin d’accès à un programme (qui peut être un script shell wrapper si des arguments supplémentaires sont nécessaires).

En général, il est plus facile de configurer les options souhaitées via votre fichier personnel .ssh/config.
Veuillez consulter la documentation ssh pour plus de détails.

GIT_SSH_VARIANT
Si cette variable d’environnement est définie, elle remplace la détection automatique de Git pour savoir si
GIT_SSH/GIT_SSH_COMMAND/core.sshCommand font référence à OpenSSH, plink ou tortoiseplink.
Cette variable remplace le paramètre de configuration ssh.variant qui a le même objectif.

GIT_SSL_NO_VERIFY
Définir et exporter cette variable d’environnement à n’importe quelle valeur indique à Git de ne pas vérifier
le certificat SSL lors de la récupération ou de la transmission via HTTPS.

GIT_ATTR_SOURCE
Définit le treeish à partir duquel gitattributes sera lu.

GIT_ASKPASS
Si cette variable d’environnement est définie, alors les commandes Git qui doivent acquérir des mots de passe ou
des phrases secrètes (par exemple, pour l’authentification HTTP ou IMAP) appelleront ce programme avec une
invite appropriée en tant qu’argument de ligne de commande et liront le mot de passe à partir de sa sortie standard.
Voir également l’option core.askPass dans git-config(1).

GIT_TERMINAL_PROMPT
Si cette variable d’environnement booléenne est définie sur false, git ne demandera pas d’informations sur le terminal
(par exemple, lors de la demande d’authentification HTTP).

GIT_CONFIG_GLOBAL, GIT_CONFIG_SYSTEM
Utilise la configuration des fichiers donnés au lieu des fichiers de configuration globaux ou système. Si
GIT_CONFIG_SYSTEM est défini, le fichier de configuration système défini au moment de la compilation (généralement
/etc/gitconfig) ne sera pas lu. De même, si GIT_CONFIG_GLOBAL est défini, ni $HOME/.gitconfig ni
$XDG_CONFIG_HOME/git/config ne seront lus. Peut être défini sur /dev/null pour ignorer la lecture des fichiers de configuration du niveau respectif.

GIT_CONFIG_NOSYSTEM

Indique s’il faut ignorer la lecture des paramètres du fichier de configuration système, $(prefix)/etc/gitconfig. Cette variable d’environnement booléenne peut être utilisée avec $HOME et $XDG_CONFIG_HOME pour créer un environnement prévisible pour un script exigeant, ou vous pouvez la définir sur « true » pour éviter temporairement d’utiliser un fichier /etc/gitconfig défectueux en attendant que quelqu’un ayant les autorisations nécessaires le corrige.

GIT_FLUSH

Si cette variable d’environnement booléenne est définie sur « true », les commandes telles que git blame (en mode incrémental), git rev-list, git log, git check-attr et git check-ignore forceront une vidange du flux de sortie après que chaque enregistrement aura été vidé. Si cette variable est définie sur « false », la sortie de ces commandes sera effectuée en utilisant une E/S entièrement mise en mémoire tampon. Si cette variable d’environnement n’est pas définie, Git choisira une vidange en mémoire tampon ou orientée vers les enregistrements en fonction du fait que stdout semble être redirigé vers un fichier ou non.

GIT_TRACE

Active les messages de trace généraux, par exemple l’expansion des alias, l’exécution des commandes intégrées et l’exécution des commandes externes.

Si cette variable est définie sur « 1 », « 2 » ou « true » (la comparaison n’est pas sensible à la casse), les messages de trace seront imprimés sur stderr.

Si la variable est définie sur une valeur entière supérieure à 2 et inférieure à 10 (strictement), Git interprétera cette valeur comme un descripteur de fichier ouvert et tentera d’écrire les messages de trace dans ce descripteur de fichier.

Alternativement, si la variable est définie sur un chemin absolu (commençant par un caractère /), Git l’interprétera comme un chemin de fichier et tentera d’y ajouter les messages de trace.

La suppression de la variable ou sa définition sur une chaîne vide, « 0 » ou « false » (insensible à la casse) désactive les messages de trace.

GIT_TRACE_FSMONITOR

Active les messages de trace pour l’extension du moniteur de système de fichiers. Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_TRACE_PACK_ACCESS

Active les messages de trace pour tous les accès à des packs. Pour chaque accès, le nom du fichier de pack et un décalage dans le pack sont enregistrés. Cela peut être utile pour résoudre certains problèmes de performances liés aux packs. Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_TRACE_PACKET

Active les messages de trace pour tous les paquets entrants ou sortants d’un programme donné. Cela peut aider à déboguer la négociation d’objets ou d’autres problèmes de protocole. La trace est désactivée pour un paquet commençant par « PACK » (mais voir GIT_TRACE_PACKFILE ci-dessous). Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_TRACE_PACKFILE

Active la trace des fichiers de pack envoyés ou reçus par un programme donné. Contrairement à d’autres sorties de trace, cette trace est verbatim : pas d’en-têtes et aucune mise entre guillemets des données binaires. Vous voudrez presque certainement la diriger vers un fichier (par exemple, GIT_TRACE_PACKFILE=/tmp/my.pack) plutôt que de l’afficher sur le terminal ou de la mélanger avec d’autres sorties de trace.

Notez que ceci n’est actuellement implémenté que pour le côté client des opérations de clonage et de récupération.

GIT_TRACE_PERFORMANCE

Active les messages de trace liés aux performances, par exemple le temps d’exécution total de chaque commande Git. Consultez GIT_TRACE pour connaître les options de sortie de trace disponibles.

GIT_TRACE_REFS

Active les messages de trace pour les opérations sur la base de données de références. Consultez GIT_TRACE pour connaître les options de sortie de trace disponibles.

GIT_TRACE_SETUP

Active les messages de trace affichant les répertoires .git, de l’arbre de travail et du répertoire de travail courant après que Git a terminé sa phase d’initialisation. Consultez GIT_TRACE pour connaître les options de sortie de trace disponibles.

GIT_TRACE_SHALLOW

Active les messages de trace qui peuvent aider au débogage du clonage ou de la récupération de référentiels peu profonds. Consultez GIT_TRACE pour connaître les options de sortie de trace disponibles.

GIT_TRACE_CURL

Active un vidage de trace curl complet de toutes les données entrantes et sortantes, y compris les informations descriptives, du protocole de transport git. Ceci est similaire à l’utilisation de curl --trace-ascii en ligne de commande. Consultez GIT_TRACE pour connaître les options de sortie de trace disponibles.

GIT_TRACE_CURL_NO_DATA

Lorsqu’une trace curl est activée (voir GIT_TRACE_CURL ci-dessus), ne videz pas les données (c’est-à-dire, ne videz que les lignes d’informations et les en-têtes).

GIT_TRACE2

Active des messages de trace plus détaillés de la bibliothèque « trace2 ». La sortie de GIT_TRACE2 est un format texte simple pour une lisibilité humaine.

Si cette variable est définie sur « 1 », « 2 » ou « true » (la comparaison n’étant pas sensible à la casse), les messages de trace seront affichés sur stderr.

Alternativement, si la variable est définie sur un chemin absolu (commençant par un caractère /), Git interprétera cela comme un chemin de fichier et tentera d’y ajouter les messages de trace. Si le chemin existe déjà et est un répertoire, les messages de trace seront écrits dans des fichiers (un par processus) dans ce répertoire, nommés en fonction du dernier composant de l’ID de session et d’un compteur facultatif (pour éviter les collisions de noms de fichiers).

De plus, si la variable est définie sur af_unix:[:], Git tentera d’ouvrir le chemin comme un socket de domaine Unix. Le type de socket peut être soit stream, soit dgram.

La désactivation de la variable, ou sa définition sur une chaîne vide, « 0 » ou « false » (sans tenir compte de la casse) désactive les messages de trace.

Consultez la documentation de Trace2[2] pour plus de détails.

GIT_TRACE2_EVENT

Ce paramètre écrit un format basé sur JSON qui est adapté à l’interprétation par machine. Consultez GIT_TRACE2 pour connaître les options de sortie de trace disponibles et la documentation de Trace2[2] pour plus de détails.

GIT_TRACE2_PERF

En plus des messages basés sur du texte disponibles dans GIT_TRACE2, ce paramètre écrit un format en colonnes pour comprendre les régions imbriquées. Consultez GIT_TRACE2 pour connaître les options de sortie de trace disponibles et la documentation de Trace2[2] pour plus de détails.

GIT_TRACE_REDACT

Par défaut, lorsque le traçage est activé, Git masque les valeurs des cookies, l'en-tête "Authorization:", l'en-tête "Proxy-Authorization:" et les URI des fichiers de paquets. Définissez cette variable d'environnement booléenne sur false pour empêcher cette suppression.

GIT_NO_REPLACE_OBJECTS

Définir et exporter cette variable d'environnement indique à Git d'ignorer les références de remplacement et de ne pas remplacer les objets Git.

GIT_LITERAL_PATHSPECS

Définir cette variable d'environnement booléenne sur true force Git à traiter tous les pathspecs littéralement, plutôt que comme des modèles glob. Par exemple, l'exécution de GIT_LITERAL_PATHSPECS=1 git log -- '*.c' recherchera les commits qui touchent le chemin *.c, et non les chemins qui correspondent au modèle glob *.c. Vous pourriez vouloir cela si vous fournissez des chemins littéraux à Git (par exemple, des chemins qui vous ont été fournis précédemment par git ls-tree, la sortie brute de diff, etc.).

GIT_GLOB_PATHSPECS

Définir cette variable d'environnement booléenne sur true force Git à traiter tous les pathspecs comme des modèles glob (également appelés "glob magic").

GIT_NOGLOB_PATHSPECS

Définir cette variable d'environnement booléenne sur true force Git à traiter tous les pathspecs comme des littéraux (également appelés "literal magic").

GIT_ICASE_PATHSPECS

Définir cette variable d'environnement booléenne sur true force Git à traiter tous les pathspecs en ignorant la casse.

GIT_NO_LAZY_FETCH

Définir cette variable d'environnement booléenne sur true indique à Git de ne pas récupérer paresseusement les objets manquants du dépôt de promesse à la demande.

GIT_REFLOG_ACTION

Lorsqu'une référence est mise à jour, des entrées de journal des références sont créées pour enregistrer la raison pour laquelle la référence a été mise à jour (qui est généralement le nom de la commande de niveau supérieur qui a mis à jour la référence), en plus des valeurs anciennes et nouvelles de la référence. Une commande Porcelain scriptée peut utiliser la fonction d'assistance set_reflog_action dans git-sh-setup pour définir son nom dans cette variable lorsqu'elle est invoquée en tant que commande de niveau supérieur par l'utilisateur final, afin qu'elle soit enregistrée dans le corps du journal des références.

GIT_REF_PARANOIA

Si cette variable d'environnement booléenne est définie sur false, ignorez les références cassées ou mal nommées lors de l'itération sur des listes de références. Normalement, Git tentera d'inclure toutes ces références, ce qui peut entraîner l'échec de certaines opérations. Cela est généralement préférable, car les opérations potentiellement destructrices (par exemple, git-prune(1)) sont mieux vaut qu'elles abandonnent plutôt que d'ignorer les références cassées (et de considérer ainsi l'historique auquel elles pointent comme ne valant pas la peine d'être sauvegardé). La valeur par défaut est 1 (c'est-à-dire, être paranoïaque quant à la détection et l'annulation de toutes les opérations). Vous n'aurez normalement pas besoin de définir cette valeur sur 0, mais cela peut être utile lorsque vous essayez de récupérer des données d'un dépôt corrompu.

GIT_COMMIT_GRAPH_PARANOIA

Lors du chargement d'un objet de commit à partir du graphe de commit, Git effectue une vérification d'existence de l'objet dans la base d'objets. Cela est fait pour éviter les problèmes avec les graphes de commits obsolètes qui contiennent des références à des commits déjà supprimés, mais cela a un coût en termes de performances.

La valeur par défaut est "false", ce qui désactive le comportement susmentionné. Définir cette valeur sur "true" active la vérification d'existence afin que les commits obsolètes ne soient jamais renvoyés à partir du graphe de commit, au prix des performances.

GIT_ALLOW_PROTOCOL

Si cette variable d'environnement est définie sur une liste de protocoles séparés par des deux-points, elle se comporte comme si protocol.allow était défini sur never, et que chacun des protocoles répertoriés a protocol.<name>.allow défini sur always (en remplaçant toute configuration existante). Voir la description de protocol.allow dans git-config(1) pour plus de détails.

GIT_PROTOCOL_FROM_USER

Définissez cette variable d'environnement booléenne sur false pour empêcher l'utilisation de protocoles par fetch/push/clone qui sont configurés au niveau de l'utilisateur. Ceci est utile pour restreindre l'initialisation récursive des sous-modules à partir d'un dépôt non fiable ou pour les programmes qui fournissent des URL potentiellement non fiables aux commandes git. Voir git-config(1) pour plus de détails.

GIT_PROTOCOL

Réservé à un usage interne. Utilisé pour la négociation du protocole réseau. Contient une liste de clés séparées par des deux-points, avec des valeurs facultatives <key>[=<value>]. La présence de clés et de valeurs inconnues doit être ignorée.

Notez que les serveurs peuvent avoir besoin d'être configurés pour autoriser cette variable à être transmise sur certains protocoles. Elle sera propagée automatiquement lors de l'accès aux dépôts locaux (c'est-à-dire file:// ou un chemin de système de fichiers), ainsi que sur le protocole git://. Pour git-over-http, cela devrait fonctionner automatiquement dans la plupart des configurations, mais voir la discussion dans git-httpbackend(1). Pour git-over-ssh, le serveur SSH peut avoir besoin d'être configuré pour autoriser les clients à transmettre cette variable (par exemple, en utilisant AcceptEnv GIT_PROTOCOL avec OpenSSH).

Cette configuration est facultative. Si la variable n'est pas propagée, les clients reviendront au protocole « v0 » d'origine (mais pourraient manquer certaines améliorations de performances ou fonctionnalités). Cette variable n'affecte actuellement que les clones et les récupérations ; elle n'est pas encore utilisée pour les envois (mais pourrait l'être à l'avenir).

GIT_OPTIONAL_LOCKS

Si cette variable d'environnement booléenne est définie sur false, Git exécutera toutes les opérations demandées sans effectuer d'opérations secondaires facultatives qui nécessitent la prise d'un verrou. Par exemple, cela empêchera git status d'actualiser l'index en tant qu'effet secondaire. Ceci est utile pour les processus s'exécutant en arrière-plan qui ne souhaitent pas provoquer de conflit de verrou avec d'autres opérations sur le dépôt. La valeur par défaut est 1.

GIT_REDIRECT_STDIN, GIT_REDIRECT_STDOUT, GIT_REDIRECT_STDERR

Uniquement pour Windows : permet de rediriger les descripteurs de flux d’entrée/sortie/erreur standard vers les chemins spécifiés par les variables d’environnement. Ceci est particulièrement utile dans les applications multithread où la méthode standard pour transmettre les descripteurs standard via CreateProcess() n’est pas une option, car cela nécessiterait que les descripteurs soient marqués comme héritables (et par conséquent, chaque processus généré hériterait d’eux, ce qui pourrait bloquer les opérations Git régulières). Le cas d’utilisation principal est d’utiliser des canaux nommés pour la communication (par exemple, \\.\pipe\my-git-stdin-123).

Deux valeurs spéciales sont prises en charge : off fermera simplement le descripteur de flux standard correspondant, et si GIT_REDIRECT_STDERR est 2>&1, la sortie d’erreur standard sera redirigée vers le même descripteur que la sortie standard.

GIT_PRINT_SHA1_ELLIPSIS (obsolète)

Si défini sur oui, affiche une ellipse après une valeur SHA-1 (abrégée). Cela affecte les indications de HEAD détachés (git-checkout(1)) et la sortie brute de diff (git-diff(1)). L’affichage d’une ellipse dans les cas mentionnés n’est plus considéré comme approprié et la prise en charge de cette fonctionnalité sera probablement supprimée dans un avenir proche (ainsi que la variable).

GIT_ADVICE

Si défini sur 0, désactive tous les messages d’aide. Ces messages sont destinés à fournir des indications aux utilisateurs pour les aider à sortir de situations problématiques ou à tirer parti de nouvelles fonctionnalités. Les utilisateurs peuvent désactiver des messages individuels à l’aide des clés de configuration advice.*. Ces messages peuvent perturber les outils qui exécutent des processus Git, cette variable est donc disponible pour désactiver les messages. (L’option globale --no-advice est également disponible, mais les anciennes versions de Git peuvent échouer lorsque cette option n’est pas comprise. La variable d’environnement sera ignorée par les versions de Git qui ne la comprennent pas.)

DISCUSSION

Plus de détails sont disponibles dans le chapitre sur les concepts Git du manuel d’utilisation [3] et dans gitcore-tutorial(7).

Un projet Git se compose généralement d’un répertoire de travail avec un sous-répertoire « .git » au niveau supérieur.
Le répertoire .git contient, entre autres, une base de données d’objets compressée qui représente l’historique complet du projet,
un fichier « index » qui lie cet historique au contenu actuel de l’arborescence de travail, et des pointeurs nommés dans cet historique,
tels que les balises et les têtes de branche.

La base de données d’objets contient des objets de trois types principaux : les blobs, qui contiennent des données de fichiers ; les arbres, qui pointent vers des blobs et d’autres arbres pour construire des hiérarchies de répertoires ; et les commits, qui référencent chacun un seul arbre et un certain nombre de commits parents.

Le commit, équivalent à ce que d’autres systèmes appellent un « jeu de modifications » ou une « version », représente une étape dans l’historique du projet, et chaque parent représente l’étape immédiatement précédente. Les commits avec plus d’un parent représentent des fusions de branches de développement indépendantes.

Tous les objets sont nommés par le hachage SHA-1 de leur contenu, généralement écrit sous forme de chaîne de 40 hexadécimaux. De tels noms sont globalement uniques. L’ensemble de l’historique menant à un commit peut être authentifié en signant ce commit. Un quatrième type d’objet, la balise, est fourni à cette fin.

Lors de leur création, les objets sont stockés dans des fichiers individuels, mais pour plus d’efficacité, ils peuvent ensuite être compressés ensemble dans des « fichiers pack ».

Les pointeurs nommés appelés refs marquent des points intéressants dans l’historique. Un ref peut contenir le nom SHA-1 d’un objet ou le nom d’un autre ref (ce dernier est appelé un « ref symbolique »). Les refs dont les noms commencent par refs/head/ contiennent le nom SHA-1 du commit le plus récent (ou « tête ») d’une branche en cours de développement. Les noms SHA-1 des balises d’intérêt sont stockés dans refs/tags/. Un ref symbolique nommé HEAD contient le nom de la branche actuellement extraite.

Le fichier d'index est initialisé avec une liste de tous les chemins, et pour chaque chemin, un objet blob et un ensemble d'attributs. L'objet blob représente le contenu du fichier tel qu'il était au moment du dernier commit de la branche actuelle. Les attributs (date de dernière modification, taille, etc.) sont extraits du fichier correspondant dans l'arborescence de travail. Les modifications ultérieures apportées à l'arborescence de travail peuvent être détectées en comparant ces attributs. L'index peut être mis à jour avec de nouveaux contenus, et de nouveaux commits peuvent être créés à partir du contenu stocké dans l'index.

L'index est également capable de stocker plusieurs entrées (appelées « étapes ») pour un nom de fichier donné. Ces étapes sont utilisées pour conserver les différentes versions non fusionnées d'un fichier lorsqu'une fusion est en cours.

SÉCURITÉ

Certaines options de configuration et fichiers de hooks peuvent amener Git à exécuter des commandes shell arbitraires. Étant donné que la configuration et les hooks ne sont pas copiés à l'aide de git clone, il est généralement sûr de cloner des dépôts distants avec du contenu non fiable, de les examiner avec git log, etc.

Cependant, il n'est pas sûr d'exécuter des commandes Git dans un répertoire .git (ou l'arborescence de travail qui l'entoure) lorsque ce répertoire .git provient d'une source non fiable. Les commandes dans sa configuration et ses hooks sont exécutées de la manière habituelle.

Par défaut, Git refusera de s'exécuter lorsque le dépôt appartient à une personne autre que l'utilisateur exécutant la commande. Voir l'entrée pour safe.directory dans git-config(1). Bien que cela puisse vous protéger dans un environnement multi-utilisateur, notez que vous pouvez également acquérir des dépôts non fiables qui vous appartiennent (par exemple, si vous extrayez un fichier zip ou tarball à partir d'une source non fiable). Dans de tels cas, vous devrez d'abord « nettoyer » le dépôt non fiable.

Si vous avez un répertoire .git non fiable, vous devez d'abord le cloner avec git clone --no-local pour obtenir une copie propre. Git restreint l'ensemble des options et des hooks qui seront exécutés par upload-pack, qui gère la partie serveur d'un clone ou d'une extraction, mais soyez conscient que la surface d'attaque contre upload-pack est importante, ce qui comporte donc un certain risque. La chose la plus sûre est de servir le dépôt en tant qu'utilisateur non privilégié (soit via git-daemon(1), ssh, ou en utilisant d'autres outils pour modifier les ID d'utilisateur). Voir la discussion dans la section SÉCURITÉ de git-upload-pack(1).

DOCUMENTATION SUPPLÉMENTAIRE

Consultez les références dans la section « description » pour commencer à utiliser Git. Ce qui suit est probablement plus détaillé que nécessaire pour un nouvel utilisateur.

Le chapitre sur les concepts Git du manuel utilisateur[3] et gitcore-tutorial(7) fournissent tous deux des introductions à l'architecture Git sous-jacente.

Consultez gitworkflows(7) pour un aperçu des flux de travail recommandés.

Consultez également les documents howto[4] pour obtenir quelques exemples utiles.

Les internes sont documentés dans la documentation de l'API Git[5].

Les utilisateurs qui migrent depuis CVS peuvent également consulter gitcvs-migration(7).

AUTEURS

Git a été créé par Linus Torvalds et est actuellement maintenu par Junio C Hamano. De nombreuses contributions proviennent de la liste de diffusion Git <_[6]>. https://openhub.net/p/git/contributors/summary vous donne une liste plus complète des contributeurs.

Si vous disposez d’une copie du dépôt git.git, la sortie des commandes git-shortlog(1) et git-blame(1) peut vous indiquer les auteurs des différentes parties du projet.

SIGNALEMENT DES BUGS

Signalez les bugs à la liste de diffusion Git <_[6]>, où le développement et la maintenance sont principalement effectués. Vous n’avez pas besoin d’être abonné à la liste pour y envoyer un message. Consultez l’archive de la liste à l’adresse https://lore.kernel.org/git pour consulter les rapports de bugs et autres discussions précédents.

Les problèmes liés à la sécurité doivent être signalés en privé à la liste de diffusion Git Security <_[7]>.

VOIR AUSSI

gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7), gitglossary(7), gitcoretutorial(7), gitcli(7), Le manuel d’utilisation de Git[1], gitworkflows(7)

GIT

Fait partie de la suite git(1)

NOTES

    Manuel d’utilisation de Git
file:///usr/share/doc/git/html/user-manual.html

    Documentation de Trace2
file:///usr/share/doc/git/html/technical/api-trace2.html

    Chapitre sur les concepts Git du manuel d’utilisation
file:///usr/share/doc/git/html/user-manual.html#git-concepts

howto
file:///usr/share/doc/git/html/howto-index.html

    Documentation de l’API Git
file:///usr/share/doc/git/html/technical/api-index.html

_
mailto:_

_
mailto:_