SYNOPSIS

git status [<options>] [--] [<pathspec>…]

DESCRIPTION

インデックスファイルと現在のHEADコミットの間に違いがあるパスや、作業ツリーとインデックスファイルの間に違いがあるパスや、Gitによって追跡されない(かつ gitignore(5) によって無視されない)作業ツリー内のパスを表示します。1つ目は、 git commit を実行してコミットすることになるものです。 2番目と3番目は、 git commit を実行する前に git add を実行することでコミット可能になるものです。

OPTIONS

-s
--short

短い形式で出力を提供します。

-b
--branch

短い形式でもブランチと追跡情報を表示します。

--show-stash

現在スタッシュされているエントリの数を表示します。

--porcelain[=<version>]

スクリプトの出力を解析しやすい形式(easy-to-parse)で提供します。 これは短い出力に似ていますが、Gitのバージョン間で、ユーザー構成に関係なく安定しています。 詳細下記。

versionパラメーターは、フォーマットバージョンを指定するために使用されます。 これはオプションであり、デフォルトでオリジナルバージョンの「v1」形式になります。

--long

長い形式で出力します。 これがデフォルトです。

-v
--verbose

変更されたファイルの名前に加えて、コミットされるようにステージングされたテキストの変更も表示します(つまり、 git diff --cached の出力風です)。 -v が2回指定されている場合は、まだステージングされていない作業ツリーの変更も表示します(つまり、 git diff の出力風です)。

-u[<mode>]
--untracked-files[=<mode>]

追跡されていないファイル(untracked files)を表示します。

modeパラメーターは、追跡されていないファイルの処理を指定するために使用されます。 これはオプションです。デフォルトは all であり、指定する場合は、オプションに串刺しする必要があります(たとえば、 -u no ではなく -uno)。

可能なオプションは以下のとおりです
no

追跡されていないファイル(untracked files)を表示します。

normal

追跡されていないファイルとディレクトリを表示します。

all

追跡されていないディレクトリ内の個々のファイルも表示します。

-u オプションを使用しない場合、追跡されていないファイルとディレクトリが表示され(つまり、 normal を指定するのと同じ)、新しく作成されたファイルを追加するのを忘れないようにします。 ファイルシステムで、追跡されていないファイルを見つけるには余分な作業が必要なため、このモードは大きな作業ツリーでは時間がかかる場合があります。 サポートされている場合は、追跡されていないキャッシュと分割インデックスを有効にすることを検討してください(git update-index --untracked-cachegit update-index --split-index を参照)。そうでない場合は、 no を使用して、追跡されていないファイルを表示せずに git status からより迅速に返ることができます。

デフォルトは、 git-config(1) に記載されている status.showUntrackedFiles 構成変数を使用して変更できます。

--ignore-submodules[=<when>]

変更を探すときは、サブモジュールへの変更を無視します。 <when> は、「none」、「untracked」、「dirty」、「all」のいずれかになります。「all」がデフォルトです。 「none」を使用すると、追跡されていないファイルまたは変更されたファイルが含まれている場合、またはそのHEADがスーパープロジェクトに記録されているコミットと異なる場合にサブモジュールが変更されたと見なされ、 git-config(1) または gitmodules(5) の「ignore」オプションの設定をオーバーライドするために使用できます。 「untracked」が使用されている場合、サブモジュールには追跡されていないコンテンツのみが含まれている場合、サブモジュールはダーティとは見なされません(ただし、変更されたコンテンツはスキャンされます)。 「dirty」を使用すると、サブモジュールの作業ツリーへのすべての変更が無視され、スーパープロジェクトに格納されているコミットへの変更のみが表示されます(これは1.7.0より前の振る舞いでした)。 「all」を使用すると、サブモジュールへのすべての変更が非表示になります(また、構成オプション status.submoduleSummary が設定されている場合、サブモジュールの要約の出力が抑制されます)。

--ignored[=<mode>]

無視されたファイル(ignored files)も表示します。

modeパラメーターは、無視されたファイル(ignored files)の処理を指定するために使用されます。 これはオプションです。デフォルトは traditional です。

可能なオプションは以下のとおりです
traditional

--untracked-files=all が指定されていない限り、無視されたファイルとディレクトリを表示します。指定されている場合、無視されたディレクトリ内の個々のファイルが表示されます。

no

無視されたファイル(ignored files)を表示しません。

matching

無視パターンにマッチする、無視されたファイルとディレクトリを表示します。

matching モードが指定されている場合、無視されたパターンに明示的にマッチするパスが表示されます。 ディレクトリが無視パターンにマッチする場合、それは表示されますが、無視されたディレクトリに含まれるパスは表示されません。 ディレクトリが無視パターンにマッチしないが、すべてのコンテンツが無視される場合、ディレクトリは表示されませんが、すべてのコンテンツが表示されます。

-z

LFではなくNULでエントリを終了します。 これは、他の形式が指定されていない場合、 --porcelain=v1 出力形式の指定を含んでいます。

--column[=<options>]
--no-column

追跡されていないファイルを列(columns)に表示します。 オプションの構文については、構成変数 column.status を参照してください。 オプションのない --column--no-column は、それぞれ alwaysnever と同等です。

--ahead-behind
--no-ahead-behind

アップストリームブランチに関連するブランチの詳細な 先行(ahead)/遅延(behind) カウントを、表示するか、または、表示しない。 デフォルトはtrueです。

--renames
--no-renames

ユーザー構成に関係なく、名前変更検出の オン/オフ を切り替えます。 git-diff(1)--no-renames も参照してください。

--find-renames[=<n>]

名前変更の検出をオンにし、オプションで類似性のしきい値を設定します。 git-diff(1)--find-renames も参照してください。

<pathspec>…

gitglossary(7) の「pathspec」エントリを参照してください。

OUTPUT

このコマンドの出力は、コミットテンプレートのコメントとして使用するように設計されています。 デフォルトの長い形式は、人間が読める形式で、冗長で説明的なものになるように設計されています。 その内容と形式は予告なく変更される事があります。

他の多くのGitコマンドとは異なり、出力に記載されているパスは、サブディレクトリで作業している場合、現在のディレクトリを基準にして作成されます(これは、カット&ペーストを支援するための意図的なものです)。 下記 status.relativePaths 構成オプションを参照してください。

Short Format

短い形式では、各パスのステータスがこれらの形式の1つとして表示されます

XY PATH
XY ORIG_PATH -> PATH

ここで、 ORIG_PATH は、名前が 変更/コピー されたコンテンツの出所です。 ORIG_PATH は、エントリの名前が変更またはコピーされた場合にのみ表示されます。 XY は2文字のステータスコードです。

フィールド(-> を含む)は、単一のスペースで互いに区切られています。 ファイル名に空白またはその他の印刷不可能な文字が含まれている場合、そのフィールドはC文字列リテラルの方法でクォートされます。ASCII二重引用符(34)キャラクタ(")で囲まれ、内部の特殊文字はバックスラッシュ(\)でエスケープされます。

この形式を使用して表示される状態には3つの異なるタイプがあり、それぞれが「XY」構文を異なる方法で使用します:

  • マージが発生していてマージが成功した場合、またはマージ状況以外の場合、 X はインデックスのステータスを示し、Y は作業ツリーのステータスを示します。

  • マージの競合が発生し、まだ解決されていない場合、 XY は、共通の祖先と比較して、マージの各ヘッドによって導入された状態を示します。 これらのパスは「unmerged」と言われます。

  • パスが追跡されていない場合、 XY はインデックスで不明(unknown)であるため、常に同一です。 ?? は追跡されていないパスに使用されます。 --ignored が使用されない限り、無視されたファイルはリストされません。 --ignored が使用された場合、無視されたファイルは !! で示されます。

ここでのマージという用語には、デフォルトの `--merge`戦略を使用したリベースや、チェリーピックや、マージ機構を使用したその他のものも含まれることに注意してください。

以下の表では、これら3つのクラスが別々のセクションに示されています。これらの文字は、追跡されたパスを示す最初の2つのセクションの X フィールドと Y フィールドに使用されます。

  • " " = 変更されていない

  • M = 変更された

  • T = ファイル・タイプが変更された(通常ファイル(regular file)またはシンボリック・リンク(symbolic link)またはサブモジュール(submodule))

  • A = 追加された

  • D = 削除された

  • R = 名前変更された

  • C = コピーされた (構成オプション status.renamescopies に設定されている場合)

  • U = 更新されたがマージされていない

X          Y     Meaning
-------------------------------------------------
         [AMD]   not updated
M        [ MTD]  updated in index
T        [ MTD]  type changed in index
A        [ MTD]  added to index
D                deleted from index
R        [ MTD]  renamed in index
C        [ MTD]  copied in index
[MTARC]          index and work tree matches
[ MTARC]    M    work tree changed since index
[ MTARC]    T    type changed in work tree since index
[ MTARC]    D    deleted in work tree
            R    renamed in work tree
            C    copied in work tree
-------------------------------------------------
D           D    unmerged, both deleted
A           U    unmerged, added by us
U           D    unmerged, deleted by them
U           A    unmerged, added by them
D           U    unmerged, deleted by us
A           A    unmerged, both added
U           U    unmerged, both modified
-------------------------------------------------
?           ?    untracked
!           !    ignored
-------------------------------------------------
サブモジュールにはより多くの状態があり、代わりのレポートがあります
M

サブモジュールには、インデックスに記録されているものとは異なるHEADがあります

m

サブモジュールに変更されたコンテンツがあります

?

サブモジュールに追跡されていないファイル(untracked files)があります

これは、サブモジュール内の、変更されたコンテンツ、または、追跡されていないファイルは、コミットを準備するためにスーパープロジェクトの git add を介して追加できないためです。

m? は再帰的に適用されます。 たとえば、サブモジュール内のネストされたサブモジュールに、追跡されていないファイルが含まれている場合、これは同様に ? として報告されます。

-b が使用されている場合、短い形式のステータスの前に行が表示されます

## branchname tracking info

Porcelain Format Version 1

バージョン 1 の磁器形式(porcelain format)は短い形式に似ていますが、Gitバージョン間またはユーザー構成に基づいて後方互換性のない方法で変更されないことが保証されています。 これにより、スクリプトによる解析に最適です。 上記の短い形式の説明では、いくつかの例外を除いて、磁器形式についても説明しています:

  1. ユーザーの color.status 構成は尊重されません。 色は常にオフになります。

  2. ユーザーの status.relativePaths 構成は尊重されません。 表示されるパスは、常にリポジトリルートを基準にしています。

機械的パースで推奨される 代替 -z 形式もあります。 この形式では、ステータスフィールドは同じですが、他のいくつかの点が異なります。 まず、名前変更エントリから -> が省略され、フィールドの順序が逆になります(たとえば、from -> toto from になります)。 次に、 NUL(ASCII 0)が各ファイル名の後に続き、スペースをフィールド区切り文字として置き換え、改行で終了します(ただし、スペースはステータスフィールドを最初のファイル名から分離します)。 第三に、特殊文字を含むファイル名は特別にフォーマットされません。 クォートや、バックスラッシュのエスケープは実行されません。

サブモジュールの変更は、 m または 単一の ? ではなく、変更された M として報告されます。

Porcelain Format Version 2

バージョン2形式では、ワークツリーの状態と変更されたアイテムに関するより詳細な情報が追加されます。 バージョン2では、パースが容易なオプションのヘッダーの拡張可能なセットも定義されています。

ヘッダー行は # で始まり、特定のコマンドライン引数に応じて追加されます。 パーサーは、認識できないヘッダーを無視する必要があります。

Branch Headers

--branch を指定すると、一連のヘッダー行に現在のブランチに関する情報が出力されます。

Line                                     Notes
------------------------------------------------------------
# branch.oid <commit> | (initial)        Current commit.
# branch.head <branch> | (detached)      Current branch.
# branch.upstream <upstream_branch>      If upstream is set.
# branch.ab +<ahead> -<behind>           If upstream is set and
                                         the commit is present.
------------------------------------------------------------

Stash Information

--show-stash が指定された場合に、スタッシュエントリの数が非ゼロの場合、スタッシュ・エントリの数を示す 1 行が出力されます:

# stash <N>

Changed Tracked Entries

ヘッダーに続いて、追跡されたエントリの一連の行が印刷されます。 変更の種類に応じて、3つの異なる行形式のいずれかを使用してエントリを記述することができます。 追跡されたエントリは、未定義の順序で印刷されます。 パーサーは、3つの行タイプを任意の順序で混合できるようにする必要があります。

通常の、変更されたエントリの形式は以下のとおりです:

1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path>

名前変更またはコピーされたエントリの形式は以下のとおりです:

2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
Field       Meaning
--------------------------------------------------------
<XY>        short formatで記述されたステージされたXY値と
            ステージされていないXY値を含む2文字のフィー
            ルドで、変更されていない場合は空白
            ではなく "." で示されます。
<sub>       サブモジュールの状態説明の4文字フィールド。
            "N..." when the entry is not a submodule.
            "S<c><m><u>" when the entry is a submodule.
            <c> is "C" if the commit changed; それ以外 ".".
            <m> is "M" if it has tracked changes; それ以外 ".".
            <u> is "U" if there are untracked changes; それ以外 ".".
<mH>        The octal file mode in HEAD.
<mI>        The octal file mode in the index.
<mW>        The octal file mode in the worktree.
<hH>        The object name in HEAD.
<hI>        The object name in the index.
<X><score>  The rename or copy score (移動またはコピーのソースと
            ターゲット間の類似性のパーセンテージを示します)
            例 "R100" or "C75".
<path>      The pathname.  In a renamed/copied entry, this
            is the target path.
<sep>       When the `-z` option is used, the 2 pathnames are separated
            with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
            byte separates them.
<origPath>  HEADでのコミットまたはインデックス内のパス名。
            これは、名前が 変更された/コピーされた エントリに
            のみ存在し、名前が変更された/コピーされた
            コンテンツがどこから来たかを示します。
--------------------------------------------------------

アンマージエントリの形式は以下のとおりです。 最初の文字は、通常の変更されたエントリと区別するための「u」です。

u <XY> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
Field       Meaning
--------------------------------------------------------
<XY>        A 2 character field describing the conflict type
            as described in the short format.
<sub>       A 4 character field describing the submodule state
            as described above.
<m1>        The octal file mode in stage 1.
<m2>        The octal file mode in stage 2.
<m3>        The octal file mode in stage 3.
<mW>        The octal file mode in the worktree.
<h1>        The object name in stage 1.
<h2>        The object name in stage 2.
<h3>        The object name in stage 3.
<path>      The pathname.
--------------------------------------------------------

Other Items

追跡されたエントリに続いて(そして要求された場合)、ワークツリーで見つかった追跡されてない項目と無視される項目に対して、一連の行を出力します。

追跡されていないアイテムの形式は以下のとおりです:

? <path>

無視されるアイテムの形式は以下のとおりです:

! <path>

パス名の形式に関する注意と -z

-z オプションを指定すると、パス名はクォートされずにそのまま出力され、行はNUL(ASCII 0x00)バイトで終了します。

-z オプションを指定しない場合、構成変数 core.quotePath で説明されているように、「異常な」文字を含むパス名がクォートされます(git-config(1) を参照)。

CONFIGURATION

このコマンドは、 color.status (または status.color — 同じことを意味し、status.color は下位互換性のために保持されます)と color.status.<slot> 構成変数を尊重して出力を色付けします。

構成変数 status.relativePaths がfalseに設定されている場合、表示されるすべてのパスは、現在のディレクトリではなく、リポジトリルートを基準にしています。

status.submoduleSummary がゼロ以外の数値またはtrue(それぞれ -1 または 無制限の数値 と同じ)に設定されている場合、サブモジュールの概要が長い形式で有効になり、変更されたサブモジュールのコミットの概要が表示されます(git-submodule(1)--summary-limit 参照)。 diff.ignoreSubmodulesall に設定されている場合、または submodule.<name>.ignore=all であるサブモジュールに対してのみ、statusコマンドからの要約出力が抑制されることに注意してください。 無視されたサブモジュールの概要も表示するには、 --ignore-submodules=dirty マンドラインオプションまたは git submodule summary コマンドを使用できます。これは同様の出力を表示しますが、これらの設定を尊重しません。

BACKGROUND REFRESH

デフォルトでは、 git status は自動的にインデックスを更新し、作業ツリーからキャッシュされた統計情報を更新し、結果を書き出します。 更新されたインデックスを書き出すことは、厳密には必要ではない最適化です(status はそれ自体の値を計算しますが、それらを書き出すことは、後続のプログラムが計算を繰り返さないようにするためだけです)。 status がバックグラウンドで実行されると、書き込み中に保持されたロックが他の同時プロセスと競合し、それらが失敗する可能性があります。 バックグラウンドで status を実行しているスクリプトは、 git --no-optional-locks status の使用を検討する必要があります(詳細については、 git(1) を参照してください)。

UNTRACKED FILES AND PERFORMANCE

「git status」は、 大規模なワークツリーで非追跡ファイルやディレクトリを検索する必要がある場合、 非常に遅くなる可能性があります。 この処理を回避するか、 あるいは前に実行した Git コマンドによるキャッシュされた結果を利用することで、 この処理を高速化するために利用できる構成オプションが多数あります。 すべての人にとって最適な単一の設定の組み合わせはありません。 あなたの助けになるように、 関連するオプションの概要を以下にリストします。 ただし、 リストする前に、 「git status」を再度実行するとよいでしょう。 これは、あなたの設定がすでに「git status」の結果をキャッシュしている可能性があるため、以降の実行時により高速になる可能性があるためです。

  • --untracked-files=no フラグまたは status.showUntrackedfiles=false 設定 (双方とも前述を参照): 「git status」に非追跡ファイルを報告すべきでないと指示します。 これが最も速いオプションです。 「git status」は非追跡ファイルをリストしないため、 新しいファイルを作成して手動で git add する場合、 あなたが注意深く覚えておかなければなりません。

  • advice.statusUoption=false (git-config(1) 参照): この変数を false に設定すると、 非追跡ファイルをリストするのに 2 秒以上かかる場合に表示される警告メッセージが無効になります。 大規模なプロジェクトでは、 非追跡ファイルをリストするのにもっと時間がかかりますが、 ユーザーがすでにトレードオフ(例えば -uno の使用はユーザーにとって受け入れられないオプションである可能性がある)を受け入れているかもしれません。 その場合、警告メッセージを発行しても意味がありません。 そのような場合には、 警告を無効にすることが最善の方法であるかもしれません。

  • core.untrackedCache=true (git-update-index(1) 参照): 非追跡のキャッシュ機能を有効にし、 前の「git status」コマンド以降に変更されたディレクトリのみを検索します。 Git は各ディレクトリ内の非追跡ファイルの組を記憶しており、 ディレクトリが変更されていない場合、 その中の非追跡ファイルの組は変更されていないと想定します。 これは、 すべてのディレクトリの内容をリストするよりもはるかに高速ですが、 それでも Git は変更されたディレクトリの組を検索する必要があるため、 コストがかかります。 非追跡のキャッシュは .git/index ファイルに保存されます。 非追跡ファイルの検索コストの削減は、 インデックスのサイズの増加とインデックスを最新の状態に保つコストによってわずかに相殺されます。 通常は検索時間の短縮の為に、 このサイズ追加を行う価値があります。

  • core.untrackedCache=true かつ、 core.fsmonitor=true または core.fsmonitor=<hook_command_pathname> (git-update-index(1) 参照): 非追跡のキャッシュと FSMonitor 機能の両方を有効にし、 前の「git status」コマンド以降に変更されたディレクトリのみを検索します。 Git は変更されたディレクトリの検索も回避できるため、 非追跡のキャッシュだけを単独で使用するよりも高速です。 Git は、 最近変更されたディレクトリの組を正確にリストするだけで済みます。 非追跡のキャッシュがなくても FSMonitor 機能を有効にすることはできますが、 その場合は利点が大幅に減少します。

非追跡のキャッシュや FSMonitor 機能をオンにした後、 コマンド実行時間が改善されるまで、 さまざまなキャッシュをウォームアップするために、いくつかの「git status」コマンドが必要になる場合があることに注意してください。 これは正常な動作です。

SEE ALSO

GIT

Part of the git(1) suite