此屬性將路徑標記為文字檔案，從而啟用行結束符轉換：當匹配檔案新增到索引時，檔案的行結束符在索引中標準化為 LF。相反，當檔案從索引複製到工作目錄時，其行結束符可能會從 LF 轉換為 CRLF，具體取決於 eol 屬性、Git 配置和平臺（參見下面 eol 的解釋）。

任何其他值都會使 Git 表現得如同 text 未指定一樣。

此屬性標記路徑，使其在檢出時在工作樹中使用特定的行結束符樣式。它僅在設定了 text 或 text=auto 時才生效（參見上文），但如果 text 未指定，指定 eol 會自動設定 text。

為了向後相容，crlf 屬性解釋如下

雖然 Git 通常不觸及檔案內容，但可以將其配置為在倉庫中將行結束符標準化為 LF，並（可選地）在檢出檔案時將其轉換為 CRLF。

如果您只是希望工作目錄中具有 CRLF 行結束符，無論您使用的是哪個倉庫，您都可以設定配置變數 "core.autocrlf" 而不使用任何屬性。

這不會強制文字檔案進行標準化，但會確保您引入倉庫的文字檔案在新增時將其行結束符標準化為 LF，並且倉庫中已標準化的檔案保持標準化。

如果您想確保任何貢獻者引入倉庫的文字檔案都將其行結束符標準化，您可以為 所有 檔案將 text 屬性設定為 "auto"。

這些屬性允許對行結束符的轉換進行精細控制。以下是一個示例，它將使 Git 標準化 .txt、.vcproj 和 .sh 檔案，確保 .vcproj 檔案在工作目錄中使用 CRLF，.sh 檔案使用 LF，並防止 .jpg 檔案無論其內容如何都被標準化。

從乾淨的工作目錄開始

如果任何不應標準化的檔案出現在 git status 中，請在執行 git add -u 之前取消設定它們的 text 屬性。

反之，Git 未檢測到的文字檔案可以手動啟用標準化。

如果 core.safecrlf 設定為 "true" 或 "warn"，Git 會驗證轉換對於 core.autocrlf 的當前設定是否可逆。對於 "true"，Git 拒絕不可逆的轉換；對於 "warn"，Git 只打印警告但接受不可逆的轉換。安全機制觸發以防止對工作樹中的檔案進行此類轉換，但也有一些例外。儘管…​

Git 識別以 ASCII 或其超集（例如 UTF-8、ISO-8859-1 等）編碼的檔案作為文字檔案。以某些其他編碼（例如 UTF-16）編碼的檔案被解釋為二進位制，因此內建的 Git 文字處理工具（例如 git diff）以及大多數 Git Web 前端預設不顯示這些檔案的內容。

在這些情況下，您可以使用 working-tree-encoding 屬性告訴 Git 工作目錄中檔案的編碼。如果一個帶有此屬性的檔案被新增到 Git，那麼 Git 會將內容從指定的編碼重新編碼為 UTF-8。最後，Git 將 UTF-8 編碼的內容儲存在其內部資料結構中（稱為“索引”）。在檢出時，內容會被重新編碼回指定的編碼。

請注意，使用 working-tree-encoding 屬性可能會帶來許多陷阱

僅當您無法將檔案儲存為 UTF-8 編碼並且希望 Git 能夠將內容作為文字處理時，才使用 working-tree-encoding 屬性。

例如，如果您的 *.ps1 檔案是帶有位元組順序標記（BOM）的 UTF-16 編碼，並且您希望 Git 根據您的平臺執行自動行結束符轉換，請使用以下屬性。

如果您的 *.ps1 檔案是無 BOM 的 UTF-16 小端編碼，並且您希望 Git 在工作目錄中使用 Windows 行結束符，請使用以下屬性（如果您想要帶 BOM 的 UTF-16 小端，請使用 UTF-16LE-BOM 而不是 UTF-16LE）。請注意，強烈建議在使用 working-tree-encoding 屬性時顯式定義行結束符與 eol，以避免歧義。

您可以使用以下命令獲取平臺上所有可用編碼的列表

如果您不知道檔案的編碼，則可以使用 file 命令猜測編碼

當路徑設定了 ident 屬性時，Git 會在檢出時將 blob 物件中的 $Id$ 替換為 $Id:，後跟 40 個字元的十六進位制 blob 物件名稱，再後跟一個美元符號 $。工作樹檔案中以 $Id: 開頭並以 $ 結尾的任何位元組序列在檢入時都會被替換為 $Id$。

可以將 filter 屬性設定為一個字串值，該值命名了配置中指定的過濾器驅動程式。

一個過濾器驅動程式由一個 clean 命令和一個 smudge 命令組成，其中任何一個都可以不指定。在檢出時，如果指定了 smudge 命令，則將 blob 物件作為其標準輸入，並使用其標準輸出來更新工作樹檔案。類似地，clean 命令用於在檢入時轉換工作樹檔案的內容。預設情況下，這些命令只處理單個 blob 並終止。如果使用長時間執行的 process 過濾器代替 clean 和/或 smudge 過濾器，那麼 Git 可以透過一次過濾器命令呼叫處理所有 blob，該呼叫持續單個 Git 命令的整個生命週期，例如 git add --all。如果配置了長時間執行的 process 過濾器，則它始終優先於配置的單個 blob 過濾器。有關與 process 過濾器通訊所用協議的描述，請參閱以下部分。

內容過濾的一種用途是，將內容整理成對平臺、檔案系統和使用者來說更方便使用的形式。對於這種操作模式，關鍵短語是“更方便”，而不是“將不可用的東西變成可用”。換句話說，其目的是，如果有人取消設定過濾器驅動程式定義，或者沒有合適的過濾器程式，專案仍然應該可用。

內容過濾的另一個用途是儲存無法直接在倉庫中使用的內容（例如，引用儲存在 Git 外部的真實內容的 UUID，或加密內容），並在檢出時將其轉換為可用形式（例如，下載外部內容，或解密加密內容）。

這兩種過濾器行為不同，預設情況下，過濾器被視為前者，將內容整理成更方便的形式。配置中缺少過濾器驅動程式定義，或者過濾器驅動程式以非零狀態退出，這不是錯誤，而是使過濾器成為無操作的直通。

您可以宣告過濾器透過將 filter.<driver>.required 配置變數設定為 true 來將內容轉換為自身不可用的可用內容。

注意：每當 clean 過濾器更改時，倉庫都應重新規範化：$ git add --renormalize .

例如，在 .gitattributes 中，您將為路徑分配 filter 屬性。

然後，您將在 .git/config 中定義 "filter.indent.clean" 和 "filter.indent.smudge" 配置，以指定一對命令來修改 C 程式的內容，當原始碼檔案被檢入時（執行 "clean"）和檢出時（不進行更改，因為命令是 "cat"）。

為了獲得最佳結果，clean 在執行兩次時應不再更改其輸出（“clean→clean”應等同於“clean”），並且多個 smudge 命令不應更改 clean 的輸出（“smudge→smudge→clean”應等同於“clean”）。請參閱下面的合併部分。

“indent”過濾器在這方面表現良好：它不會修改已正確縮排的輸入。在這種情況下，缺少 smudge 過濾器意味著 clean 過濾器 必須 接受自己的輸出而不進行修改。

如果過濾器 必須 成功才能使儲存的內容可用，您可以在配置中宣告該過濾器是 required 的

過濾器命令列上的序列“%f”被替換為過濾器正在處理的檔名。過濾器可以在關鍵字替換中使用此功能。例如

請注意，“%f”是正在處理的路徑的名稱。根據正在過濾的版本，磁碟上的相應檔案可能不存在，或者可能包含不同的內容。因此，smudge 和 clean 命令不應嘗試訪問磁碟上的檔案，而應僅作為標準輸入提供給它們的內容的過濾器。

如果透過 filter.<driver>.process 定義了過濾器命令（字串值），那麼 Git 可以在單個 Git 命令的整個生命週期內，透過一次過濾器呼叫處理所有 blob。這是透過使用長時間執行程序協議（在 Documentation/technical/long-running-process-protocol.adoc 中描述）實現的。

當 Git 遇到第一個需要清理或塗抹的檔案時，它會啟動過濾器並執行握手。在握手中，Git 傳送的歡迎訊息是“git-filter-client”，只支援版本 2，支援的功能是“clean”、“smudge”和“delay”。

之後，Git 會發送一個以 flush 包終止的“key=value”對列表。該列表將至少包含過濾器命令（基於支援的功能）以及相對於倉庫根目錄的檔案路徑。緊接著 flush 包，Git 會發送零個或多個 pkt-line 包以及一個 flush 包來終止內容。請注意，在收到內容和最終的 flush 包之前，過濾器不得傳送任何響應。另請注意，“key=value”對的“value”可以包含“=”字元，而 key 永遠不會包含該字元。

過濾器應以“key=value”對列表響應，並以 flush 包終止。如果過濾器沒有遇到問題，則該列表必須包含“success”狀態。緊接著這些包之後，過濾器應以零個或多個 pkt-line 包傳送內容，並在末尾傳送一個 flush 包。最後，應期望收到以 flush 包終止的第二個“key=value”對列表。過濾器可以在第二個列表中更改狀態，或透過空列表保持狀態不變。請注意，無論如何，空列表也必須以 flush 包終止。

如果結果內容為空，則過濾器應以“success”狀態和 flush 包響應，以表示內容為空。

如果過濾器無法或不想處理內容，則應以“error”狀態響應。

如果在處理過程中過濾器遇到錯誤，則可以在內容（部分或完全）傳送後傳送“error”狀態。

如果過濾器不能或不想處理內容，以及在 Git 程序的生命週期內任何未來的內容，那麼它應該在協議的任何時候響應“abort”狀態。

Git 不會因為設定了“error”/“abort”狀態而停止或重新啟動過濾器程序。但是，Git 會根據 filter.<driver>.required 標誌設定其退出程式碼，模仿 filter.<driver>.clean / filter.<driver>.smudge 機制的行為。

如果在通訊過程中過濾器死亡或不遵守協議，那麼 Git 將停止過濾器程序，並在下一個需要處理的檔案時重新啟動它。根據 filter.<driver>.required 標誌，Git 會將其解釋為錯誤。

如果過濾器支援“delay”功能，那麼 Git 可以在過濾器命令和路徑名之後傳送“can-delay”標誌。此標誌表示過濾器可以延遲過濾當前 blob（例如，為了補償網路延遲），透過不響應內容但響應“delayed”狀態和一個 flush 包來完成。

如果過濾器支援“delay”功能，那麼它必須支援“list_available_blobs”命令。如果 Git 傳送此命令，則過濾器應返回一個路徑名列表，表示之前已延遲且現在可用的 blob。該列表必須以一個 flush 包終止，後跟一個“success”狀態，該狀態也以一個 flush 包終止。如果延遲路徑的 blob 尚未可用，則過濾器應阻塞響應，直到至少有一個 blob 可用。過濾器可以透過傳送一個空列表來告訴 Git 它沒有更多的延遲 blob。一旦過濾器響應空列表，Git 就會停止詢問。此時 Git 尚未收到的所有 blob 都將被視為丟失並導致錯誤。

Git 收到路徑名後，將再次請求相應的 blob。這些請求包含一個路徑名和一個空的內容部分。過濾器應按照上述方式以通常的方式響應塗抹後的內容。

一個長時間執行的過濾器演示實現可以在 Git 核心倉庫中的 contrib/long-running-filter/example.pl 中找到。如果您開發自己的長時間執行過濾器程序，那麼 GIT_TRACE_PACKET 環境變數對除錯會非常有幫助（參見 git[1]）。

請注意，您不能將現有的 filter.<driver>.clean 或 filter.<driver>.smudge 命令與 filter.<driver>.process 一起使用，因為前兩者使用與後者不同的程序間通訊協議。

在檢入程式碼路徑中，工作樹檔案首先透過 filter 驅動程式（如果指定且定義了相應的驅動程式）進行轉換，然後結果透過 ident（如果指定）進行處理，最後透過 text（再次，如果指定且適用）進行處理。

在檢出程式碼路徑中，blob 內容首先透過 text 轉換，然後是 ident，並提供給 filter。

如果您向檔案添加了導致該檔案規範倉庫格式更改的屬性，例如新增 clean/smudge 過濾器或 text/eol/ident 屬性，那麼合併任何沒有這些屬性的地方通常會導致合併衝突。

為了防止這些不必要的合併衝突，可以透過設定 merge.renormalize 配置變數來告訴 Git 對每個需要三向內容合併的檔案執行所有三個階段的虛擬檢出和檢入。這可以防止檢入轉換引起的更改在轉換後的檔案與未轉換的檔案合併時導致虛假的合併衝突。

只要“smudge→clean”的結果與“clean”的結果相同，即使檔案已經被塗抹，這個策略也將自動解決所有與過濾器相關的衝突。不以這種方式工作的過濾器可能會導致必須手動解決的額外合併衝突。

屬性 diff 影響 Git 如何為特定檔案生成差異。它可以告訴 Git 是為路徑生成文字補丁還是將路徑視為二進位制檔案。它還可以影響 hunk 頭部 @@ -k,l +n,m @@ 行上顯示哪一行，告訴 Git 使用外部命令生成差異，或者要求 Git 在生成差異之前將二進位制檔案轉換為文字格式。

差異驅動程式的定義是在 gitconfig 中完成的，而不是在 gitattributes 檔案中，所以嚴格來說，本手冊頁談論它是不對的。然而……

要定義外部差異驅動程式 jcdiff，請在您的 $GIT_DIR/config 檔案（或 $HOME/.gitconfig 檔案）中新增如下部分

當 Git 需要向您顯示 diff 屬性設定為 jcdiff 的路徑的差異時，它會呼叫您透過上述配置指定的命令，即 j-c-diff，帶有 7 個引數，就像呼叫 GIT_EXTERNAL_DIFF 程式一樣。詳情請參閱 git[1]。

如果程式能夠忽略某些更改（類似於 git diff --ignore-space-change），那麼也請將選項 trustExitCode 設定為 true。屆時，如果發現顯著更改，它預計返回退出程式碼 1，否則返回 0。

可以透過 diff.algorithm 配置鍵設定差異演算法，但有時按路徑設定差異演算法可能會有所幫助。例如，您可能希望對 .json 檔案使用 minimal 差異演算法，對 .c 檔案使用 histogram 等，而無需每次都透過命令列傳遞演算法。

首先，在 .gitattributes 中，為路徑分配 diff 屬性。

然後，定義一個 "diff.<name>.algorithm" 配置以指定差異演算法，從 myers、patience、minimal 或 histogram 中選擇。

此差異演算法適用於面向使用者的差異輸出，如 git-diff(1)、git-show(1)，也用於 --stat 輸出。合併機制不會使用透過此方法設定的差異演算法。

文字差異輸出中每個更改組（稱為“hunk”）都以以下形式的行作為字首

這被稱為 hunk header（塊頭）。“TEXT”部分預設是以字母、下劃線或美元符號開頭的行；這與 GNU diff -p 輸出使用的內容匹配。然而，此預設選擇不適用於某些內容，您可以使用自定義模式進行選擇。

首先，在 .gitattributes 中，您將為路徑分配 diff 屬性。

然後，您將定義 "diff.tex.xfuncname" 配置以指定一個正則表示式，該正則表示式匹配您希望作為塊頭“TEXT”出現的行。在您的 $GIT_DIR/config 檔案（或 $HOME/.gitconfig 檔案）中新增如下部分

注意：配置解析器會吞掉一層反斜槓，因此您需要雙倍的反斜槓；上面的模式選擇以反斜槓開頭、後跟零個或多個 sub 再後跟 section 再後跟開括號的行，直到行尾。

有一些內建模式可以使這更容易，其中 tex 就是其中之一，因此您不必在配置檔案中編寫上述內容（您仍然需要透過屬性機制，即 .gitattributes 啟用此功能）。以下內建模式可用

您可以透過在“diff.*.wordRegex”配置變數中指定合適的正則表示式來定製 git diff --word-diff 用於將一行拆分為單詞的規則。例如，在 TeX 中，反斜槓後跟字母序列構成一個命令，但幾個這樣的命令可以連續執行而無需中間空格。要將它們分開，請在您的 $GIT_DIR/config 檔案（或 $HOME/.gitconfig 檔案）中使用如下正則表示式

上一節中列出的所有語言都提供了內建模式。

有時，需要檢視某些二進位制檔案文字轉換版本的差異。例如，文字處理文件可以轉換為 ASCII 文字表示，並顯示文字的差異。儘管這種轉換會丟失一些資訊，但生成的差異對於人類檢視很有用（但無法直接應用）。

textconv 配置選項用於定義執行此類轉換的程式。該程式應接受一個引數，即要轉換的檔名，並將結果文字輸出到標準輸出。

例如，要顯示檔案的 exif 資訊而不是二進位制資訊的差異（假設您已安裝 exif 工具），請將以下部分新增到您的 $GIT_DIR/config 檔案（或 $HOME/.gitconfig 檔案）中

由於文字轉換可能很慢，尤其是在使用 git log -p 進行大量轉換時，Git 提供了一種機制來快取輸出並在未來的差異中使用它。要啟用快取，請在您的差異驅動程式的配置中設定“cachetextconv”變數。例如

這將無限期地快取對每個 blob 執行“exif”的結果。如果您更改差異驅動程式的 textconv 配置變數，Git 將自動使快取條目失效並重新執行 textconv 過濾器。如果您想手動使快取失效（例如，因為您的“exif”版本已更新，現在生成了更好的輸出），您可以使用 git update-ref -d refs/notes/textconv/jpg 手動刪除快取（其中“jpg”是差異驅動程式的名稱，如上面的示例所示）。

如果您想顯示倉庫中二進位制或特殊格式 blob 之間的差異，您可以選擇使用外部差異命令，或者使用 textconv 將它們轉換為可差異的文字格式。選擇哪種方法取決於您的具體情況。

使用外部差異命令的優點是靈活性。您不受限於查詢面向行的更改，也不要求輸出類似於統一差異。您可以自由地以最適合您的資料格式的方式查詢和報告更改。

相比之下，textconv 更具限制性。您提供將資料轉換為面向行的文字格式的轉換，Git 使用其常規差異工具生成輸出。選擇此方法有幾個優點

Git 通常透過檢查內容開頭來正確猜測 blob 是包含文字還是二進位制資料。然而，有時您可能希望覆蓋它的決定，無論是由於 blob 在檔案中包含後來的二進位制資料，還是因為內容，儘管技術上由文字字元組成，但對人類讀者來說是不透明的。例如，許多 Postscript 檔案只包含 ASCII 字元，但會產生嘈雜且無意義的差異。

將檔案標記為二進位制的最簡單方法是在 .gitattributes 檔案中取消設定 diff 屬性

這將導致 Git 生成 Binary files differ（或二進位制補丁，如果啟用了二進位制補丁）而不是常規差異。

但是，可能還需要指定其他差異驅動程式屬性。例如，您可能希望使用 textconv 將 Postscript 檔案轉換為 ASCII 表示以供人工檢視，但否則將它們視為二進位制檔案。您不能同時指定 -diff 和 diff=ps 屬性。解決方案是使用 diff.*.binary 配置選項

merge 屬性影響在 git merge 和其他命令（例如 git revert 和 git cherry-pick）期間需要檔案級合併時，檔案的三個版本如何合併。

有一些內建的低階合併驅動程式，可以透過 merge 屬性請求。

合併驅動程式的定義是在 .git/config 檔案中完成的，而不是在 gitattributes 檔案中，所以嚴格來說，本手冊頁談論它是不對的。然而……

要定義自定義合併驅動程式 filfre，請在您的 $GIT_DIR/config 檔案（或 $HOME/.gitconfig 檔案）中新增如下部分

merge.*.name 變數為驅動程式提供了一個人類可讀的名稱。

merge.*.driver 變數的值用於構建一個命令，該命令執行以處理共同祖先版本 (%O)、當前版本 (%A) 和其他分支的版本 (%B)。當構建命令列時，這些三個令牌將替換為儲存這些版本內容的臨時檔案的名稱。此外，%L 將替換為衝突標記大小（見下文）。

合併驅動程式預期透過覆蓋 %A 指定的檔案來留下合併結果，如果能幹淨合併則以零狀態退出，否則以非零狀態退出表示存在衝突。當驅動程式崩潰（例如被 SEGV 殺死）時，預期以高於 128 的非零狀態退出，在這種情況下，合併會導致失敗（這與產生衝突不同）。

merge.*.recursive 變數指定當合併驅動程式被呼叫以進行多個共同祖先之間的內部合併時，使用哪個其他合併驅動程式。如果未指定，則驅動程式本身將用於內部合併和最終合併。

合併驅動程式可以透過佔位符 %P 瞭解儲存合併結果的路徑名。用於共同祖先、本地頭部和其他頭部的衝突標籤可以透過使用 %S、%X 和 %Y 分別傳遞。

此屬性控制衝突合併期間留在工作樹檔案中的衝突標記的長度。只有正整數才具有有意義的效果。

例如，.gitattributes 中的這一行可用於告訴合併機制，當合並檔案 Documentation/git-merge.adoc 導致衝突時，留下更長（而不是通常的 7 個字元長）的衝突標記。

core.whitespace 配置變數允許您定義 diff 和 apply 應將哪些空白視為專案所有路徑的錯誤（參見 git-config[1]）。此屬性使您能夠對每個路徑進行更精細的控制。

帶有 export-ignore 屬性的檔案和目錄不會新增到存檔檔案中。

如果檔案設定了 export-subst 屬性，那麼 Git 在將此檔案新增到存檔時將展開幾個佔位符。展開取決於提交 ID 的可用性，即，如果 git-archive[1] 已給定樹而不是提交或標籤，則不會進行替換。佔位符與 git-log[1] 的 --pretty=format: 選項的佔位符相同，只是它們需要在檔案中像這樣包裝：$Format:PLACEHOLDERS$。例如，字串 $Format:%H$ 將被提交雜湊替換。但是，每個存檔只展開一個 %(describe) 佔位符，以避免拒絕服務攻擊。

對於 delta 屬性設定為 false 的路徑的 blob，將不嘗試進行增量壓縮。

此屬性的值指定 GUI 工具（例如 gitk[1] 和 git-gui[1]）顯示相關檔案內容時應使用的字元編碼。請注意，出於效能考慮，gitk[1] 不使用此屬性，除非您在其選項中手動啟用按檔案編碼。

如果此屬性未設定或具有無效值，則改用 gui.encoding 配置變數的值（參見 git-config[1]）。