git - En ligne dans le Cloud

PROGRAMME:

Nom

git - le traqueur de contenu stupide

SYNOPSIS

jet [--version] [--aide] [-C ] [-c = ]
[--exec-path[= ]] [--chemin-html] [--chemin-man] [--chemin-info]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir= ] [--work-tree= ] [--namespace= ]
[ ]

DESCRIPTION

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

See gittorial(7) pour commencer, puis voir gitetous les jours(7) pour un ensemble minimum utile de
commandes. le Git Utilisateurs Manuelle[1] a une introduction plus approfondie.

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

La version formatée et avec hyperlien de la dernière documentation Git peut être consultée à l'adresse
http://git-htmldocs.googlecode.com/git/git.html.

OPTIONS

--version
Imprime la version de la suite Git que le jet programme est venu.

--Aidez-moi
Imprime le synopsis et une liste des commandes les plus couramment utilisées. Si l'option --tout
or -a est donné, toutes les commandes disponibles sont affichées. Si une commande Git est nommée ceci
L'option affichera la page de manuel de cette commande.

D'autres options sont disponibles pour contrôler l'affichage de la page de manuel. Voir git-
aider(1) pour plus d'informations, car git --help ... est converti en interne en git
aider ....

-C
Exécuter comme si git avait été démarré dans au lieu du répertoire de travail actuel. Lorsque
plusieurs options -C sont données, chaque -C non absolu suivant est interprété
par rapport au précédent -C .

Cette option affecte les options qui attendent un nom de chemin comme --git-dir et --work-tree dans
que leurs interprétations des noms de chemin seraient faites par rapport au travail
répertoire causé par l'option -C. Par exemple, les appels suivants sont
équivalent:

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

-c =
Passez un paramètre de configuration à la commande. La valeur donnée remplacera les valeurs
à partir des fichiers de configuration. Les est attendu dans le même format que celui indiqué par jet
config (sous-clés séparées par des points).

Notez que l'omission du = dans git -c foo.bar ... est autorisée et définit foo.bar sur le
valeur booléenne vraie (tout comme [foo]bar le ferait dans un fichier de configuration). Y compris les égaux
mais avec une valeur vide (comme git -c foo.bar= ...) définit foo.bar sur la chaîne vide.

--exec-path[= ]
Chemin d'accès à l'endroit où vos programmes Git principaux sont installés. Cela peut également être contrôlé par
en définissant la variable d'environnement GIT_EXEC_PATH. Si aucun chemin n'est indiqué, jet va imprimer
le réglage actuel, puis quittez.

--html-chemin
Imprimer le chemin, sans barre oblique de fin, où la documentation HTML de Git est installée
et sortie.

--man-chemin
Imprimez le chemin de l'homme (voir man(1)) pour les pages de manuel de cette version de Git et quittez.

--info-chemin
Imprimez le chemin d'installation des fichiers d'informations documentant cette version de Git et
Sortie.

-p, --paginer
Canalisez toutes les sorties dans moins (ou si défini, $PAGER) si la sortie standard est un terminal. Cette
remplace le téléavertisseur. options de configuration (voir le "Mécanisme de configuration"
section ci-dessous).

--pas de téléavertisseur
Ne redirigez pas la sortie Git dans un pager.

--git-dir=
Définissez le chemin d'accès au référentiel. Cela peut également être contrôlé en définissant le GIT_DIR
variable d'environnement. Il peut s'agir d'un chemin absolu ou d'un chemin relatif au travail actuel
répertoire.

--work-tree=
Définissez le chemin vers l'arbre de travail. Il peut s'agir d'un chemin absolu ou d'un chemin relatif au
répertoire de travail courant. Cela peut également être contrôlé en définissant le GIT_WORK_TREE
variable d'environnement et la variable de configuration core.worktree (voir core.worktree
in git-config(1) pour une discussion plus détaillée).

--namespace=
Définissez l'espace de noms Git. Voir espaces de noms git(7) pour plus de détails. Équivalent au réglage
la variable d'environnement GIT_NAMESPACE.

--nu
Traitez le référentiel comme un référentiel nu. Si l'environnement GIT_DIR n'est pas défini, il est
défini sur le répertoire de travail actuel.

--no-replace-objects
N'utilisez pas de références de remplacement pour remplacer des objets Git. Voir git-remplacer(1) pour plus
</br>L’Information.

--literal-pathspecs
Traitez les pathspecs littéralement (c'est-à-dire pas de globalisation, pas de magie de pathspec). Ceci équivaut à
en définissant la variable d'environnement GIT_LITERAL_PATHSPECS sur 1.

--glob-pathspecs
Ajoutez la magie "glob" à tous les pathspec. Cela équivaut à définir le GIT_GLOB_PATHSPECS
variable d'environnement à 1. La désactivation de la globalisation sur les pathspecs individuels peut être effectuée
en utilisant pathspec magic ":(literal)"

--noglob-pathspecs
Ajoutez de la magie "littérale" à tous les pathspec. Cela équivaut à régler le
Variable d'environnement GIT_NOGLOB_PATHSPECS sur 1. Activation de la globalisation sur un individu
les pathspecs peuvent être effectués en utilisant pathspec magic ":(glob)"

--icase-pathspecs
Ajoutez la magie "icase" à tous les pathspec. Cela équivaut à régler le
Variable d'environnement GIT_ICASE_PATHSPECS à 1.

GIT COMMANDES

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

HAUT NIVEAU COMMANDES (PORCELAINE)

Nous séparons les commandes de porcelaine en commandes principales et en utilisateur auxiliaire
utilitaires.

Entrée porcelaine commandes
git-ajouter(1)
Ajouter le contenu du fichier à l'index.

git-suis(1)
Appliquez une série de correctifs à partir d'une boîte aux lettres.

git-archive(1)
Créez une archive de fichiers à partir d'une arborescence nommée.

git-bissec(1)
Utilisez la recherche binaire pour trouver le commit qui a introduit un bogue.

git-branche(1)
Répertoriez, créez ou supprimez des branches.

git-bundle(1)
Déplacez les objets et les références par archive.

git-checkout(1)
Changez de branche ou restaurez les fichiers d'arborescence de travail.

git-cherry-pick(1)
Appliquez les changements introduits par certains commits existants.

git-citool(1)
Alternative graphique à git-commit.

git-propre(1)
Supprimez les fichiers non suivis de l'arborescence de travail.

git-clone(1)
Clonez un référentiel dans un nouveau répertoire.

git-commit(1)
Enregistrez les modifications dans le référentiel.

git-description(1)
Décrivez un commit en utilisant la balise la plus récente accessible à partir de celui-ci.

git-diff(1)
Afficher les changements entre les commits, les commits et l'arbre de travail, etc.

git-fetch(1)
Téléchargez des objets et des références à partir d'un autre référentiel.

git-format-correctif(1)
Préparez les correctifs pour la soumission par e-mail.

git-gc(1)
Nettoyez les fichiers inutiles et optimisez le référentiel local.

git-grep(1)
Imprimer des lignes correspondant à un motif.

git-gui(1)
Une interface graphique portable vers Git.

git-init(1)
Créez un référentiel Git vide ou réinitialisez-en un existant.

journal git(1)
Afficher les journaux de validation.

git-merge(1)
Joignez deux ou plusieurs histoires de développement ensemble.

git-mv(1)
Déplacer ou renommer un fichier, un répertoire ou un lien symbolique.

notes git(1)
Ajouter ou inspecter des notes d'objet.

git-pull(1)
Récupérer et intégrer avec un autre référentiel ou une branche locale.

git-push(1)
Mettre à jour les références distantes avec les objets associés.

git-rebase(1)
Forward-port local s'engage à la tête en amont mise à jour.

git-reset(1)
Réinitialise la HEAD actuelle à l'état spécifié.

git-revert(1)
Rétablir certains commits existants.

git-rm(1)
Supprimez les fichiers de l'arbre de travail et de l'index.

git-shortlog(1)
Résumer jet enregistrer sortie.

git-show(1)
Montrez différents types d'objets.

git-cache(1)
Rangez les modifications dans un répertoire de travail sale.

git-statut(1)
Afficher l'état de l'arbre de travail.

git-sous-module(1)
Initialiser, mettre à jour ou inspecter les sous-modules.

tag git(1)
Créez, répertoriez, supprimez ou vérifiez un objet tag signé avec GPG.

git-worktree(1)
Gérer plusieurs arbres de travail.

connard(1)
Le navigateur de référentiel Git.

Auxiliaire Commandes
Manipulateurs :

git-config(1)
Obtenez et définissez le référentiel ou les options globales.

git-fast-export(1)
Exportateur de données Git.

git-fast-importation(1)
Backend pour les importateurs de données Git rapides.

git-filter-branche(1)
Réécrire les branches.

git-mergetool(1)
Exécutez des outils de résolution des conflits de fusion pour résoudre les conflits de fusion.

git-pack-refs(1)
Emballez les têtes et les balises pour un accès efficace au référentiel.

git-prune(1)
Élaguez tous les objets inaccessibles de la base de données d'objets.

git-reflog(1)
Gérer les informations de reflog.

git-relink(1)
Lien dur des objets communs dans les référentiels locaux.

git-distant(1)
Gérer un ensemble de référentiels suivis.

git-repack(1)
Emballez les objets décompressés dans un référentiel.

git-remplacer(1)
Créer, lister, supprimer des références pour remplacer des objets.

Interrogateurs :

git-annoter(1)
Annotez les lignes de fichier avec les informations de validation.

blâme(1)
Montrez quelle révision et quel auteur ont modifié en dernier chaque ligne d'un fichier.

git-cerise(1)
Trouvez les commits à appliquer en amont.

git-count-objets(1)
Comptez le nombre d'objets décompressés et leur consommation de disque.

git-difftool(1)
Afficher les modifications à l'aide des outils de comparaison courants.

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

git-get-tar-commit-id(1)
Extrayez l'ID de validation d'une archive créée à l'aide de git-archive.

git-aide(1)
Afficher des informations d'aide sur Git.

git-instaweb(1)
Parcourez instantanément votre référentiel de travail dans gitweb.

git-merge-tree(1)
Afficher la fusion à trois voies sans toucher à l'index.

git-rerere(1)
Réutilisez la résolution enregistrée des fusions en conflit.

git-rev-analyse(1)
Sélectionnez et massez les paramètres.

git-show-branche(1)
Afficher les branches et leurs commits.

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

git-verify-tag(1)
Vérifiez la signature GPG des balises.

git-ce qui a changé(1)
Afficher les journaux avec la différence introduite par chaque commit.

gitweb(1)
Interface Web Git (interface Web vers les référentiels Git).

En interaction avec Autres
Ces commandes doivent interagir avec le SCM étranger et avec d'autres personnes via patch over
e-mail.

git-archimport(1)
Importez un référentiel Arch dans Git.

git-cvsexportcommit(1)
Exportez un seul commit vers une extraction CVS.

git-cvsimport(1)
Récupérez vos données sur un autre SCM que les gens aiment détester.

serveur git-cvs(1)
Un émulateur de serveur CVS pour Git.

git-imap-envoyer(1)
Envoyez une collection de correctifs de stdin vers un dossier IMAP.

git-p4(1)
Importez et soumettez vers les référentiels Perforce.

git-quiltimport(1)
Applique un patchset de courtepointe sur la branche actuelle.

git-request-pull(1)
Génère un résumé des modifications en attente.

git-send-email(1)
Envoyez une collection de correctifs sous forme d'e-mails.

git-svn(1)
Opération bidirectionnelle entre un dépôt Subversion et Git.

NIVEAU FAIBLE COMMANDES (PLOMBERIE)

Bien que Git comprenne sa propre couche de porcelaine, ses commandes de bas niveau sont suffisantes pour
soutenir le développement de porcelaines alternatives. Les développeurs de telles porcelaines pourraient commencer
en lisant sur git-update-indexde Géographie (1) et avec la git-read-tree (1).

L'interface (entrée, sortie, ensemble d'options et la sémantique) vers ces
les commandes sont censées être beaucoup plus stables que les commandes de niveau Porcelaine, car ces
les commandes sont principalement destinées à une utilisation scriptée. L'interface aux commandes Porcelaine d'autre part
main sont susceptibles d'être modifiés afin d'améliorer l'expérience de l'utilisateur final.

La description suivante divise les commandes de bas niveau en commandes qui manipulent
objets (dans le référentiel, l'index et l'arbre de travail), les commandes qui interrogent et
comparer des objets et des commandes qui déplacent des objets et des références entre les référentiels.

Manipulation commandes
git-appliquer(1)
Appliquer un correctif aux fichiers et/ou à l'index.

git-checkout-index(1)
Copiez les fichiers de l'index vers l'arborescence de travail.

git-commit-tree(1)
Créez un nouvel objet commit.

objet git-hash(1)
Calculer l'ID de l'objet et créer éventuellement un blob à partir d'un fichier.

git-index-pack(1)
Fichier d'index de pack de construction pour une archive compressée existante.

git-merge-fichier(1)
Exécutez une fusion de fichiers à trois voies.

git-merge-index(1)
Exécutez une fusion pour les fichiers nécessitant une fusion.

git-mktag(1)
Crée un objet tag.

git-mktree(1)
Construisez un arbre-objet à partir de texte au format ls-tree.

git-pack-objets(1)
Créez une archive compressée d'objets.

git-prune-emballé(1)
Supprimez les objets supplémentaires qui sont déjà dans les fichiers pack.

git-read-tree(1)
Lit les informations de l'arborescence dans l'index.

git-ref-symbolique(1)
Lire, modifier et supprimer les références symboliques.

git-unpack-objets(1)
Décompressez les objets d'une archive compressée.

git-update-index(1)
Enregistrez le contenu du fichier dans l'arborescence de travail dans l'index.

git-update-ref(1)
Mettez à jour le nom de l'objet stocké dans une référence en toute sécurité.

git-écrire-arbre(1)
Créez un objet arbre à partir de l'index actuel.

Interrogatoire commandes
git-cat-fichier(1)
Fournissez des informations sur le contenu ou le type et la taille des objets du référentiel.

fichiers git-diff(1)
Compare les fichiers dans l'arbre de travail et l'index.

git-diff-index(1)
Comparez un arbre à l'arbre de travail ou à l'index.

git-diff-arbre(1)
Compare le contenu et le mode des blobs trouvés via deux objets arborescents.

git-pour-chaque-ref(1)
Informations de sortie sur chaque réf.

fichiers git-ls(1)
Afficher des informations sur les fichiers dans l'index et l'arbre de travail.

git-ls-remote(1)
Répertoriez les références dans un référentiel distant.

git-ls-arbre(1)
Répertoriez le contenu d'un objet arbre.

git-merge-base(1)
Trouvez des ancêtres communs aussi bons que possible pour une fusion.

nom-git-rev(1)
Trouvez des noms symboliques pour des tours donnés.

git-pack-redondant(1)
Trouvez les fichiers de pack redondants.

git-rev-liste(1)
Répertorie les objets commit dans l'ordre chronologique inverse.

git-show-index(1)
Afficher l'index des archives compressées.

git-show-ref(1)
Répertoriez les références dans un référentiel local.

fichier git-unpack(1)
Crée un fichier temporaire avec le contenu d'un blob.

git-var(1)
Affiche une variable logique Git.

git-verify-pack(1)
Validez les fichiers d'archive Git compressés.

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

Synchronisation code source
démon git(1)
Un serveur vraiment simple pour les dépôts Git.

git-fetch-pack(1)
Recevoir les objets manquants d'un autre référentiel.

git-http-backend(1)
Implémentation côté serveur de Git sur HTTP.

git-send-pack(1)
Transférez des objets via le protocole Git vers un autre référentiel.

git-update-server-info(1)
Mettez à jour le fichier d'informations auxiliaire pour aider les serveurs stupides.

Ce qui suit sont des commandes d'aide utilisées par ce qui précède ; les utilisateurs finaux ne les utilisent généralement pas
directement.

git-http-fetch(1)
Téléchargez à partir d'un référentiel Git distant via HTTP.

git-http-push(1)
Transférez des objets via HTTP/DAV vers un autre référentiel.

git-parse-distant(1)
Routines pour aider à analyser les paramètres d'accès au référentiel distant.

git-recevoir-pack(1)
Recevez ce qui est poussé dans le référentiel.

git-shell(1)
Shell de connexion restreint pour l'accès SSH à Git uniquement.

git-upload-archive(1)
Renvoyez l'archive à git-archive.

git-upload-pack(1)
Renvoyez les objets compressés à git-fetch-pack.

Interne assistant commandes
Ce sont des commandes d'aide internes utilisées par d'autres commandes ; les utilisateurs finaux n'utilisent généralement pas
eux directement.

git-check-attr(1)
Afficher les informations sur les attributs git.

git-check-ignorer(1)
Déboguer gitignore/exclure les fichiers.

git-check-mailmap(1)
Afficher les noms canoniques et les adresses e-mail des contacts.

format git-check-ref(1)
Assure qu'un nom de référence est bien formé.

git-colonne(1)
Afficher les données en colonnes.

git-informations d'identification(1)
Récupérez et stockez les informations d'identification de l'utilisateur.

cache d'informations d'identification git(1)
Helper pour stocker temporairement les mots de passe en mémoire.

git-credential-store(1)
Helper pour stocker les informations d'identification sur le disque.

git-fmt-merge-msg(1)
Produire un message de validation de fusion.

git-interpret-remorques(1)
aider à ajouter des informations structurées dans les messages de validation.

git-mailinfo(1)
Extrait le correctif et la paternité d'un seul message électronique.

git-mailsplit(1)
Programme simple de séparateur UNIX mbox.

git-merge-un-fichier(1)
Le programme d'assistance standard à utiliser avec git-merge-index.

git-patch-id(1)
Calculer l'identifiant unique d'un correctif.

git-sh-i18n(1)
Le code de configuration i18n de Git pour les scripts shell.

git-sh-configuration(1)
Code de configuration du script shell Git commun.

git-stripspace(1)
Supprimez les espaces inutiles.

CONFIGURATION MÉCANISME

Git utilise un format de texte simple pour stocker les personnalisations par référentiel et par
utilisateur. Un tel fichier de configuration peut ressembler à ceci :

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

; variables de base
[coeur]
; Ne faites pas confiance aux modes de fichier
mode fichier = faux

; identité de l'utilisateur
[Utilisateur]
nom = "Junio ​​C Hamano"
e-mail = "[email protected]"

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

IDENTIFICATEUR TERMINOLOGIE

Indique le nom d'objet pour tout type d'objet.


Indique un nom d'objet blob.


Indique un nom d'objet arborescent.


Indique un nom d'objet de validation.


Indique un nom d'objet d'arborescence, de validation ou de balise. Une commande qui prend un
argument veut finalement opérer sur un objet mais déréférence automatiquement
et objets qui pointent vers un .


Indique un nom d'objet de validation ou de balise. Une commande qui prend un argument
veut finalement opérer sur un objet mais déréférence automatiquement
objets qui pointent vers un .


Indique qu'un type d'objet est requis. Actuellement l'un des éléments suivants : blob, tree, commit ou
Étiquette.


Indique un nom de fichier - presque toujours par rapport à la racine de l'arborescence
GIT_INDEX_FILE décrit.

SYMBOLIQUE IDENTIFIANTS

Toute commande Git acceptant peut également utiliser la notation symbolique suivante :

TÊTE
indique le responsable de la branche courante.


une balise valide prénom (c'est-à-dire un refs/tags/ référence).


une tête valide prénom (c'est-à-dire un refs/heads/ référence).

Pour une liste plus complète des façons d'épeler les noms d'objets, voir la section « SPÉCIFIER LES RÉVISIONS »
in gitrévisions (7).

FICHIER/RÉPERTOIRE STRUCTURE

S'il vous plaît voir le disposition du dépôt gitre(5) documents.

Lire crochets(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

S'il te plait regarde gitglossaire (7).

ENVIRONNEMENT VARIABLES

Diverses commandes Git utilisent les variables d'environnement suivantes :

La Git Dépôt
Ces variables d'environnement s'appliquent à TOUTE commandes Git de base. Nb : il est à noter que
ils peuvent être utilisés/outrepassés par SCMS assis au-dessus de Git, alors faites attention si vous utilisez un étranger
l'extrémité avant.

GIT_INDEX_FILE
Cet environnement permet la spécification d'un fichier d'index alternatif. Si non
spécifié, la valeur par défaut de $GIT_DIR/index est utilisée.

GIT_INDEX_VERSION
Cette variable d'environnement permet de spécifier une version d'index pour les nouveaux
référentiels. Cela n'affectera pas les fichiers d'index existants. Par défaut fichier d'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, le
Les répertoires sha1 sont créés en dessous - sinon le $GIT_DIR/objects par défaut
répertoire est utilisé.

GIT_ALTERNATE_OBJECT_DIRECTORIES
En raison de la nature immuable des objets Git, les anciens objets peuvent être archivés dans des fichiers partagés,
répertoires en lecture seule. Cette variable spécifie un ":" séparé (sous Windows ";"
séparés) liste des répertoires d'objets Git qui peuvent être utilisés pour rechercher des objets Git.
Les nouveaux objets ne seront pas écrits dans ces répertoires.

GIT_DIR
Si la GIT_DIR variable d'environnement est définie, puis il spécifie un chemin à utiliser au lieu de
le .git par défaut pour la base du référentiel. Les --git-dir option de ligne de commande
définit également cette valeur.

GIT_WORK_TREE
Définissez le chemin d'accès à la racine de l'arbre de travail. Cela peut également être contrôlé par le
--arbre de travail l'option de ligne de commande et la variable de configuration core.worktree.

GIT_NAMESPACE
Définissez l'espace de noms Git ; voir espaces de noms git(7) pour plus de détails. Les --espace de noms de ligne de commande
L'option définit également cette valeur.

GIT_PLAFOND_RÉPERTOIRES
Il doit s'agir d'une liste de chemins absolus séparés par des deux-points. S'il est défini, il s'agit d'une liste de
répertoires dans lesquels Git ne doit pas se connecter lors de la recherche d'un répertoire de référentiel
(utile pour exclure les répertoires réseau à chargement lent). Cela n'exclura pas le
répertoire de travail courant ou un GIT_DIR défini sur la ligne de commande ou dans l'environnement.
Normalement, Git doit lire les entrées de cette liste et résoudre tout lien symbolique qui pourrait
être présent afin de les comparer avec le répertoire courant. Cependant, si même cela
l'accès est lent, vous pouvez ajouter une entrée vide à la liste pour indiquer à Git que la suite
les entrées ne sont pas des liens symboliques et n'ont pas besoin d'être résolues ; par exemple,
GIT_CEILING_DIRECTORIES=/peut-être/lien symbolique ::/très/lent/non/lien symbolique.

GIT_DISCOVERY_ACROSS_FILESYSTEM
Lorsqu'il est exécuté dans un répertoire qui n'a pas de répertoire de référentiel ".git", Git essaie de
trouver un tel répertoire dans les répertoires parents pour trouver le haut de l'arbre de travail,
mais par défaut, il ne franchit pas les limites du système de fichiers. Cette variable d'environnement peut
être défini sur true pour dire à Git de ne pas s'arrêter aux limites du système de fichiers. Comme
GIT_PLAFOND_RÉPERTOIRES, cela n'affectera pas un répertoire de référentiel 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 non-worktree qui sont normalement dans $GIT_DIR
sera pris à partir de ce chemin à la place. Fichiers spécifiques à Worktree tels que HEAD ou index
sont extraits de $GIT_DIR. Voir disposition du dépôt gitrede Géographie (5) et avec la 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...

Git Commet
GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME,
GIT_COMMITTER_EMAIL, GIT_COMMITTER_DATE, E-MAIL
sur le lien git-commit-tree(1)

Git Diff
GIT_DIFF_OPTS
Le seul paramètre valide est "--unified=??" ou "-u ?" pour définir le nombre de lignes de contexte
affiché lorsqu'un diff unifié est créé. Ceci a préséance sur tout "-U" ou
Valeur de l'option "--unified" transmise sur la ligne de commande Git diff.

GIT_EXTERNAL_DIFF
Lorsque la variable d'environnement GIT_EXTERNAL_DIFF est défini, le programme nommé par celui-ci est
appelé, au lieu de l'invocation diff décrite ci-dessus. Pour un chemin ajouté,
supprimé ou modifié, GIT_EXTERNAL_DIFF est appelé avec 7 paramètres :

chemin ancien-fichier ancien-hex ancien-mode nouveau-fichier nouveau-hex nouveau-mode

où:

-déposer
sont des fichiers que GIT_EXTERNAL_DIFF peut utiliser pour lire le contenu de ,

-hex
sont les hachages SHA-40 à 1 chiffres hexadécimaux,

-mode
sont la représentation octale des modes de fichier.

Les paramètres du fichier peuvent pointer vers le fichier de travail de l'utilisateur (par exemple, nouveau-fichier dans
"git-diff-files"), /dev/null (par exemple old-file lorsqu'un nouveau fichier est ajouté), ou un fichier temporaire
fichier (par exemple ancien fichier dans l'index). GIT_EXTERNAL_DIFF ne devrait pas s'inquiéter de
dissocier le fichier temporaire --- il est supprimé lorsque GIT_EXTERNAL_DIFF sorties.

Pour un chemin non fusionné, GIT_EXTERNAL_DIFF est appelé avec 1 paramètre, .

Pour chaque chemin GIT_EXTERNAL_DIFF est appelé, deux variables d'environnement,
GIT_DIFF_PATH_COUNTER ainsi que GIT_DIFF_PATH_TOTAL sont fixés.

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

GIT_DIFF_PATH_TOTAL
Le nombre total de chemins.

autre
GIT_MERGE_VERBOSITY
Un nombre contrôlant 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. S'il est défini sur une chaîne vide ou sur le
valeur "cat", Git ne lancera pas de pager. Voir aussi l'option core.pager dans git-
config (1).

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

GIT_SSH, GIT_SSH_COMMAND
Si l'une de ces variables d'environnement est définie, alors jet rapporter ainsi que jet pousser utilisera
la commande spécifiée au lieu de ssh lorsqu'ils doivent se connecter à un système distant. Les
commande recevra exactement deux ou quatre arguments : le nom d'utilisateur@hôte (ou juste hôte)
à partir de l'URL et de la commande shell à exécuter sur ce système distant, éventuellement
précédé par -p (littéralement) et le port à partir de l'URL lorsqu'elle spécifie quelque chose d'autre
que le port SSH par défaut.

$GIT_SSH_COMMAND est prioritaire sur $GIT_SSH, et est interprété par le shell,
ce qui permet d'ajouter des arguments supplémentaires. $GIT_SSH d'autre part doit être
juste le chemin d'accès à un programme (qui peut être un script shell wrapper, si supplémentaire
des arguments sont nécessaires).

Il est généralement plus facile de configurer les options souhaitées via votre
fichier .ssh/config. Veuillez consulter votre documentation ssh pour plus de détails.

GIT_ASKPASS
Si cette variable d'environnement est définie, alors les commandes Git qui doivent acquérir des mots de passe
ou les mots de passe (par exemple pour l'authentification HTTP ou IMAP) appelleront ce programme avec un
invite appropriée comme argument de ligne de commande et lisez le mot de passe à partir de son STDOUT. Voir
également core.askPass option git-config (1).

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

GIT_CONFIG_NOSYSTEM
S'il faut ignorer les paramètres de lecture du fichier $(prefix)/etc/gitconfig à l'échelle du système.
Cette variable d'environnement peut être utilisée avec $HOME et $XDG_CONFIG_HOME pour créer
un environnement prévisible pour un script pointilleux, ou vous pouvez le définir temporairement pour éviter
en utilisant un fichier bogué /etc/gitconfig en attendant quelqu'un avec suffisamment
autorisations pour le réparer.

GIT_FLUSH
Si cette variable d'environnement est définie sur "1", alors des commandes telles que jet blâmer (en
mode incrémental), jet liste des reves, jet enregistrer, jet chèque-attr ainsi que jet vérifier-ignorer sera
force un vidage du flux de sortie après le vidage de chaque enregistrement. Si ce
variable est mise à "0", la sortie de ces commandes se fera en utilisant complètement
E/S en mémoire tampon. Si cette variable d'environnement n'est pas définie, Git choisira buffered ou
vidage orienté enregistrement selon que stdout semble être redirigé vers un fichier ou
pas.

GIT_TRACE
Active les messages de trace généraux, par exemple l'extension d'alias, l'exécution de commandes intégrées et
exécution d'une commande externe.

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

Si la variable est définie sur 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 essaiera 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 interprétera cela comme un chemin de fichier et essaiera d'écrire la trace
messages dedans.

Désélectionner la variable ou la définir sur vide, "0" ou "false" (insensible à la casse)
désactive les messages de suivi.

GIT_TRACE_PACK_ACCESS
Active les messages de trace pour tous les accès à tous les packs. Pour chaque accès, le fichier pack
nom et un décalage dans le pack est enregistré. Cela peut être utile pour le dépannage
certains problèmes de performances liés au pack. Voir GIT_TRACE pour la sortie de trace disponible
options.

GIT_TRACE_PACKET
Active les messages de trace pour tous les paquets entrant ou sortant d'un programme donné. Ceci peut
aide au débogage de la négociation d'objets ou d'autres problèmes de protocole. Le traçage est désactivé
à un paquet commençant par "PACK" (mais voir GIT_TRACE_PACKFILE au dessous de). Voir GIT_TRACE en
options de sortie de trace disponibles.

GIT_TRACE_PACKFILE
Permet le traçage des packfiles envoyés ou reçus par un programme donné. Contrairement à d'autres traces
sortie, cette trace est textuelle : pas d'en-têtes et pas de citations de données binaires. tu as presque
voulez certainement diriger dans un fichier (par exemple, GIT_TRACE_PACKFILE=/tmp/my.pack) plutôt
que de l'afficher sur le terminal ou de le mélanger avec une autre sortie de trace.

Notez que ceci n'est actuellement implémenté que pour le côté client des clones et
extractions.

GIT_TRACE_PERFORMANCE
Active les messages de trace liés aux performances, par exemple le temps d'exécution total de chaque Git
commander. Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_TRACE_SETUP
Permet aux messages de trace d'imprimer le .git, l'arbre de travail et le répertoire de travail actuel
une fois que Git a terminé sa phase de configuration. Voir GIT_TRACE pour la sortie de trace disponible
options.

GIT_TRACE_SHALLOW
Active les messages de trace qui peuvent aider à déboguer l'extraction/le clonage de peu profonds
référentiels. Voir GIT_TRACE pour les options de sortie de trace disponibles.

GIT_LITERAL_PATHSPECS
Si vous définissez cette variable sur 1, Git traitera littéralement tous les pathspecs, plutôt
que sous forme de motifs glob. Par exemple, en exécutant GIT_LITERAL_PATHSPECS=1 git log -- '*.c'
recherchera les commits qui touchent le chemin *.c, pas les chemins que le glob *.c
allumettes. Vous voudrez peut-être cela si vous fournissez des chemins littéraux à Git (par exemple, des chemins
précédemment donné par git ls-tree, --raw diff output, etc.).

GIT_GLOB_PATHSPECS
Si vous définissez cette variable sur 1, Git traitera tous les pathspecs comme des modèles de glob (aka
magie "globale").

GIT_NOGLOB_PATHSPECS
Si vous définissez cette variable sur 1, Git traitera toutes les spécifications de chemin comme littérales (aka
magie "littérale").

GIT_ICASE_PATHSPECS
Si vous définissez cette variable sur 1, Git traitera tous les pathspecs comme insensibles à la casse.

GIT_REFLOG_ACTION
Lorsqu'une référence est mise à jour, des entrées de journal de référence sont créées pour garder une trace de la raison pour laquelle le
ref a été mis à jour (qui est généralement le nom de la commande de haut niveau qui a mis à jour
la ref), en plus des anciennes et nouvelles valeurs de la ref. Une porcelaine scénarisée
La commande peut utiliser la fonction d'assistance set_reflog_action dans git-sh-setup pour définir son nom sur
cette variable lorsqu'elle est invoquée en tant que commande de niveau supérieur par l'utilisateur final, pour être
enregistré dans le corps du reflog.

GIT_REF_PARANOIA
Si défini sur 1, incluez les références cassées ou mal nommées lors de l'itération sur les listes de références. Dans
un référentiel normal et non corrompu, cela ne fait rien. Cependant, l'activer peut aider
git pour détecter et abandonner certaines opérations en présence de références cassées. Git définit ceci
variable automatiquement lors de l'exécution d'opérations destructrices comme git-prune(1). Tu
ne devriez pas avoir besoin de le configurer vous-même, à moins que vous ne vouliez être paranoïaque à l'idée de vous assurer qu'un
l'opération a touché chaque référence (par exemple, parce que vous clonez un référentiel pour créer un
sauvegarde).

GIT_ALLOW_PROTOCOL
Si défini, fournissez une liste de protocoles séparés par des deux-points qui sont autorisés à être utilisés avec
récupérer/pousser/cloner. Ceci est utile pour restreindre l'initialisation récursive des sous-modules de
un référentiel non fiable. Tout protocole non mentionné sera refusé (c'est-à-dire qu'il s'agit de
une liste blanche, pas une liste noire). Si la variable n'est pas définie du tout, tous les protocoles sont
activée. Les noms de protocole actuellement utilisés par git sont :

· fichier : tout chemin local basé sur un fichier (y compris les URL file:// ou les chemins locaux)

· git : le protocole git anonyme sur une connexion TCP directe (ou proxy, si
configuré)

· ssh : git sur ssh (y compris hôte : syntaxe de chemin, git+ssh://, etc.).

· rsync : git sur rsync

· http : git sur http, à la fois « http intelligent » et « http stupide ». Notez que cela fait ne sauraient
inclure https ; si vous voulez les deux, vous devez spécifier les deux en tant que http:https.

· tous les assistants externes sont nommés par leur protocole (par exemple, utilisez hg pour autoriser le
assistant git-remote-hg)

DISCUSSION

Plus de détails sur les éléments suivants sont disponibles auprès du Git concepts chapitre of le
Manuel de l'Utilisateur[2] et gitcore-tutoriel (7).

Un projet Git se compose normalement d'un répertoire de travail avec un sous-répertoire ".git" au
haut niveau. Le répertoire .git contient, entre autres, une base de données d'objets compressée
représentant l'historique complet du projet, un fichier "index" qui relie cet historique
au contenu actuel de l'arbre de travail, et des pointeurs nommés dans cet historique tels que
étiquettes et têtes de branches.

La base de données d'objets contient des objets de trois types principaux : des blobs, qui contiennent des données de fichier ;
des arborescences, qui pointent vers des blobs et d'autres arborescences pour créer des hiérarchies de répertoires ; et
commits, qui font chacun référence à un seul arbre et à un certain nombre de commits parents.

Le commit, équivalent à ce que d'autres systèmes appellent un "changeset" ou "version", représente un
étape dans l'historique du projet, et chaque parent représente une étape immédiatement précédente.
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 le hachage SHA-1 de leur contenu, normalement écrit sous la forme d'une chaîne de
40 chiffres hexadécimaux. Ces noms sont globalement uniques. L'historique complet menant à un commit
peut être garanti en ne signant que ce commit. Un quatrième type d'objet, le tag, est fourni
dans ce but.

Lorsqu'ils sont créés pour la première fois, les objets sont stockés dans des fichiers individuels, mais pour plus d'efficacité, ils peuvent plus tard
être compressés ensemble dans des "fichiers pack".

Les pointeurs nommés appelés refs marquent des points intéressants dans l'histoire. Une référence peut contenir le SHA-1
nom d'un objet ou le nom d'une autre réf. Réfs avec des noms commençant par ref/head/contain
le nom SHA-1 du commit le plus récent (ou "head") d'une branche en cours de développement. SHA-1
les noms des balises d'intérêt sont stockés sous ref/tags/. Une référence spéciale nommée 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 à partir du
chef de la branche actuelle. Les attributs (heure de la dernière modification, taille, etc.) sont extraits de
le fichier correspondant dans l'arbre de travail. Les modifications ultérieures de l'arbre de travail peuvent être
trouvé en comparant ces attributs. L'index peut être mis à jour avec de nouveaux contenus et de nouveaux
les 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
chemin d'accès. Ces étapes permettent de conserver les différentes versions non fusionnées d'un fichier lorsqu'un
la fusion est en cours.

PLUS LOIN DOCUMENTATION

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

La Git concepts chapitre of le Manuel de l'Utilisateur[2] et gitcore-tutoriel(7) les deux fournissent
introductions à l'architecture Git sous-jacente.

See gitworkflows(7) pour un aperçu des workflows recommandés.

Voir aussi howto[3] documents pour quelques exemples utiles.

Les internes sont documentés dans le Git API Documentation[4].

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

AUTEURS

Git a été lancé par Linus Torvalds et est actuellement maintenu par Junio ​​C Hamano. Nombreux
les contributions proviennent de la liste de diffusion Git[email protected][5]>.
http://www.openhub.net/p/git/contributors/summary vous donne une liste plus complète de
contributeurs.

Si vous avez un clone de git.git lui-même, la sortie de git-shortlogde Géographie (1) et avec la blâme(1) peut
vous montrer les auteurs pour des parties spécifiques du projet.

DE LA LIGNE BOGUES

Signaler des bogues à la liste de diffusion Git[email protected][5]> où le développement et
l'entretien se fait principalement. Vous n'avez pas besoin d'être inscrit à la liste pour envoyer un
message là-bas.

Utiliser git en ligne en utilisant les services onworks.net