Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.43.0 11/20/23
- 2.40.1 → 2.42.1 no changes
- 2.40.0 03/12/23
- 2.39.1 → 2.39.3 no changes
- 2.39.0 12/12/22
- 2.35.1 → 2.38.5 no changes
- 2.35.0 01/24/22
- 2.34.1 → 2.34.8 no changes
- 2.34.0 11/15/21
- 2.31.1 → 2.33.8 no changes
- 2.31.0 03/15/21
- 2.30.2 → 2.30.9 no changes
- 2.30.1 02/08/21
DESCRIPTION
Montre les chemins qui ont des différences entre le fichier d’index et le
commit HEAD actuel, les chemins qui ont des différences entre l’arbre de
travail et de fichier d’index, et les chemins dans l’arbre de travail qui ne
sont pas suivis par Git (et qui ne sont pas ignorés par
gitignore[5]). Les premiers sont ce que vous valideriez en lançant
git commit
; les seconds et les troisièmes sont ce que vous pourriez
valider en lançant git add
avant de lancer git commit
.
OPTIONS
- -s
- --short
-
Afficher la sortie en format court.
- -b
- --branch
-
Montrer la branche et l’information de suivi, y compris en format court.
- --show-stash
-
Montrer le nombre d’entrées actuellement remisées.
- --porcelain[=<version>]
-
Donner la sortie dans un format facile à analyser par script. Ceci est similaire à la sortie courte, mais restera stable à travers les versions de Git et sans tenir compte de la configuration utilisateur. Voir ci-dessous pour de plus amples détails.
Le paramètre de version est utilisé pour spécifier la version de format. Ceci est optionnel et utilise par défaut le format v1 de la version d’origine.
- --long
-
Afficher la sortie en format long. Option par défaut.
- -v
- --verbose
-
En plus des noms de fichiers qui ont été changés, montrer aussi les changements textuels qui sont indexés pour validation (c.-à-d., comme la sortie de
git diff --cached
). Si-v
est spécifié deux fois, alors montrer également les modifications dans l’arbre de travail qui n’ont pas encore été indexées (c.-à-d., comme la sortie degit diff
). - -u[<mode>]
- --untracked-files[=<mode>]
-
Montrer les fichiers non-suivis.
Le paramètre mode est utilisé pour spécifier le traitement des fichiers non-suivis. C’est optionnel : il vaut par défaut all, et si spécifié, il doit être collé à l’option (par exemple,
-uno
, mais pas-u no
).Les options possibles sont :
-
no - Ne montrer aucun fichier non-suivi.
-
normal - Montrer les fichiers non-suivis et les dossiers.
-
all - Montrer aussi les fichiers dans les dossiers dont le contenu n’est pas suivi.
Quand l’option
-u
n’est pas utilisée, les fichiers non-suivis et les dossiers sont montrés (c.-à-d. comme en spécifiantnormal
), pour vous aider à éviter d’oublier d’ajouter des fichiers nouvellement créés. Étant donné que la recherche de fichiers non-suivis dans le système de fichiers nécessite un travail supplémentaire, ce mode peut prendre un certain temps dans un grand arbre de travail. Pensez à activer le cache non suivi et l’index fractionné, le cas échéant (voyezgit update-index --untracked-cache
etgit update-index --split-index
), sinon vous pouvez utiliserno
pour quegit status
revienne plus rapidement sans afficher les fichiers non-suivis.La valeur par défaut est contenue dans la variable de configuration status.showUntrackedFiles documentée dans git-config[1].
-
- --ignore-submodules[=<quand>]
-
Ignorer les modifications apportées aux sous-modules lors de la recherche de modifications. <quand> peut être "none", "untracked", "dirty" ou "all", qui est la valeur par défaut. Utiliser "none" considérera le sous-module comme modifié lorsqu’il contient des fichiers non suivis ou modifiés ou que sa HEAD diffère de la validation enregistrée dans le super-projet et peut être utilisé pour remplacer les paramètres de l’option ignore dans git-config[1] ou gitmodules[5]. Lorsque "untracked" est utilisé, les sous-modules ne sont pas considérés comme sales lorsqu’ils contiennent uniquement du contenu non suivi (mais ils sont toujours analysés pour rechercher le contenu modifié). L’utilisation de "dirty" ignore toutes les modifications apportées à l’arborescence de travail des sous-modules ; seules les modifications des validations stockées dans le super-projet sont affichées (il s’agissait du comportement avant la version 1.7.0). L’utilisation de "all" masque toutes les modifications apportées aux sous-modules (et supprime la sortie des résumés de sous-modules lorsque l’option de configuration
status.submoduleSummary
est définie). - --ignored[=<mode>]
-
Montrer aussi les fichiers ignorés.
Le paramètre mode est utilisé pour spécifier le traitement des fichiers ignorés. Il est optionnel est vaut par défaut traditional.
Les options possibles sont :
-
traditional - Montrer les fichiers non-suivis et les dossiers dont le contenu n’est pas suivi, à moins que --untracked-files=all soit spécifié, auquel cas les fichiers individuels dans les dossiers ignorés sont affichés.
-
no - Ne montrer aucun fichier ignoré.
-
matching - Montre les fichiers et les dossiers ignorés correspondants à un motif à ignorer.
Quand le mode matching est spécifié, les chemins qui correspondent explicitement à un motif à ignorer sont affichés. Si un dossier correspond à un motif à ignorer, alors il est affiché, mais pas les chemins contenus dans celui-ci. Si un dossier ne correspond pas à un motif à ignorer, mais que tout son contenu est ignoré, alors le dossier n’est pas affiché, mais tout son contenu est affiché.
-
- -z
-
Terminer les entrées avec NUL au lieu de LF. Cela implique le format de sortie
--porcelain=v1
si aucun autre format n’est fourni. - --column[=<options>]
- --no-column
-
Afficher les fichiers non suivis en colonnes. Voir la variable de configuration column.status pour la syntaxe de l’option.
--column
et--no-column
sans options sont équivalents à always et never respectivement. - --ahead-behind
- --no-ahead-behind
-
Afficher ou ne pas afficher les comptes détaillés devant/derrière pour la branche par rapport à sa branche amont. La valeur par défaut est true.
- --renames
- --no-renames
-
Activer ou désactiver la détection de renommage sans tenir compte de la configuration utilisateur. Voir aussi git-diff[1]
--no-renames
. - --find-renames[=<n>]
-
Activer la détection de renommage, en définissant de manière optionnelle le seuil de similarité. Voir aussi git-diff[1]
--find-renames
. - <spécificateur de chemin>…
-
Voir l’entrée spécificateur de chemin dans gitglossary[7].
SORTIE
La sortie de cette commande est conçue pour être utilisée comme modèle de message de validation. La valeur par défaut, format long, est conçue pour être lisible par un humain, commentée et descriptive. Son contenu et son format sont susceptibles de changer à tout moment.
Contrairement au comportement de beaucoup d’autres commandes Git qui référencent la racine de l’arbre de travail, les chemins mentionnés dans la sortie sont relatifs au répertoire courant (ceci est à dessein, pour aider le couper-coller). Voir l’option de configuration status.relativePaths ci-dessous.
Format court
Dans le format court, le statut de chaque chemin est affiché selon une de ces formes
XY CHEMIN XY CHEMIN_ORIGINE -> CHEMIN
où CHEMIN_ORIGINE
est l’origine du contenu renommé/copié. CHEMIN_ORIGINE
n’est montré que lorsque l’entrée est renommée ou copiée. Le XY
est un
code de statut à deux lettres.
Les champs (incluant le ->
) sont séparés les uns des autres par un seul
espace. Si un nom de fichier contient des espaces ou d’autres caractères non
imprimables, ce champ sera cité à la manière d’un littéral de chaîne C :
entouré par des caractères de guillemets ASCII (34), et avec les caractères
spéciaux à l’intérieur échappés par la barre oblique inversée.
Pour les chemins avec des conflits de fusion, X
et Y
montrent les états
de modification de chaque côté de la fusion. Pour les chemins qui n’ont pas
de conflit de fusion, X
montre le statut de l’index, et Y
montre le
statut de l’arbre de travail. Pour les chemins non suivis, XY
sont
??
. Les autres codes de statut peuvent être interprétés comme :
-
' ' = non modifié
-
M = modifié
-
A = ajouté
-
D = supprimé (Deleted)
-
R = renommé
-
C = copié
-
U = mis à jour (Updated) mais non fusionné
Les fichiers ignorés ne sont pas listés, à moins que l’option --ignored
soit effective, auquel cas XY
sont !!
.
X Y Signification --------------------------------------------------------- [AMD] non mis à jour M [ MD] mis à jour dans l'index A [ MD] ajouté à l'index D supprimé de l'index R [ MD] renommé dans l'index C [ MD] copié dans l'index [MARC] l'index et l'arbre de travail correspondent [ MARC] M arbre de travail modifié depuis l'index [ MARC] D supprimé dans l'arbre de travail [ D] R renommé dans l'arbre de travail [ D] C copié dans l'arbre de travail --------------------------------------------------------- D D non fusionné, les deux l'ont supprimé A U non fusionné, ajouté par nous U D non fusionné, supprimé par eux U A non fusionné, ajouté par eux D U non fusionné, supprimé par nous A A non fusionné, les deux l'ont ajouté U U non fusionné, les deux l'ont modifié --------------------------------------------------------- ? ? non suivi ! ! ignoré ---------------------------------------------------------
Les sous-modules ont plus d’états et indiquent à la place
M le sous-module a une HEAD différente de
celle enregistrée dans l’index
m le sous-module a un contenu modifié
? le sous-module a des fichiers non suivis
puisque le contenu modifié ou les fichiers non suivis dans un sous-module ne peuvent pas être ajoutés
via git add
dans le super-projet pour préparer une validation.
m et ? sont appliqués récursivement. Par exemple, si un sous-module niché dans un sous-module contient un fichier non suivi, ceci sera aussi indiqué par ?.
Si -b est utilisé, le statut en format court est précédé par une ligne
## information de suivi de branche
Format de porcelaine version 1
Le format de porcelaine de la version 1 est similaire au format court, mais le maintien de compatibilité est garanti au fil des versions et indépendamment de la configuration utilisateur. Cela le rend idéal pour l’analyse par script. La description du format court ci-dessus décrit également le format porcelaine, avec quelques exceptions :
-
La configuration color.status de l’utilisateur n’est pas respectée ; la couleur sera toujours éteinte.
-
La configuration status.relativePaths de l’utilisateur n’est pas respectée ; les chemins affichés seront toujours relatifs à la racine du dépôt.
Il y a aussi un format alternatif -z recommandé pour l’analyse par la machine. Dans ce format, le champ de statut est le même, mais d’autres choses changent. Premièrement, le -> est omis pour les entrées renommées et l’ordre des champs est inversé (par exemple, de -> à devient à de). Deuxièmement, un NUL (ASCII 0) suit chaque nom de fichier, remplaçant l’espace comme séparateur de champ et la nouvelle ligne de fin (mais un espace sépare toujours le champ de statut du premier nom de fichier). Troisièmement, les noms de fichier contenant des caractères spéciaux ne sont pas spécialement formatés ; aucune mise entre guillemets ni échappement par barre oblique inversée n’est effectué.
N’importe quelle modification dans un sous-module est indiquée comme
modifiée par M
au lieu de m
ou un ?
seul.
Format de porcelaine version 2
Le format version 2 ajoute des informations détaillées sur l’état de l’arbre de travail et les éléments modifiés. La version 2 définit également un ensemble extensible d’en-têtes optionnels faciles à analyser.
Les lignes d’en-tête commencent par "#" et sont ajoutées en réponse à des arguments spécifiques en ligne de commande. Les analyseurs syntaxiques doivent ignorer les en-têtes qu’ils ne reconnaissent pas.
En-têtes de branche
Si --branch
est fourni, une série de lignes d’en-tête est affichée avec
des informations sur la branche actuelle.
Ligne Notes ------------------------------------------------------------ # branch.oid <commit> | (initial) Commit courant. # branch.head <branche> | (detached) Branche courante. # branch.upstream <branche_amont> Si l'amont est défini. # branch.ab +<devant> -<derrière> Si l'amont est défini et le commit est présent. ------------------------------------------------------------
Entrées suivies modifiées
Après les en-têtes, une série de lignes est affichée pour les entrées suivies. Un des trois différents formats de ligne peut être utilisé pour décrire une entrée en fonction du type de changement. Les entrées suivies sont affichées dans un ordre indéfini ; les analyseurs syntaxiques doivent autoriser un mélange des 3 types de lignes dans n’importe quel ordre.
Les entrées modifiées normales ont le format suivant :
1 <XY> <sous> <mH> <mI> <mW> <hH> <hI> <chemin>
Les entrées renommées ou copiées ont le format suivant :
2 <XY> <sous> <mH> <mI> <mW> <hH> <hI> <X><score> <chemin><sep><cheminOrig>
Champ Signification -------------------------------------------------------- <XY> Un champ à 2 caractères contenant les valeurs XY indexées et non indexées décrites dans le format court, avec non-modifié indiqué par un "." plutôt qu'un espace. <sous> Un champ à 4 caractères décrivant l'état du sous-module. "N..." quand l'entrée n'est pas un sous-module. "S<c><m><u>" quand l'entrée est un sous-module. <c> vaut "C" si le commit a changé ; autrement ".". <m> vaut "M" s'il a des modifications suivies ; autrement ".". <u> vaut "U" s'il y a des modifications non-suivies ; autrement ".". <mH> Le mode octal du fichier dans HEAD. <mI> Le mode octal du fichier dans l'index. <mW> Le mode octal du fichier dans l'arbre de travail. <hH> Le nom de l'objet dans HEAD. <hI> Le nom de l'objet dans l'index. <X><score> Le score de renommage ou de copie (indiquant le pourcentage de similarité entre la source et la cible du déplacement ou de la copie). Par exemple, "R100" ou "C75". <chemin> Le nom du chemin. Dans une entrée renommée/copiée, c'est le chemin cible. <sep> Quand l'option `-z` est utilisée, les 2 noms de chemin sont séparés par un octet NUL (ASCII 0x00) ; autrement, un octet tabulation (ASCII 0x09) les sépare. <cheminOrig> Le nom du chemin dans le commit de HEAD ou dans l'index. C'est présent que dans une entrée renommée/copiée, et indique d'où le contenu renommé/copié vient. --------------------------------------------------------
Les entrées non fusionnées ont le format suivant ; le premier caractère est un "u" pour les différencier des entrées ordinaires modifiées.
u <xy> <sous> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <chemin>
Champ Signification -------------------------------------------------------- <XY> Un champ à 2 caractères décrivant le type de conflit comme décrit dans le format court. <sous> Un champ à 4 caractères décrivant l'état du sous-module comme décrit ci-dessus. <m1> Le mode octal du fichier dans l'étape 1. <m2> Le mode octal du fichier dans l'étape 2. <m3> Le mode octal du fichier dans l'étape 3. <mW> Le mode octal du fichier dans l'arbre de travail. <h1> Le nom de l'objet dans l'étape 1. <h2> Le nom de l'objet dans l'étape 2. <h3> Le nom de l'objet dans l'étape 3. <chemin> Le nom du chemin. --------------------------------------------------------
Autres éléments
Après les entrées suivies (et si demandé), une série de lignes sera affichée pour les éléments non suivis, puis ignorés, trouvés dans l’arbre de travail.
Les entrées non-suivies ont le format suivant :
? <chemin>
Les entrées ignorées ont le format suivant :
! <chemin>
Notes de format du nom de chemin et -z
Quand l’option -z
est fournie, les noms de chemin sont affichés tels quels
et sans guillemets et les lignes sont terminées par un octet NUL (ASCII
0x00).
Sans l’option -z
, les noms de chemin avec des caractères « inhabituels »
sont cités comme expliqué pour la variable de configuration core.quotePath
(voir git-config[1]).
CONFIGURATION
La commande honore les variables de configuration color.status
(ou
status.color
— elles signifient la même chose et la dernière est
conservée pour la compatibilité ascendante) et color.status.<slot>
pour
colorer sa sortie.
Si la variable de configuration status.relativePaths
est définie à
false, alors tous les chemins affichés sont relatifs à la racine du dépôt,
et non pas au répertoire courant.
Si status.submoduleSummary
est défini sur un nombre non nul ou vrai
(identique à -1 ou à un nombre illimité), le résumé du sous-module sera
activé pour le format long et un résumé des validations pour les
sous-modules modifiés sera affiché (voir l’option --summary-limit de
git-submodule[1]). Veuillez noter que la sortie récapitulative de la
commande status sera supprimée pour tous les sous-modules lorsque
diff.ignoreSubmodules
est réglé sur all ou uniquement pour les
sous-modules où submodule.<Name>.ignore = all
. Pour afficher également le
résumé des sous-modules ignorés, vous pouvez utiliser l’option de ligne de
commande --ignore-submodules=dirty ou la commande git submodule summary,
qui affiche une sortie similaire mais ne respecte pas ces paramètres.
RAFRAÎCHISSEMENT EN TÂCHE DE FOND
Par défaut, git status
actualisera automatiquement l’index, mettant à jour
les informations statistiques mises en cache à partir de l’arbre de travail
et écrivant le résultat. Écrire l’index mis à jour est une optimisation qui
n’est pas strictement nécessaire (status
calcule les valeurs pour
lui-même, mais les écrire ne sert qu’à épargner les programmes suivants de
répéter nos calculs). Lorsque status
est exécuté en arrière-plan, le
verrou maintenu pendant l’écriture peut entrer en conflit avec d’autres
processus simultanés, entraînant leur échec. Les scripts exécutant status
en arrière-plan doivent envisager d’utiliser git --no-optional-locks
status
(voir git[1] pour plus de détails).
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 .