設定與配置
取得與建立專案
基本快照
分支與合併
分享與更新專案
檢查與比較
修補
除錯
電子郵件
外部系統
伺服器管理
指南
管理
底層命令
- 2.45.1 → 2.47.0 無變更
-
2.45.0
04/29/24
- 2.44.1 → 2.44.2 無變更
-
2.44.0
02/23/24
- 2.43.1 → 2.43.5 無變更
-
2.43.0
11/20/23
- 2.40.1 → 2.42.3 無變更
-
2.40.0
03/12/23
- 2.39.1 → 2.39.5 無變更
-
2.39.0
12/12/22
- 2.35.1 → 2.38.5 無變更
-
2.35.0
01/24/22
- 2.34.1 → 2.34.8 無變更
-
2.34.0
11/15/21
- 2.31.1 → 2.33.8 無變更
-
2.31.0
03/15/21
- 2.30.2 → 2.30.9 無變更
-
2.30.1
02/08/21
- 2.24.1 → 2.30.0 無變更
-
2.24.0
11/04/19
- 2.22.1 → 2.23.4 無變更
-
2.22.0
06/07/19
- 2.21.1 → 2.21.4 無變更
-
2.21.0
02/24/19
- 2.19.1 → 2.20.5 無變更
-
2.19.0
09/10/18
- 2.18.1 → 2.18.5 無變更
-
2.18.0
06/21/18
- 2.17.1 → 2.17.6 無變更
-
2.17.0
04/02/18
-
2.16.6
12/06/19
- 2.15.4 無變更
-
2.14.6
12/06/19
-
2.13.7
05/22/18
- 2.12.5 無變更
-
2.11.4
09/22/17
- 2.7.6 → 2.10.5 無變更
-
2.6.7
05/05/17
-
2.5.6
05/05/17
-
2.4.12
05/05/17
- 2.3.10 無變更
-
2.2.3
09/04/15
- 2.1.4 無變更
-
2.0.5
12/17/14
描述
顯示索引檔與目前 HEAD 提交之間有差異的路徑、工作樹與索引檔之間有差異的路徑,以及工作樹中未被 Git 追蹤的路徑(且未被 gitignore[5] 忽略)。第一個是您執行 git commit
*會*提交的內容;第二個和第三個是您在執行 git commit
之前執行 *git add* *可以*提交的內容。
選項
- -s
- --short
-
以簡短格式輸出。
- -b
- --branch
-
即使是簡短格式,也顯示分支和追蹤資訊。
- --show-stash
-
顯示目前已儲藏的條目數量。
- --porcelain[=<版本>]
-
以易於腳本解析的格式輸出。這與簡短輸出類似,但在 Git 版本之間以及無論使用者配置如何都將保持穩定。請參閱以下詳細資訊。
版本參數用於指定格式版本。這是可選的,預設為原始版本 *v1* 格式。
- --long
-
以長格式輸出。這是預設值。
- -v
- --verbose
-
除了已變更的檔案名稱之外,還顯示已暫存以提交的文字變更(即,類似於
git diff --cached
的輸出)。如果指定了兩次-v
,則還會顯示工作樹中尚未暫存的變更(即,類似於git diff
的輸出)。 - -u[<模式>]
- --untracked-files[=<模式>]
-
顯示未追蹤的檔案。
模式參數用於指定如何處理未追蹤的檔案。它是可選的:它預設為 *all*,如果指定,則必須緊貼選項(例如
-uno
,而不是-u no
)。可能的選項為
-
no - 不顯示未追蹤的檔案。
-
normal - 顯示未追蹤的檔案和目錄。
-
all - 也顯示未追蹤目錄中的個別檔案。
未使用
-u
選項時,會顯示未追蹤的檔案和目錄(即,與指定normal
相同),以協助您避免忘記新增新建立的檔案。因為在檔案系統中尋找未追蹤的檔案需要額外的工作,因此這種模式在大型工作樹中可能需要一些時間。如果支援,請考慮啟用未追蹤快取和分割索引(請參閱git update-index --untracked-cache
和git update-index --split-index
),否則您可以使用no
來讓git status
更快地返回,而不會顯示未追蹤的檔案。Boolean 值true
的所有常用拼寫都視為normal
,而false
則視為no
。可以使用 git-config[1] 中記載的 status.showUntrackedFiles 組態變數來變更預設值。
-
- --ignore-submodules[=<when>]
-
在尋找變更時忽略對子模組的變更。<when> 可以是 "none"、"untracked"、"dirty" 或 "all",這是預設值。使用 "none" 時,如果子模組包含未追蹤或已修改的檔案,或其 HEAD 與超級專案中記錄的提交不同,則會將子模組視為已修改,並且可以使用它來覆寫 git-config[1] 或 gitmodules[5] 中 *ignore* 選項的任何設定。使用 "untracked" 時,如果子模組僅包含未追蹤的內容,則不會將其視為髒(但仍會掃描已修改的內容)。使用 "dirty" 時會忽略對子模組工作樹的所有變更,僅顯示儲存在超級專案中的提交的變更(這是 1.7.0 之前的行為)。使用 "all" 時會隱藏對子模組的所有變更(並且在設定 config 選項
status.submoduleSummary
時會抑制子模組摘要的輸出)。 - --ignored[=<模式>]
-
也顯示已忽略的檔案。
模式參數用於指定如何處理已忽略的檔案。它是可選的:它預設為 *traditional*。
可能的選項為
-
traditional - 顯示已忽略的檔案和目錄,除非指定了 --untracked-files=all,在這種情況下,會顯示已忽略目錄中的個別檔案。
-
no - 不顯示已忽略的檔案。
-
matching - 顯示符合忽略模式的已忽略檔案和目錄。
指定 *matching* 模式時,會顯示明確符合忽略模式的路徑。如果目錄符合忽略模式,則會顯示該目錄,但不顯示已忽略目錄中包含的路徑。如果目錄不符合忽略模式,但所有內容都被忽略,則不會顯示該目錄,但會顯示所有內容。
-
- -z
-
以 NUL 而非 LF 終止條目。如果沒有給定其他格式,則這表示
--porcelain=v1
輸出格式。 - --column[=<選項>]
- --no-column
-
以欄位顯示未追蹤的檔案。請參閱組態變數
column.status
以取得選項語法。沒有選項的--column
和--no-column
分別等同於 always 和 never。 - --ahead-behind
- --no-ahead-behind
-
顯示或不顯示分支相對於其上游分支的詳細超前/落後計數。預設為 true。
- --renames
- --no-renames
-
開啟/關閉重新命名偵測,無論使用者配置如何。另請參閱 git-diff[1]
--no-renames
。 - --find-renames[=<n>]
-
開啟重新命名偵測,選擇性設定相似度閾值。另請參閱 git-diff[1]
--find-renames
。 - <路徑規格>…
-
請參閱 gitglossary[7] 中的 *路徑規格* 條目。
輸出
此命令的輸出設計為用作提交範本註解。預設的長格式設計為易於人類閱讀、詳細且具描述性。其內容和格式隨時可能變更。
輸出中提及的路徑,與許多其他 Git 命令不同,如果您在子目錄中工作,則會相對於當前目錄(這是故意的,以方便剪下和貼上)。請參閱下面的 status.relativePaths 設定選項。
短格式
在短格式中,每個路徑的狀態會以以下形式之一顯示
XY PATH XY ORIG_PATH -> PATH
其中 ORIG_PATH
是重新命名/複製的內容的來源。只有在條目被重新命名或複製時才會顯示 ORIG_PATH
。XY
是一個雙字母狀態碼。
各個欄位(包括 ->
)之間以單個空格分隔。如果檔案名稱包含空格或其他不可列印的字元,則該欄位會以 C 字串常值的方式加上引號:以 ASCII 雙引號 (34) 字元包圍,且內部特殊字元會使用反斜線跳脫。
使用此格式顯示的三種不同類型的狀態,每一種都以不同的方式使用 XY
語法
-
當發生合併且合併成功,或在合併情況之外時,
X
會顯示索引的狀態,而Y
會顯示工作樹的狀態。 -
當發生合併衝突且尚未解決時,
X
和Y
會顯示合併的每個頭所引入的狀態,相對於共同祖先。這些路徑被稱為未合併。 -
當路徑未追蹤時,
X
和Y
始終相同,因為它們對索引是未知的。??
用於未追蹤的路徑。除非使用--ignored
,否則會忽略檔案;如果使用,則忽略的檔案會以!!
指示。
請注意,這裡的合併一詞也包括使用預設 --merge
策略的重新變基、cherry-pick 和任何其他使用合併機制的行為。
在下表中,這三個類別會分開顯示,並且這些字元會用於顯示追蹤路徑的前兩個區段的 X
和 Y
欄位
-
' ' = 未修改
-
M = 已修改
-
T = 檔案類型已變更(一般檔案、符號連結或子模組)
-
A = 已新增
-
D = 已刪除
-
R = 已重新命名
-
C = 已複製(如果 config 選項 status.renames 設定為「copies」)
-
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 = 子模組已修改內容
-
? = 子模組有未追蹤的檔案
這是因為子模組中修改的內容或未追蹤的檔案無法透過超級專案中的 git add
新增來準備提交。
m 和 ? 會以遞迴方式套用。例如,如果子模組中的巢狀子模組包含未追蹤的檔案,這也會報告為 ?。
如果使用 -b,則短格式狀態會以一行開頭
## branchname tracking info
瓷器格式版本 1
版本 1 瓷器格式類似於短格式,但保證在 Git 版本之間或根據使用者設定,不會以不相容的方式向後變更。這使其非常適合由指令碼剖析。上述短格式的描述也描述了瓷器格式,但有一些例外
-
不採用使用者的 color.status 設定;顏色永遠關閉。
-
不採用使用者的 status.relativePaths 設定;顯示的路徑永遠會相對於儲存庫根目錄。
還有另一種 -z 格式建議用於機器剖析。在該格式中,狀態欄位相同,但其他一些事項會變更。首先,重新命名條目會省略 ->,並且欄位順序會反轉(例如,from -> to 變成 to from)。其次,每個檔案名稱後面都會跟著一個 NUL (ASCII 0),取代空格作為欄位分隔符號和終止換行符號(但空格仍會將狀態欄位與第一個檔案名稱分開)。第三,包含特殊字元的檔案名稱不會以特殊方式格式化;不會執行加引號或反斜線跳脫。
任何子模組變更都會報告為已修改的 M
,而不是 m
或單個 ?
。
瓷器格式版本 2
版本 2 格式新增了有關工作樹狀態和已變更項目的更詳細資訊。版本 2 也定義了一組可擴展、易於剖析的選用標頭。
標頭行以「#」開頭,並且會根據特定的命令列引數新增。剖析器應忽略他們不認識的標頭。
分支標頭
如果指定 --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. ------------------------------------------------------------
已變更的追蹤條目
在標頭之後,會針對追蹤的條目印出一系列行。可能會使用三種不同的行格式之一來描述條目,具體取決於變更類型。追蹤的條目會以未定義的順序印出;剖析器應允許 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> A 2 character field containing the staged and unstaged XY values described in the short format, with unchanged indicated by a "." rather than a space. <sub> A 4 character field describing the submodule state. "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; otherwise ".". <m> is "M" if it has tracked changes; otherwise ".". <u> is "U" if there are untracked changes; otherwise ".". <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 (denoting the percentage of similarity between the source and target of the move or copy). For example "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> The pathname in the commit at HEAD or in the index. This is only present in a renamed/copied entry, and tells where the renamed/copied contents came from. --------------------------------------------------------
未合併的條目具有以下格式;第一個字元是「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. --------------------------------------------------------
路徑名稱格式注意事項和 -z
如果指定 -z
選項,則會直接印出路徑名稱,而不會加上任何引號,並且行會以 NUL (ASCII 0x00) 位元組終止。
如果不使用 -z
選項,則會如配置變數 core.quotePath
所述,引述帶有「不尋常」字元的路徑名稱(請參閱git-config[1])。
組態
此命令會採用 color.status
(或 status.color
,它們的意思相同,後者保留為向後相容性)和 color.status.<slot>
配置變數來為其輸出著色。
如果將配置變數 status.relativePaths
設定為 false,則顯示的所有路徑都會相對於儲存庫根目錄,而不是目前目錄。
如果將 status.submoduleSummary
設定為非零數字或 true(與 -1 或無限數字相同),則長格式會啟用子模組摘要,並且會顯示已修改子模組的提交摘要(請參閱git-submodule[1]的 --summary-limit 選項)。請注意,當 diff.ignoreSubmodules
設定為 *all* 時,會為所有子模組抑制來自 status 命令的摘要輸出,或僅為 submodule.<name>.ignore=all
的那些子模組抑制。若要檢視忽略的子模組的摘要,您可以使用 --ignore-submodules=dirty 命令列選項或 *git submodule summary* 命令,該命令會顯示類似的輸出,但不採用這些設定。
背景重新整理
依預設,git status
會自動重新整理索引,從工作樹更新快取的 stat 資訊並寫出結果。寫出更新的索引是一種最佳化,並非絕對必要(status
會自行計算這些值,但寫出它們只是為了避免後續程式重複我們的計算)。當 status
在背景中執行時,寫入期間持有的鎖定可能會與其他同時執行的處理程序衝突,導致它們失敗。在背景中執行 status
的指令碼應考慮使用 git --no-optional-locks status
(請參閱git[1]以取得詳細資訊)。
未追蹤的檔案和效能
如果 git status
需要搜尋未追蹤的檔案和目錄,則在大型工作樹中可能會非常慢。有許多組態選項可用,可藉由避免工作或使用先前 Git 命令的快取結果來加速。沒有適合每個人的單一最佳設定集。我們將列出相關選項的摘要來協助您,但在進入清單之前,您可能需要再次執行 git status
,因為您的設定可能已經快取了 git status
結果,因此後續執行可能會更快。
-
--untracked-files=no
旗標或status.showUntrackedFiles=no
設定(以上兩者請參閱):表示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
命令,讓各種快取預熱,才能看到命令執行時間的改善。 這是正常現象。
GIT
屬於 git[1] 套件的一部分