Git 🌙
Français ▾ Topics ▾ Latest version ▾ git-status last updated in 2.45.0

NOM

git-status - Montrer le statut de l’arbre de travail

SYNOPSIS

git status [<options>] [--] [<spéc-de-chemin>…​]

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 de git 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écifiant normal), 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 (voyez git update-index --untracked-cache et git update-index --split-index), sinon vous pouvez utiliser no pour que git status revienne plus rapidement sans afficher les fichiers non-suivis. Toutes les orthographes habituelles pour la valeur booléenne true sont prises comme normal et false comme no.

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.

Il existe trois types d’états différents qui sont présentés selon ce format, et chacun utilise la syntaxe XY de manière différente :

  • Lorsqu’une fusion est en cours et que la fusion a été réussie, ou en dehors d’une fusion X indique l’état de l’index et Y indique l’état de l’abre de travail.

  • Lorsqu’un conflit de fusion s’est produit et n’a pas encore été résolu, X et Y montrent l’état introduit par chaque tête de la fusion, par rapport à l’ancêtre commun. Ces chemins sont dits non fusionnés.

  • Lorsqu’un chemin n’est pas tracé, X et Y sont toujours les mêmes, puisqu’ils sont inconnus de l’index. ?? est utilisé pour les chemins non suivis. Les fichiers ignorés ne sont pas listés sauf si --ignored est utilisé ; si c’est le cas, les fichiers ignorés sont indiqués par !!.

Notez que le terme merge ici inclut également les rebasages utilisant la stratégie de --merge par défaut, les picorages, et tout ce qui utilise la machinerie de fusion.

Dans le tableau suivant, ces trois classes sont présentées dans des sections séparées, et ces caractères sont utilisés pour les champs X et Y des deux premières sections qui montrent les chemins suivis :

  • ' ' = non modifié

  • M = modifié

  • T = changement de type de fichier (fichier ordinaire, lien symbolique ou sous-module)

  • A = ajouté

  • D = supprimé (Deleted)

  • R = renommé

  • C = copié (si l’option de configuration status.renames est définie comme "copies")

  • U = mis à jour (Updated) mais non fusionné

X          Y     Signification
---------------------------------------------------------
	 [AMD]   non mis à jour
M        [ MTD]   mis à jour dans l'index
T        [ MTD]   changement de type dans l'index
A        [ MTD]   ajouté à l'index
D                supprimé de l'index
R        [ MTD]   renommé dans l'index
C        [ MTD]   copié dans l'index
[MTARC]           l'index et l'arbre de travail correspondent
[ MTARC]     M    arbre de travail modifié depuis l'index
[ MTARC]     T    type modifié dans l'arbre de travail depuis l'index
[ MTARC]     D    supprimé dans l'arbre de travail
	   R    renommé dans l'arbre de travail
	    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’état et plutôt indiquent

  • M = le sous-module a une HEAD différente que celle enregistrée dans l’index

  • m = le sous-module a du contenu modifié

  • ? = le sous-module a des fichiers non suivis

Ceci s’explique du fait que le contenu modifié ou les fichiers non suivis dans un sous-module ne peuvent pas être ajoutés via git add dans le superprojet pour préparer un commit.

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 :

  1. La configuration color.status de l’utilisateur n’est pas respectée ; la couleur sera toujours éteinte.

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

Information de Remisage

Si --show-stash est donné, une ligne est affichée montrant le nombre d’entrées de remisage s’il est différent de zéro :

# remisage <N>

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

FICHIERS NON SUIVIS ET PERFORMANCES

git status peut être très lent dans les grands arbres-de-travail si/quand il doit rechercher des fichiers et des répertoires non suivis. Il y a beaucoup d’options de configuration disponibles pour accélérer cela, soit en évitant le travail, soit en utilisant les résultats en cache des commandes Git précédentes. Il n’y a pas un seul ensemble optimal de paramètres qui convienne à tout le monde. Nous allons lister un résumé des options pertinentes pour vous aider, mais avant de les lister, vous devriez lancer git status à nouveau, parce que votre configuration peut déjà avoir mis en cache les résultats de git status, et donc être plus rapide lors des exécutions suivantes.

  • Le drapeau --untracked-files=no ou la status.showUntrackedFiles=no(voir ci-dessus pour les deux) : indique que git status ne doit pas signaler les fichiers non suivis. C’est l’option la plus rapide. git status ne listera pas les fichiers non suivis, vous devez donc faire attention à vous souvenir si vous créez de nouveaux fichiers et à les git add manuellement.

  • advice.statusUoption=false (voir git-config[1]) : mettre cette variable à false désactive le message d’avertissement donné lorsque l’énumération des fichiers non suivis prend plus de 2 secondes. Dans un grand projet, cela peut prendre plus de temps et l’utilisateur peut avoir déjà accepté le compromis (par exemple, l’utilisation de "-uno" peut ne pas être une option acceptable pour l’utilisateur), auquel cas, il n’y a pas de raison d’émettre un message d’avertissement, et désactiver l’avertissement peut être la meilleure solution.

  • core.untrackedCache=true (voir git-update-index[1]) : activer la fonctionnalité de cache non suivi et ne rechercher que les répertoires qui ont été modifiés depuis la précédente commande git status. Git se souvient de l’ensemble des fichiers non suivis dans chaque répertoire et suppose que si un répertoire n’a pas été modifié, alors l’ensemble des fichiers non suivis n’a pas changé. C’est beaucoup plus rapide que d’énumérer le contenu de chaque répertoire, mais ce n’est pas sans coût, car Git doit toujours rechercher l’ensemble des répertoires modifiés. Le cache non suivi est stocké dans le fichier .git/index. Le coût réduit de la recherche des fichiers non suivis est légèrement compensé par l’augmentation de la taille de l’index et le coût de sa mise à jour. Cette réduction du temps de recherche l’emporte généralement sur la taille supplémentaire.

  • core.untrackedCache=true et core.fsmonitor=true ou core.fsmonitor=<chemin-de-commande-crochet> (voir git-update-index[1]) : active à la fois les fonctionnalités de cache de non suivi et de FSMonitor et ne recherche que les répertoires qui ont été modifiés depuis la précédente commande git status. Ceci est plus rapide que d’utiliser uniquement le cache de non suivi car Git peut également éviter de rechercher les répertoires modifiés. Git doit seulement énumérer l’ensemble exact des répertoires qui ont été modifiés récemment. Bien que la fonctionnalité FSMonitor puisse être activée sans le cache de non suivi, les avantages sont considérablement réduits dans ce cas.

Notez qu’après avoir activé les fonctionnalités cache de non suivi et/ou FSMonitor, quelques commandes git status peuvent être nécessaires pour que les différents caches se remplissent avant que vous ne constatiez une amélioration des temps de commande. Ceci est normal.

VOIR AUSSI

gitignore[5]

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