Git
Français ▾ Topics ▾ Latest version ▾ git last updated in 2.47.0

NOM

git - le traqueur de contenu stupide

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>=<var-env>] <commande> [<args>]

DESCRIPTION

Git est un système de gestion de révision rapide, extensible et distribué avec un ensemble de commandes inhabituellement riche qui fournit à la fois des opérations de haut niveau et un accès complet aux structures de bas niveau.

Voir gittutorial[7] pour démarrer, puis voir giteveryday[7] pour un ensemble minimal utile de commandes. Le manuel utilisateur de Git contient une introduction plus approfondie.

Aprs avoir maîtrisé les concepts de base, vous pouvez revenir à cette page pour apprendre les commandes que Git offre. Vous pouvez en apprendre plus sur chaque commande Git avec « git help command ». La page de manuel de gitcli[7] fournit un aperçu de la syntaxe de commande de la ligne de commande.

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

OPTIONS

-v
--version

Afficher la version de la suite Git de laquelle le programme git provient.

Cette option est convertie en interne en git version... et accepte les mêmes options que la commande git-version[1]. Si l’on --help est donnée aussi , elle a préséance sur --version.

-h
--help

Afficher le synopsis et les liste des commandes les plus utilisées. Si l’option --all ou -a est fournie alors toutes les commandes disponibles sont affichées. si une commande Git est fournie, cette option affiche la page de manuel pour cette commande.

Les autres options sont disponibles pour contrôler comment la page de manuel est affichée. Voir git-help[1] pour plus d’information, parce que git --help ... est convertie en interne en git help ....

-C <chemin>

Démarrer comme si git était lancé depuis <chemin> au lieu du répertoire de travail actuel. Quand plusieurs options -C sont fournies, chaque -C <chemin> non-absolu supplémentaire est interprété relativement au -C <chemin> précédent. Si <chemin> est présent mais vide, c-à-d -C "", alors le répertoire de travail courant est laissé inchangé.

Cette option affecte les options qui attendent de chemins comme --git-dir et --work-tree en ce que leurs interprétations des noms de chemins seront relatives au répertoire de travail défini 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>

Passer un paramètre de configuration à la commande. La valeur fournie surchargera la valeur des fichiers des configuration. Le <nom> a le même format que listé par ‘git config’ (sous-clés séparées par des points).

Notez qu’omettre le = dans git -c foo.bar ... est permis et positionne foo.bar à la valeur booléenne true (de la même manière que le ferait [foo]bar dans un fichier de configuration). Si le = est inclus mais avec une valeur vide (comme git -c foo.bar= ...), cela positionne foo.bar à la chaîne vide que git config --type=bool convertira en false.

--config-env=<nom>=<var-env>

À l’instar de -c <nom>=<valeur>, donner une valeur à la variable de configuration <nom>, où <envvar> est le nom d’une variable d’environnement depuis laquelle récupérer la valeur. Contrairement à -c il n’y a pas de raccourci pour définir directement la valeur à une chaîne vide, la variable d’environnement elle-même doit être définie à la chaîne vide. Il s’agit d’une erreur si le envvar n’existe pas dans l’environnement. <envvar> ne peut pas contenir un signe égal pour éviter toute ambiguïté avec <nom> en contenant un.

Ceci est utile pour les cas où vous voulez passer des options de configuration transitoires à git, mais le faire sur les systèmes d’exploitation où d’autres processus pourraient être en mesure de lire votre ligne de commande (par exemple /proc/self/cmdline), mais pas votre environnement (par exemple /proc/self/environ). C’est le comportement par défaut sur Linux, mais peut ne pas l’être sur votre système.

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

--exec-path[=<chemin>]

Chemin dans lequel les programmes de base de Git sont installés. Cela peut aussie être géré en positionnant la variable d’environnement GIT_EXEC_PATH. Si aucun chemin n’est spécifié, git affichera la valeur actuelle, puis sortira.

--html-path

Afficher le chemin, sans la barre finale, où la documentation HTML de Git est installé et sortir.

--man-path

Afficher le chemin manpath (voir man(1)) pour les pages de manuel de cette version de Git et sortir.

--info-path

Afficher le chemin où sont installés les fichiers Info documentant cette version de Git et sortir.

-p
--paginate

Redirige toutes les sorties dans less (ou $PAGER, si positionné) si la sortie standard est un terminal. Cela surcharge les options de configuration pager.<cmd> (voir la section « Mécanisme de configuration » ci-dessous).

-P
--no-pager

Ne pas rediriger la sortie de Git dans un pageur.

--git-dir=<chemin>

Règle le chemin vers le dépôt (répertoire ".git"). Ceci peut aussi être contrôlé en réglant la variable d’environnement GIT_DIR. Ce peut être un chemin absolu ou relatif au répertoire de travail actuel.

Spécifier l’emplacement du répertoire ".git" en utilisant cette option (ou la variable d’environnement GIT_DIR) désactive la découverte de dépôt, qui tente de trouver un répertoire avec un sous-répertoire ".git" (ce qui est la façon dont le dépôt et le niveau supérieur de l’arbre de travail sont découverts), et indique à Git que vous êtes au niveau supérieur de l’arbre de travail. Si vous n’êtes pas dans le répertoire de niveau supérieur de l’arbre de travail, vous devez dire à Git où se trouve le niveau supérieur de l’arbre de travail, avec l’option --work-tree=<chemin> (ou la variable d'environnement`GIT_WORK_TREE)

Si vous voulez juste lancer git comme s’il était démarré dans <chemin>, utilisez git -C <chemin>.

--work-tree=<chemin>

Régler le chemin du répertoire de travail. Ce peut être un chemin absolu ou un chemin relatif au répertoire de travail actuel. Ceci peut aussi être contrôlé en réglant la variable d’environnement GIT_WORK_TREE et la variable de configuration core.worktree (voir core.worktree dans git-config[1] pour une discussion plus détaillée).

--namespace=<chemin>

Régler l’espace de nommage Git. Voir gitnamespaces[7] pour plus de détails. Équivalent à régler la variable d’environnement GIT_NAMESPACE.

--bare

Traiter le dépôt comme un dépôt nu. Si l’environnement GIT_DIR n’est pas défini, alors il est défini au répertoire de travail actuel.

--no-replace-objects

Ne pas utiliser des refs de remplacement pour remplacer des objets Git. Voir git-replace[1] pour de plus amples informations. Ceci équivaut à l’exportation de la variable d’environnement GIT_NO_REPLACE_OBJECTS avec n’importe quelle valeur. Voir git-replace[1] pour de plus amples d’informations.

--no-lazy-fetch

Do not fetch missing objects from the promisor remote on demand. Useful together with git cat-file -e <object> to see if the object is locally available. This is equivalent to setting the GIT_NO_LAZY_FETCH environment variable to 1.

--no-optional-locks

Ne pas effectuer des opérations optionnelles qui nécessitent des verrouillages. Ceci équivaut à mettre GIT_OPTIONAL_LOCKS à 0.

--no-advice

Disable all advice hints from being printed.

--literal-pathspecs

Traier les spécificateurs de chemins littéralement (c-à-d sans jokers ni magie de pathspec). Ceci est équivalent à régler la variable d’environnement GIT_LITERAL_PATHSPECS à 1.

--glob-pathspecs

Ajouter la magie « glob » à tous les spécificateurs de chemin. C’est équivalent à régler la variable d’environnement GIT_GLOB_PATHSPECS à 1. La désactivation du traitement glob sur des spécificateurs de chemin spécifiques peut être réalisée en utilisant le préfixe magique ":(litera)"

--noglob-pathspecs

Ajouter la magie « literal » à tous les spécificateurs de chemin. C’est équivalent à régler la variable d’environnement GIT_NOGLOB_PATHSPECS à 1. L’activation du traitement glob sur des spécificateurs de chemin spécifiques peut être réalisée en utilisant le préfixe magique ":(glob)"

--icase-pathspecs

Ajouter la magie « icase » à tous les spécificateurs de chemin. C’est équivalent à régler la variable d’environnement GIT_ICASE_PATHSPECS à 1.

--list-cmds=<groupe>[,<groupe>…​]

Liste les commandes par groupe. Il s’agit d’une option interne/expérimentale et peut changer ou être retirée à l’avenir. Les groupes pris en charge sont les suivants : builtins, parseopt (commandes intégrées qui utilisent parse-options), main (toutes commandes dans le répertoire libexec), autres (toutes autres commandes dans $PATH qui ont un préfixe git), list-<catégorie> (voir les catégories dans command-list.txt), nohelpers (exclure les commandes assistantes), alias et config (récupère la liste de commandes depuis la variable de configuration completion.commands)

--attr-source=<arbre-esque>

Lire les gitattributs depuis <arbre-esque> au lieu de l’arbre-de-travail. Voir gitattributes[5]. C’est équivalent à régler la variable d’environnement GIT_ATTR_SOURCE.

COMMANDES GIT

Nous divisons Git entre les commandes de haut niveau ("porcelaine") et de bas niveau ("plomberie").

Commandes de haut niveau (porcelaine)

Nous séparerons les commandes de porcelaine entre commandes principales et quelques utilitaires auxiliaires.

Commandes Porcelaine Principales

git-add[1]

Ajouter le contenu de fichiers à l’index.

git-am[1]

Appliquer une série de rustines depuis des fichiers mailbox.

git-archive[1]

Créer une archive des fichiers depuis un arbre nommé.

git-bisect[1]

Trouver par recherche binaire la modification qui a introduit un bogue.

git-branch[1]

Lister, créer ou supprimer des branches.

git-bundle[1]

Déplacer les objets et références par archive.

git-checkout[1]

Basculer de branche ou restaurer les fichiers des arbres de travail.

git-cherry-pick[1]

Appliquer les modifications introduites par des commits existants.

git-citool[1]

Alternative graphique à git-commit.

git-clean[1]

Supprimer des fichiers non-suivis depuis un arbre de travail.

git-clone[1]

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

git-commit[1]

Enregistrer les modifications dans le dépôt.

git-describe[1]

Baptiser un objet avec un nom lisible basé sur une référence disponible.

git-diff[1]

Afficher les modifications entre les validations, entre validation et copie de travail, etc.

git-fetch[1]

Télécharger les objets et références depuis un autre dépôt.

git-format-patch[1]

Préparer les rustines pour soumission par courriel.

git-gc[1]

Effacer les fichiers non-nécessaires et optimiser le dépôt local.

git-grep[1]

Afficher les lignes correspondant à un motif.

git-gui[1]

Une interface graphique portable pour Git.

git-init[1]

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

git-log[1]

Afficher l’historique des validations.

git-maintenance[1]

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

git-merge[1]

Fusionner deux ou plusieurs historiques de développement ensemble.

git-mv[1]

Déplacer ou renommer un fichier, un répertoire, ou un lien symbolique.

git-notes[1]

Ajouter ou inspecter les notes d’un objet.

git-pull[1]

Rapatrier et intégrer un autre dépôt ou une branche locale.

git-push[1]

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

git-range-diff[1]

Comparer deux plages de commits (par exemple deux versions d’une branche).

git-rebase[1]

Réappliquet des commits sur le sommet de l’autre base.

git-reset[1]

Réinitialiser la HEAD actuelle à l’état spécifié.

git-restore[1]

Corriger les fichiers de l’arbre de travail.

git-revert[1]

Inverser des commits existants.

git-rm[1]

Supprimer des fichiers d’un arbre de travail ou de l’index.

git-shortlog[1]

Résumer la sortie de git log.

git-show[1]

Afficher différents types d’objets.

git-sparse-checkout[1]

Réduire votre arbre de travail à un sous-ensemble de fichiers suivis.

git-stash[1]

Remiser les modifications d’un répertoire de travail sale.

git-status[1]

Afficher l’état de l’arbre de travail.

git-submodule[1]

Initialiser, mettre à jour et inspecter les sous-modules.

git-switch[1]

Basculer de branche.

git-tag[1]

Créer, lister, supprimer ou vérifier un objet d’étiquette signé avec GPG.

git-worktree[1]

Gérer des arbres de travail multiples.

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]

Voir et régler les options globales ou de dépôt.

git-fast-export[1]

Exporteur de données Git.

git-fast-import[1]

Moteur pour les importateurs rapides de données Git.

git-filter-branch[1]

Réécrire les branches.

git-mergetool[1]

Lancer les outils de résolution de conflit de fusion pour résoudre les conflits de fusion.

git-pack-refs[1]

Empaqueter les têtes et les étiquettes pour un accès efficace au dépôt.

git-prune[1]

Élaguer tous les objets non joignables de la base de données d’objets.

git-reflog[1]

Gérer l’information de reflog.

git-refs[1]

Accès bas niveau aux refs.

git-remote[1]

Gerer un ensemble de dépôts suivis.

git-repack[1]

Empaqueter les objets non-empaquetés dans un dépôt.

git-replace[1]

Créer, lister, supprimer des référence pour remplacer des objets.

Interrogateurs :

git-annotate[1]

Annoter les lignes du fichier avec l’information de commit.

git-blame[1]

Montrer la révision et l’auteur qui ont modifié en dernier chaque ligne d’un fichier.

git-bugreport[1]

Collecter des informations pour que l’utilisateur dépose un rapport de bogue.

git-count-objects[1]

Compter le nombre non-empaqueté d’objets et leur consommation d’espace disque.

git-diagnose[1]

Générer une archive zip des informations de diagnostic.

git-difftool[1]

Afficher les modifications en utilisant les outils habituels de diff.

git-fsck[1]

Vérifie la connectivité et la validité des objets en base de données.

git-help[1]

Afficher l’information d’aide à propos de Git.

git-instaweb[1]

Naviguer instantanément votre dépôt de travail dans gitweb.

git-merge-tree[1]

Effectuer la fusion sans toucher à l’index ou à l’arbre de travail.

git-rerere[1]

Réutiliser une résolution enregistrée de fusions conflictuelles.

git-show-branch[1]

Afficher les branches et leurs commits.

git-verify-commit[1]

Vérifier la signature GPG de commits.

git-verify-tag[1]

Vérifier la signature GPG d’étiquettes.

git-version[1]

Afficher l’information de version à propos de Git.

git-whatchanged[1]

Afficher les journaux avec les différences que chaque commit introduit.

gitweb[1]

Interface web de Git (frontal web vers les dépôts Git).

Interaction avec d’autres développeurs

Ces commandes permettent d’interagir avec autre SCM et avec d’autres personnes via rustines envoyées par courriel.

git-archimport[1]

Importer dans Git un dépôt GNU Arch.

git-cvsexportcommit[1]

Exporter un commit unique en extraction CVS.

git-cvsimport[1]

Sauver vos données depuis un autre SCM qu’on aime haïr.

git-cvsserver[1]

Un émulateur de serveur CVS pour Git.

git-imap-send[1]

Envoyer un ensemble de patchs depuis stdin vers un répertoire IMAP.

git-p4[1]

Importer depuis et soumettre vers des dépôts Perforce.

git-quiltimport[1]

Appliquer un patchset quilt sur la branche courante.

git-request-pull[1]

Générer une résumé des modifications en attentes.

git-send-email[1]

Envoyer un ensemble de rustines comme courriels.

git-svn[1]

Opération Bidirectionnelle entre un dépôt Subversion et Git.

Réinitialiser, restaurer et revenir

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

  • git-revert[1] sert à faire un nouveau commit qui inverse les modifications apportées par d’autres commits.

  • git-restore[1] consiste à 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 depuis un autre commit.

  • git-reset[1] consiste à mettre à jour votre branche, en déplaçant le sommet 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, à la manière de git restore.

Commandes de bas niveau (plomberie)

Bien que Git comprend sa propre couche de porcelaine, ses commandes de bas niveau sont suffisantes pour développer de porcelaines alternatives. Les développeurs de ces porcelaines devraient commencer par la lecture de git-update-index[1] et git-read-tree[1].

L’interface (entrée, sortie, ensemble d’options et sémantique) à ces commandes de bas niveau est censée être beaucoup plus stable que les commandes de niveau Porcelaine, parce que ces commandes sont principalement destinées à une utilisation scriptée. L’interface des commandes Porcelaine en revanche est sujette à changement afin d’améliorer l’expérience de l’utilisateur final.

La description suivante divise les commandes de bas niveau en commandes qui manipulent les objets (dans le dépôt, l’index et l’arbre de travail), celles 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]

Appliquer un correctif à des fichiers et/ou à l’index.

git-checkout-index[1]

Copier des fichiers depuis l’index dans l’arbre de travail.

git-commit-graph[1]

Écrire et vérifier les fichiers de graphe de commit Git.

git-commit-tree[1]

Créer un nouvel objet commit.

git-hash-object[1]

Calculer l’ID d’objet et créer optionnellement un objet depuis un fichier.

git-index-pack[1]

Construire un fichier d’index pack depuis une archive compactée existante.

git-merge-file[1]

Lancer une fusion à 3 points.

git-merge-index[1]

Lancer une fusion à 3 points pour les fichiers à fusionner.

git-mktag[1]

Créer un objet étiquette avec une validation supplémentaire.

git-mktree[1]

Construire un objet arbre depuis du texte au format ls-tree.

git-multi-pack-index[1]

Écrire et vérifier les index multi-paquet.

git-pack-objects[1]

Créer une archive compactée d’objets.

git-prune-packed[1]

Éliminer les objets supplémentaires qui sont déjà présents dans les fichiers pack.

git-read-tree[1]

Lire l’information d’arbre dans l’index.

git-replay[1]

EXPÉRIMENTAL : Rejoue les commits sur une nouvelle base, travaille avec un dépôt nu aussi.

git-symbolic-ref[1]

Lire, modifier et supprimer les références symboliques.

git-unpack-objects[1]

Dépaqueter les objets depuis une archive empaquetée.

git-update-index[1]

Enregistrer le contenu de fichiers de l’arbre de travail dans l’index.

git-update-ref[1]

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

git-write-tree[1]

Créer un objet arbre depuis l’index courant.

Commandes d’interrogation

git-cat-file[1]

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

git-cherry[1]

Trouver les commits à appliquer en amont.

git-diff-files[1]

Comparer des fichiers dans l’arbre de travail et l’index.

git-diff-index[1]

Comparer un arbre à l’arbre de travail ou l’index.

git-diff-tree[1]

Compare le contenu et le mode des blobs trouvés via deux objets arbre.

git-for-each-ref[1]

Afficher des informations sur chaque référence.

git-for-each-repo[1]

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

git-get-tar-commit-id[1]

Extraire l’ID du commit depuis une archive créée par git-archive.

git-ls-files[1]

Afficher des informations sur les fichiers de l’index et de l’arbre de travail.

git-ls-remote[1]

Lister les références dans un dépôt distant.

git-ls-tree[1]

Afficher le contenu d’un objet arbre.

git-merge-base[1]

Trouver un ancêtre aussi bon que possible pour une fusion.

git-name-rev[1]

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

git-pack-redundant[1]

Trouver les fichiers pack redondants.

git-rev-list[1]

Afficher les objets commit dans l’ordre chronologique inverse.

git-rev-parse[1]

Analyser et préparer les paramètres.

git-show-index[1]

Afficher l’index de l’archive empaquetée.

git-show-ref[1]

Lister les références du dépôt local.

git-unpack-file[1]

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

git-var[1]

Afficher un variable logique de Git.

git-verify-pack[1]

Valider des fichiers d’archive Git empaquetés.

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

Synchronisation des dépôts

git-daemon[1]

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

git-fetch-pack[1]

Recevoir des objets manquants depuis un autre dépôt.

git-http-backend[1]

Implantation côté serveur de Git sur HTTP.

git-send-pack[1]

Pousser des objets sur le protocole Git sur un autre dépôt.

git-update-server-info[1]

Mettre à jour le fichier d’informations auxiliaires pour aider les serveurs idiots.

Les commandes suivantes sont des utilitaires utilisés par celles ci-dessus ; les utilisateurs finaux ne les utilisent généralement pas directement.

git-http-fetch[1]

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

git-http-push[1]

Pousser des objets par HTTP/DAV vers un autre dépôt.

git-receive-pack[1]

Recevoir ce qui est poussé dans un dépôt.

git-shell[1]

Shell de login restreint pour un accès SSH vers Git seulement.

git-upload-archive[1]

Renvoyer une archive dans git-archive.

git-upload-pack[1]

Renvoyer des objets empaquetés dans git-fetch-pack.

Commandes assistantes internes

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

git-check-attr[1]

Afficher les informations de gitattributes.

git-check-ignore[1]

Déboguer gitignore / les fichiers d’exclusion.

git-check-mailmap[1]

Afficher les noms canoniques et les adresses courriel des contacts.

git-check-ref-format[1]

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

git-column[1]

Afficher les données en colonnes.

git-credential[1]

Récupérer et sauvegarder les certificats d’utilisateur.

git-credential-cache[1]

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

git-credential-store[1]

Assistant pour sauvegarder les certificats sur disque.

git-fmt-merge-msg[1]

Produire un message de validation de fusion.

git-hook[1]

Lancer les crochets git.

git-interpret-trailers[1]

Ajouter ou analyser l’information structurée dans les messages de validation.

git-mailinfo[1]

Extraire la rustine et l’information de d’auteur depuis un simple message de courriel.

git-mailsplit[1]

Programme simple de découpage de mbox UNIX.

git-merge-one-file[1]

Le programme assistant standard à utiliser avec git-merge-index.

git-patch-id[1]

Calculer l’ID unique d’une rustine.

git-sh-i18n[1]

Le code d’initialisation i18n pour les scripts shell.

git-sh-setup[1]

Le code d’initialisation commun aux scripts shell Git.

git-stripspace[1]

Retirer les espaces inutiles.

Guides

Les pages de documentation suivantes sont des guides sur les concepts Git.

gitcore-tutorial[7]

Un tutoriel de base sur Git pour les développeurs.

gitcredentials[7]

Fournir des noms d’utilisateur et des mots de passe à Git.

gitcvs-migration[7]

Git pour les utilisateurs de CVS.

gitdiffcore[7]

Bricoler la sortie 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 de Git.

gitnamespaces[7]

Espaces de noms Git.

gitremote-helpers[7]

Programmes assistants pour interagir avec les dépôts distants.

gitsubmodules[7]

Montage d’un dépôt à l’intérieur d’un autre.

gittutorial[7]

Une introduction tutorielle à Git.

gittutorial-2[7]

Une introduction tutorielle à Git : deuxième partie.

gitworkflows[7]

Un aperçu des flux de travail recommandés avec Git.

Interfaces de dépôt, de commande et de fichiers

Cette documentation traite des interfaces de dépôt et de commande que les utilisateurs sont censés utiliser directement. Pour plus de détails sur les critères, consultez --user-formats dans git-help[1].

gitattributes[5]

Définir les attributs par chemin.

gitcli[7]

Interface et conventions de la ligne de commande Git.

githooks[5]

Crochets utilisés par Git.

gitignore[5]

Spécifie les fichiers intentionnellement non suivis à ignorer.

gitmailmap[5]

Fais correspondre les noms des auteurs/validateurs et/ou les adresses électroniques.

gitmodules[5]

Définition des propriétés des sous-modules.

gitrepository-layout[5]

Disposition d’un dépôt Git.

gitrevisions[7]

Spécifier les révisions et les plages pour Git.

formats de fichiers, protocoles et interfaces de niveau développeur

Cette documentation traite des formats de fichiers, des protocoles de communication et d’autres interfaces pour les développeur de git. Voir --developer-interfaces dans git-help[1].

gitformat-bundle[5]

Le format de fichier colis.

gitformat-chunk[5]

Formats de fichiers basés sur des tronçons.

gitformat-commit-graph[5]

Le format de graphe de commit de Git.

gitformat-index[5]

Le format d’index Git.

gitformat-pack[5]

Format interne de Git.

gitformat-signature[5]

Formats de signature cryptographique Git.

gitprotocol-capabilities[5]

Capacités des protocoles v0 et v1.

gitprotocol-common[5]

Choses communes à divers protocoles.

gitprotocol-http[5]

Protocoles Git basés sur HTTP.

gitprotocol-pack[5]

Comment les paquets sont transférés dans les transmissions.

gitprotocol-v2[5]

Protocole de transmission Git, Version 2.

Mécanisme de configuration

Git utilise un format texte simple pour stocker les personnalisations qui sont spécifique au dépôt et à l’utilisateur. Un tel fichier de configuration peut ressembler à ceci :

#
# Un caractère A '#' ou ';' indique un commentaire.
#

; variables de base
[core]
	; ne pas faire confiance au mode des fichiers
	filemode = false

; identité de l'utilisateur
[user]
	name = "Junio C Hamano"
	email = "gitster@pobox.com"

Diverses commandes lisent le fichier de configuration et modifient leur comportement en conséquence. Voir git-config[1] pour une liste et plus de détails sur le mécanisme de configuration.

Terminologie des identifiants

<objet>

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

<blob>

Indique un nom d’objet blob.

<arbre>

Indique un nom d’objet d’arbre.

<commit>

Indique un nom d’objet commit.

<arbre-esque>

Indique un nom d’objet arbre, commit ou étiquette. Une commande qui prend un argument <arbre-esque> veut finalement opérer sur un objet <arbre> mais déréférences automatiquement les objets <commit> et <étiquette> qui pointent sur un <arbre>.

<commit-esque>

Indique un nom d’objet commit ou étiquette. Une commande qui prend un argument <commit-esque> veut ultimement opérer sur un objet <commit>, mais déréférence automatiquement des objets <étiquette> qui pointent sur un <commit>.

<type>

Indique qu’un type d’objet est requis. Actuellement, soit`blob`, arbre, commit, ou étiquette.

<fichier>

Indique un nom de fichier - presque toujours relatif à la racine de la structure de l’arbre que`GIT_INDEX_FILE` décrit.

Identificateurs symboliques

Toute commande Git acceptant n’importe quel <objet> peut également utiliser la notation symbolique suivante :

HEAD

indique la tête de la branche actuelle.

<étiquette>

un nom valide d’étiquette (c.-à-d. une référence refs/tags/<étiquette>).

<tête>

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

Pour une liste plus complète des façons d’épeler les noms d’objets, voir la section « SPÉCIFICATION DE RÉVISIONS" dans gitrevisions[7].

Structure de fichier/répertoire

Veuillez consulter le document gitrepository-layout[5].

Lire githooks[5] pour plus de détails sur chaque crochet.

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

Terminologie

Veuillez consulter gitglossary[7].

Variables d’environnement

Diverses commandes Git sont sensibles aux variables d’environnement et modifient leur comportement. Les variables d’environnement marquées comme "Booléenne" prennent leurs valeurs de la même manière que les variables de configuration évaluées comme Booléenne, p.ex. "true", "yes", "on" et les chiffres positifs sont pris comme "yes".

Voici les variables :

Le dépôt Git

Ces variables d’environnement s’appliquent à toutes les commandes du cœur de Git. Nb : il est intéressant de noter qu’elles peuvent être utilisées/surchargées par les SCMS agissant par-dessus Git alors faites attention si vous utilisez un frontal externe.

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 quelle version index est utilisée lors de l’écriture du fichier index. Il n’affectera pas les fichiers d’index existants. Par défaut index version 2 ou 3 est utilisé. Voir git-update-index[1] pour plus d’informations.

GIT_OBJECT_DIRECTORY

Si le répertoire de stockage d’objets est spécifié via cette variable d’environnement, alors les répertoires sha1 sont créés dedans - 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, de vieux objets peuvent être archivés dans des répertoires partagés en lecture seule. Cette variable spécifie une liste avec ":" pour séparateur (";" sur Windows) des répertoires d’objets Git qui peuvent être utilisés pour rechercher des objets Git. Aucun nouvel objet ne sera écrit dans ces répertoires.

Les entrées qui commencent par " (double-guillemets) seront interprétées comme des chemins cités de type C, en éliminant les guillemets et les doubles guillemets et en respectant les échappements par barre oblique inverse. Par exemple, la valeur "chemin-avec-\"-et-:-a-l-interieur":chemin-simple a deux chemins : chemin-avec-"-et-:-a-l-interieur et chemin-simple.

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

Régler le chemin vers la racine de l’arbre de travail. Cela peut également être contrôlé par l’option de ligne de commande --work-tree et la variable de configuration de core.worktree.

GIT_NAMESPACE

Définir l’espace de nom Git ; voir gitnamespaces[7] pour plus de détails. L’option de ligne de commande --namespace définit également cette valeur.

GIT_CEILING_DIRECTORIES

Cela devrait être une liste des chemins absolus séparés par des caractères deux point. Si elle est définie, il s’agit d’une liste de répertoires que Git ne devrait pas visiter pendant la recherche d’un répertoire de dépôt (utile pour exclure les répertoires sur réseau lents). Elle n’exclura pas le répertoire de travail actuel ou un GIT_DIR indiqué sur la ligne de commande ou dans l’environnement. Normalement, Git doit lire les entrées dans cette liste et résoudre tout lien symbolique qui pourrait être présent pour les comparer avec le répertoire courant. Cependant, si même cet accès est lent, vous pouvez ajouter une entrée vide à la liste pour dire à Git que les entrées subséquentes ne sont pas des liens symboliques et ne doivent pas être résolues ; par exemple, GIT_CEILING_DIRECTORIES=/peutetre/symlink://non/symlink/mais/lent.

GIT_DISCOVERY_ACROSS_FILESYSTEM

Lorsque Git se trouve dans un répertoire qui n’a pas de répertoire ".git", Git tente de trouver un tel répertoire dans les répertoires parent pour trouver le sommet de l’arbre de travail, mais par défaut il ne dépasse pas les limites du système de fichiers actuel. Cette variable d’environnement Booléenne peut être définie à true pour dire à Git de ne pas s’arrêter aux limites des systèmes de fichiers. Comme GIT_CEILING_DIRECTORIES, cela n’affectera pas un répertoire de dépôt explicite indiqué via GIT_DIR ou sur la ligne de commande.

GIT_COMMON_DIR

Si cette variable est définie comme un chemin, les fichiers hos de l’arbre-de-travail qui sont normalement dans $GIT_DIR seront pris depuis ce chemin à la place. Les fichiers spécifiques à des arbres-de-travail tels que HEAD ou index sont extraits de $GIT_DIR. Voir gitrepository-layout[5] et git-worktree[1] pour plus de détails. Cette variable a une préséance inférieure à d’autres variables de chemin comme GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY…​

GIT_DEFAULT_HASH

Si cette variable est définie, l’algorithme d’empreinte par défaut pour les nouveaux dépôts sera défini à cette valeur. Cette valeur est ignorée lors du clonage et le réglage 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 du moteur de réferences par défaut pour les nouveaux dépôts sera défini à cette valeur. La valeur par défaut est "files". Voir --ref-format dans git-init[1].

Commits Git

GIT_AUTHOR_NAME

Le nom lisible utilisé dans l’identité de l’auteur lors de la création d’objets de commit ou d’étiquette, ou lors de l’écriture des reflogs. Surcharge les paramètres de configuration user.name et author.name.

GIT_AUTHOR_EMAIL

L’adresse courriel utilisée dans l’identité de l’auteur lors de la création d’objets commit ou étiquette, ou lors de l’écriture de reflogs. Surcharge 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 commit ou étiquette, ou lors de l’écriture de reflogs. Voir git-commit[1] pour les formats valides.

GIT_COMMITTER_NAME

Le nom lisible utilisé dans l’identité du validateur lors de la création d’objets commit ou étiquette, ou lors de l’écriture de reflogs. Surcharge les paramètres de configuration user.name et committer.name.

GIT_COMMITTER_EMAIL

L’adresse courriel utilisée dans l’identité de l’auteur lors de la création d’objets commit ou étiquette, ou lors de l’écriture de reflogs. Surcharge les paramètres de configuration user.email et committer.email.

GIT_COMMITTER_DATE

La date utilisée pour l’identité du validateur lors de la création d’objets commit ou étiquette, ou lors de l’écriture de reflogs. Voir git-commit[1] pour les formats valides.

EMAIL

L’adresse de courriel utilisée dans les identités de l’auteur et du validateur si aucune autre variable d’environnement ou configuration pertinente n’a été définie.

Diffs Git

GIT_DIFF_OPTS

Seul le paramètre valide est "--unified=??" ou "-u??" pour définir le nombre de lignes de contexte affichées lors de la création d’une diff unifiée. Cela a préséance sur toute valeur d’option "-U" ou "--unified" passée sur la ligne de commande Git diff.

GIT_EXTERNAL_DIFF

Lorsque la variable d’environnement GIT_EXTERNAL_DIFF est définie, le programme nommé par elle est appelé pour générer des diffs, et Git n’utilise pas sa machinerie de diff intégrée. Pour un chemin qui est ajouté, enlevé ou modifié, GIT_EXTERNAL_DIFF est appelé avec 7 paramètres :

chemin vieux-fichier vieux-hex vieux-mode nouveau-fichier nouveau-hex nouveau-mode

où :

vieux-fichier et nouveau-fichier

sont des fichiers que GIT_EXTERNAL_DIFF peut utiliser pour lire le contenu de vieux et nouveau

vieux-hex et nouveau-hex

sont les empreintes SHA-1 de 40 caractère hexadécimaux,

vieux-mode et nouveau-mode

sont la représentation octale des modes de fichiers.

Les paramètres de fichier peuvent indiquer le fichier de travail de l’utilisateur (par exemple nouveau-fichier dans "git-diff-files"), /dev/null (par exemple vieux-fichier quand un nouveau fichier est ajouté), ou un fichier temporaire (par exemple vieux-fichier dans l’index). GIT_EXTERNAL_DIFF n’a pas à se soucier de supprimer le fichier temporaire --il le sera quand GIT_EXTERNAL_DIFF se terminera.

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

Pour chaque chemin GIT_EXTERNAL_DIFF appelé, deux variables d`environnement, GIT_DIFF_PATH_COUNTER et GIT_DIFF_PATH_TOTAL sont définies.

GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE

If this Boolean environment variable is set to true then the GIT_EXTERNAL_DIFF command is expected to return exit code 0 if it considers the input files to be equal or 1 if it considers them to be different, like diff(1). If it is set to false, which is the default, then the command is expected to return exit code 0 regardless of equality. Any other exit code causes Git to report a fatal error.

GIT_DIFF_PATH_COUNTER

Un compteur basé sur 1 incrémenté d’un pour chaque chemin.

GIT_DIFF_PATH_TOTAL

Le nombre total de chemins.

autre

GIT_MERGE_VERBOSITY

Un nombre contrôlant la quantité de production affichée par la stratégie de fusion récursive. Surcharge merge.verbosity. Voir git-merge[1]

GIT_PAGER

Cette variable d’environnement remplace $PAGER. Si elle est définie à une chaîne vide ou à la valeur "cat", Git ne lancera pas de pager. Voir aussi l’option core.pager dans git-config[1].

GIT_PROGRESS_DELAY

Un nombre qui contrôle le nombre de secondes à retarder avant d’afficher des indicateurs de progrès optionnels. Valeur par défaut à 2.

GIT_EDITOR

Cette variable d’environnement remplace $EDITOR et $VISUAL. Elle est utilisée par plusieurs commandes Git lorsque, en mode interactif, un éditeur doit être lancé. Voir aussi 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 l’édition de la liste de todo d’un rebasage interactif. Voir aussi 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, git fetch et git push utiliseront la commande spécifiée au lieu de ssh lorsqu’elles doivent se connecter à un système distant. Les paramètres de ligne de commande passés à la commande configurée sont déterminés par la variante de ssh. Voir l’option ssh.variant dans git-config[1] pour plus de détails.

$GIT_SSH_COMMAND a priorité sur $GIT_SSH, et est interprété par le shell, ce qui permet d’inclure des arguments supplémentaires. ‘$GIT_SSH’ d’autre part doit être juste le chemin vers un programme (qui peut être un script shell d’emballage, si des arguments supplémentaires sont nécessaires).

Habituellement, il est plus facile de configurer toutes les options souhaitées à travers votre fichier .ssh/config personnel. Veuillez consulter votre documentation pour plus de détails.

GIT_SSH_VARIANT

Si cette variable d’environnement est définie, elle remplace l’autodétection de Git pour définir si GIT_SSH/GIT_SSH_COMMAND/core.sshCommand se réfère à OpenSSH, plink ou tortoiseplink. Cette variable remplace le paramètre de configuration ssh.variant qui sert le même but.

GIT_SSL_NO_VERIFY

Régler et exporter de cette variable d’environnement avec n’importe quelle valeur indique à Git de ne pas vérifier le certificat SSL lors de la récupération ou de la poussée sur HTTPS.

GIT_ATTR_SOURCE

Définit l’arbre-esque dont gitattributes sera lu.

GIT_ASKPASS

Si cette variable d’environnement est définie, les commandes Git qui doivent acquérir des mots de passe ou des phrases de passe (p. ex. pour l’authentification HTTP ou IMAP) appellent ce programme avec un prompt approprié comme argument de ligne de commande et lisent le mot de passe de son STDOUT. Voir aussi l’option core.askPass dans git-config[1].

GIT_TERMINAL_PROMPT

Si cette variable d’environnement booléenne est définie à false, git ne posera pas de questions sur le terminal (p. ex., lors de la demande d’authentification HTTP).

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM

Prendre la configuration à partir des fichiers donnés au lieu des fichiers de configuration globaux ou au niveau système. Si GIT_CONFIG_SYSTEM est défini, le fichier de configuration du 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 pas lus. Peut être défini à /dev/null pour sauter les fichiers de configuration du niveau correspondant.

GIT_CONFIG_NOSYSTEM

Indique qu’il faut sauter la lecture des paramètres du fichier au niveau 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 pointilleux, ou vous pouvez la définir à true pour éviter temporairement d’utiliser un fichier /etc/gitconfig buggé en attendant que quelqu’un avec suffisamment de permissions puisse le réparer.

GIT_FLUSH

Si cette variable d’environnement est définie à "1", alors les commande telles que git blame (en mode différentiel), git rev-list, git log, git check-attr et git check-ignore forceront un vidage du flux de sortie après que chaque enregistrement a été écrit. Si cette variable est définie à "0", la sortie de ces commandes sera faite en utilisant des E/S complètement tamponnés. Si cette variable d’environnement n’est pas réglée, Git choisira un vidage à chaque tampon ou à chaque enregistrement selon que stdout semble être redirigé vers un fichier ou non.

GIT_TRACE

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

Si cette variable est définie à "1, "2" ou "true" (la comparaison est insensible à la casse), les messages de trace seront imprimés sur stderr.

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

Sinon, si la variable est définie à un chemin absolu (démarrant avec un caractère /), Git l’interprétera comme un chemin de fichier et tentera d’y ajouter les messages de trace.

Désinitialiser la variable, ou la définir à vide, "0" ou "false" (casse insensible) désactive les messages de trace.

GIT_TRACE_FSMONITOR

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

GIT_TRACE_PACK_ACCESS

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

GIT_TRACE_PACKET

Active les messages de trace pour tous les paquets entrant ou sortant d’un programme donné. Cela peut aider à déboguer la négociation d’objets ou d’autres questions de protocole. Le traçage est désactivé dans 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 paquets 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 pas de citation de données binaires. Vous voulez presque certainement diriger cette sortie dans un fichier (par exemple, GIT_TRACE_PACKFILE=/tmp/mon.pack) plutôt que de l’afficher sur le terminal ou de le mélanger avec d’autres sorties de trace.

Notez que ce n’est actuellement mis en œuvre que pour le côté client des clonages et des récupurations.

GIT_TRACE_PERFORMANCE

Active les messages de trace liés à la performance, par exemple le temps d’exécution total de chaque commande Git. Voir GIT_TRACE pour 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. Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_TRACE_SETUP

Active les messages de trace .git, l’arbre de travail et le répertoire de travail courant après que Git a terminé sa phase de configuration. Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_TRACE_SHALLOW

Active les messages de trace qui peuvent aider à déboguer des récupérations / clonage de dépôts superficiels. Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_TRACE_CURL

Permet un traçage complet par curl de toutes les données entrantes et sortantes, y compris les informations descriptives, du protocole de transport git. Ceci est similaire à faire du curl --trace-ascii sur la ligne de commande. Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_TRACE_CURL_NO_DATA

Lorsqu’une trace de curl est activée (voir GIT_TRACE_CURL ci-dessus), ne pas décharger les données (c’est-à-dire que seules les lignes d’info et les en-têtes sont tracés).

GIT_TRACE2

Active des messages de trace plus détaillés par la bibliothèque "trace2". La sortie de GIT_TRACE2 est un simple format texte pour consommation humaine.

Si cette variable est définie à "1, "2" ou "true" (la comparaison est insensible à la casse), les messages de trace seront imprimés sur stderr.

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

Sinon, si la variable est définie à un chemin absolu (démarrant avec un caractère /), Git l’interprétera 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 sur des fichiers (un par processus) dans ce répertoire, nommés selon le dernier composant du SID et un compteur optionnel (pour éviter les collisions de nom de fichier).

En outre, si la variable est définie à af_unix:[<type-de-socket>]<chemin-absolu>, Git va essayer d'ouvrir le chemin en tant que socket de domaine Unix. Le type de socket peut être soit `stream ou dgram.

Désinitialiser la variable, ou la définir à vide, "0" ou "false" (casse insensible) désactive les messages de trace.

Voir la documentation de Trace2 pour tous les détails.

GIT_TRACE2_EVENT

Ce réglage écrit un format JSON adapté à l’interprétation automatique. Voir GIT_TRACE2 pour les options de sortie de trace disponibles et la documentation de Trace2 pour tous les détails.

GIT_TRACE2_PERF

En plus des messages texte disponibles dans GIT_TRACE2, ce paramètre écrit un format à colonne pour comprendre les régions de nidification. Voir GIT_TRACE2 pour les options de sortie de trace disponibles et la documentation de Trace2 pour tous les détails.

GIT_TRACE_REDACT

Par défaut, lorsque le traçage est activé, Git caviarde les valeurs des cookies, l’en-tête "Authorization:", l’en-tête "Proxy-Authorization:" et les URIs de paquets. Définissez cette variable d’environnement booléenne à false pour empêcher ce caviardage.

GIT_NO_REPLACE_OBJECTS

Régler et exporter cette variable d’environnement indique à Git d’ignorer les réfs de remplacement et de ne pas remplacer les objets Git.

GIT_LITERAL_PATHSPECS

Régler cette variable d’environnement booléenne à true va forcer Git à traiter tous les spécificateurs de chemin littéralement, plutôt que comme des motifs glob. Par exemple, exécuter GIT_LITERAL_PATHSPECS=1 git log -- `\*.c cherchera des commits qui touchent le chemin *.c, pas des chemins auquels le glob *.c correspond. Vous pourriez vouloir cela si vous fournissez des chemins littéraux vers Git (p. ex., des chemins précédemment donnés par git ls-tree, --raw sortie diff, etc.).

GIT_GLOB_PATHSPECS

Régler cette variable d’environnement booléenne à true va indiquer à Git de traiter tous les spécificateurs de chemin comme des motifs glob (aka magie "glob").

GIT_NOGLOB_PATHSPECS

Régler cette variable d’environnement booléenne à vrai indique à Git de traiter tous les spécificateurs de chemin comme littéral (aka magie "littérale").

GIT_ICASE_PATHSPECS

Régler cette variable d’environnement booléenne à true va indiquer à Git de traiter tous les spécificateurs de chemins comme insensibles à la casse.

GIT_NO_LAZY_FETCH

Régler cette variable d’environnement booléenne à true va indiquer à Git de ne pas récupérer à la demande les objets manquants depuis le distant prometteur.

GIT_REFLOG_ACTION

Lorsqu’une réf est mis à jour, des entrées de reflog sont créées pour suivre la raison pour laquelle la réf a été mise à jour (ce qui est généralement le nom de la commande de haut niveau qui a mis à jour la réf), en plus des anciennes et nouvelles valeurs de la réf. Une commande scriptée de porcelaine peut utiliser la fonction set_reflog_action helper dans git-sh-setup pour définir son nom à cette variable lorsqu’elle est invoquée comme commande de niveau supérieur par l’utilisateur final, pour l’enregistrer dans le corps du reflog.

GIT_REF_PARANOIA

Si cette variable d’environnement booléenne est définie à false, ignorer les réfs cassées ou mal nommées lors de l’itération sur les listes de réfs. Habituellement, Git tentera d’inclure tous ces réfs, ce qui peut entraîner l’échec de certaines opérations. Cela est généralement préférable, car il vaut mieux abandonner les opérations potentiellement destructrices (par exemple, git-prune[1]) plutôt que d’ignorer les réfs cassées (et donc considérer l’histoire qu’elles pointent comme inutiles à sauver). La valeur par défaut est 1 (c’est-à-dire être paranoïaque sur la détection et abandon de toutes les opérations). Vous ne devriez normalement pas avoir besoin de définir ceci à 0, mais ceci peut être utile quand vous essayez de sauver des données d’un dépôt corrompu.

GIT_COMMIT_GRAPH_PARANOIA

When loading a commit object from the commit-graph, Git performs an existence check on the object in the object database. This is done to avoid issues with stale commit-graphs that contain references to already-deleted commits, but comes with a performance penalty.

The default is "false", which disables the aforementioned behavior. Setting this to "true" enables the existence check so that stale commits will never be returned from the commit-graph at the cost of performance.

GIT_ALLOW_PROTOCOL

Si elle est définie comme une liste de protocoles séparés par des deux-points, se comporter comme si protocol.allow est défini à never , et définit protocol.<nom>.allow de chacun des protocoles énumérés à always(ce qui surcharge toute configuration existante). Voir la description de protocol.allow dans git-config[1] pour plus de détails.

GIT_PROTOCOL_FROM_USER

Définir cette variable d’environnement booléenne à false pour empêcher les protocoles utilisés par fetch/push/clone qui sont configurés à l’état utilisateur. Ceci est utile pour limiter l’initialisation récursive des sous-modules à partir d’un dépôt non fiable ou pour des programmes qui fournissentdes URLS potentiellement non fiables aux commandes git. Voir git-config[1] pour plus de détails.

GIT_PROTOCOL

Pour usage interne seulement. Utilisé pour établir la liaison en protocole filaire. Contient une liste séparée par deux-point : des clés avec des valeurs facultatives <clé>[=<valeur>]. La présence de clés et de valeurs inconnues doit être ignorée.

Notez que les serveurs peuvent devoir être configurés pour permettre à cette variable de passer sur certains transports. 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 via le protocole `git://. Pour git-over-http, elle devrait fonctionner automatiquement dans la plupart des configurations, mais voir la discussion dans git-http-backend[1]. Pour git-over-ssh, le serveur ssh peut être configuré pour permettre aux clients de passer 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 retomberont sur le protocole original "v0" (mais ils peuvent manquer certaines améliorations ou caractéristiques de performance). Cette variable n’affecte actuellement que les clonages et les récupérations ; elle n’est pas encore utilisée pour les poussées (mais peut-être à l’avenir).

GIT_OPTIONAL_LOCKS

Si cette variable d’environnement booléenne est définie à false, Git effectuera toute opération demandée sans effectuer de sous-opérations facultatives qui nécessitent un verrouillage. Par exemple, cela empêchera git status de rafraîchir l’index comme effet secondaire. Ceci est utile pour les processus fonctionnant en arrière-plan qui ne veulent pas provoquer la contention de verrouillage avec d’autres opérations sur le dépôt. Par défaut à 1.

GIT_REDIRECT_STDIN
GIT_REDIRECT_STDOUT
GIT_REDIRECT_STDERR

Windows seulement : permettre de rediriger les sockets standard d’entrée/sortie/erreur sur les chemins spécifiés par les variables d’environnement. Ceci est particulièrement utile dans les applications multithread où le moyen canonique de passer les poignées standard via CreateProcess() n’est pas possible parce qu’il exigerait que les poignées soient héritées (et par conséquent *chaque processus démarré en hériterait, en bloquant éventuellement les opérations régulières de Git). Le principal cas d’utilisation prévu est d’utiliser des tuyaux nommés pour la communication (par exemple \\.\pipe\mon-git-stdin-123).

Deux valeurs spéciales sont supportées : off va tout simplement fermer la poignée standard correspondante, et si GIT_REDIRECT_STDERR est 2>&1, l’erreur standard sera redirigée vers la même poignée que la sortie standard.

GIT_PRINT_SHA1_ELLIPSIS (obsolète)

Si elle est définie à oui, afficher une ellipse suivant une valeur SHA-1 (abrégée). Cela affecte les indications des HEAD détachées (git-checkout[1]) et la sortie diff brute (git-diff[1]). L’impression d’une ellipse dans les cas mentionnés n’est plus considérée comme adéquate et la gestion est susceptible d’être retirée dans un avenir prévisible (ainsi que la variable).

GIT_ADVICE

If set to 0, then disable all advice messages. These messages are intended to provide hints to human users that may help them get out of problematic situations or take advantage of new features. Users can disable individual messages using the advice.* config keys. These messages may be disruptive to tools that execute Git processes, so this variable is available to disable the messages. (The --no-advice global option is also available, but old Git versions may fail when this option is not understood. The environment variable will be ignored by Git versions that do not understand it.)

Discussion]

Plus de détails sur ce qui suit sont disponibles dans le chapitre des concepts Git du manuel utilisateur et gitcore-tutorial[7].

Un projet Git se compose normalement 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és représentant l’historique complet du projet, un fichier "index" qui relie l’historique au contenu actuel de l’arbre de travail, et des pointeurs nommés dans cet historique comme les étiquettes et les sommets 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 « changeset » ou une « version », représente une étape dans l’historique du projet, et chaque parent représente une étape immédiatement antérieure. Les commits avec plus d’un parent représentent des fusions de lignes de développement indépendantes.

Tous les objets sont nommés par l’empreinte SHA-1 de leur contenu, normalement écrite comme une chaîne de 40 chiffres hexadécimaux. De tels noms sont uniques à chaque objet. Tout l’historique menant à un commit peut être validé en signant seulement ce commit. Un quatrième type d’objet, l’étiquette, existe à cette fin.

Lors de la première création, les objets sont stockés dans des fichiers individuels, mais peuvent plus tard être compressés ensemble dans des « fichiers paquet » pour plus d’efficacité .

Les pointeurs nommés appelés réfs marquent des points intéressants dans l’historique. Une réf peut contenir le nom SHA-1 d’un objet ou le nom d’une autre réf (cette dernière est appelée une "réf symbolique"). Les réfs avec des noms commençant refs/head/ contiennent le nom SHA-1 du commit le plus récent (ou "head") d’une branche en développement. Les noms SHA-1 des étiquettes intéressantes sont stockés sous refs/tags/. Une réf symbolique nommée HEAD contient le nom de la branche actuellement extraite.

Le fichier 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 à la tête de la branche actuelle. Les attributs (dernière date de modification, taille, etc.) sont prélevés sur le fichier correspondant de l’arbre de travail. Les modifications subséquentes à l’arbre de travail peuvent être trouvé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 chemin donné. Ces étapes sont utilisées pour contenir les différentes versions non fusionnées d’un fichier lorsqu’une fusion est en cours.

SÉCURITÉ

Some configuration options and hook files may cause Git to run arbitrary shell commands. Because configuration and hooks are not copied using git clone, it is generally safe to clone remote repositories with untrusted content, inspect them with git log, and so on.

However, it is not safe to run Git commands in a .git directory (or the working tree that surrounds it) when that .git directory itself comes from an untrusted source. The commands in its config and hooks are executed in the usual way.

By default, Git will refuse to run when the repository is owned by someone other than the user running the command. See the entry for safe.directory in git-config[1]. While this can help protect you in a multi-user environment, note that you can also acquire untrusted repositories that are owned by you (for example, if you extract a zip file or tarball from an untrusted source). In such cases, you’d need to "sanitize" the untrusted repository first.

If you have an untrusted .git directory, you should first clone it with git clone --no-local to obtain a clean copy. Git does restrict the set of options and hooks that will be run by upload-pack, which handles the server side of a clone or fetch, but beware that the surface area for attack against upload-pack is large, so this does carry some risk. The safest thing is to serve the repository as an unprivileged user (either via git-daemon[1], ssh, or using other tools to change user ids). See the discussion in the SECURITY section of git-upload-pack[1].

DOCUMENTATION SUPPLÉMENTAIRE

Voir 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 utilisateur débutant.

Le chapitre Concepts Git du manuel d’utilisateur and gitcore-tutorial[7] fournissent tout deux des introductions à l’architecture sous-jacente de Git.

Voir gitworkflows[7] pour un aperçu des modes de travail recommandés.

Voir aussi les documents de howto pour quelques exemples utiles.

Le fonctionnement interne est documenté dans la documentation d’API de Git.

Les utilisateurs qui migrent depuis CVS peuvent également vouloir lire gitcvs-migration[7].

Auteurs

Git a été initialement développé par Linus Torvalds, et est actuellement maintenu par Junio C Hamano. De nombreuses contributions proviennent de la liste de diffusion de Git <git@vger.kernel.org>. https://openhub.net/p/git/contributors/summary vous donne une liste plus complète des contributeurs.

Si vous avez un clone de git.git lui-même, la sortie de git-shortlog[1] et git-blame[1] peut vous montrer les auteurs pour des parties spécifiques du projet.

Signaler des bogues

Signaler des bogues à la liste de diffusion de Git <git@vger.kernel.org> où le développement et la maintenance sont principalement effectués. Vous n’avez pas à être abonné à la liste pour y envoyer un message. Voir l’archive de la liste à l’adresse https://lore.kernel.org/git pour les précédents rapports sur les bogues et autres débats.

Les questions de sécurité pertinentes devraient être divulguées en privé à la liste de diffusion de Sécurité Git <git-security@googlegroups.com>.

VOIR AUSSI

gittutorial[7], gittutorial-2[7], giteveryday[7], gitcvs-migration[7], gitglossary[7], gitcore-tutorial[7], gitcli[7], Manuel de l’utilisateur de Git, gitworkflows[7]

GIT

Fait partie de la suite git[1]

TRADUCTION

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .

scroll-to-top