此属性将路径标记为文本文件，从而启用换行符转换：当匹配的文件被添加到索引时，文件的行尾会被标准化为 LF。反之，当文件从索引复制到工作目录时，根据 eol 属性、Git 配置和平台（参见下方 eol 的解释），其行尾可能会从 LF 转换为 CRLF。

任何其他值都会导致 Git 表现得好像 text 一直是未指定状态。

此属性标记一个路径，使其在检出到工作树时使用特定的行尾样式。它仅在设置了 text 或 text=auto 时生效（参见上文），但指定 eol 会自动设置 text，前提是 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 可以在单个 Git 命令的整个生命周期内用一个过滤器命令调用处理所有 blob，例如 git add --all。如果配置了长时运行的 process 过滤器，它将始终优先于配置的单个 blob 过滤器。有关与 process 过滤器通信的协议的描述，请参见下面的章节。

内容过滤的一个用途是将内容处理成更适合平台、文件系统和用户使用的形式。对于这种操作模式，这里的关键短语是“更方便”，而不是“将不可用的东西变成可用的”。换句话说，目的是如果有人取消了过滤器驱动程序的定义，或者没有适当的过滤器程序，项目仍然应该是可用的。

内容过滤的另一个用途是存储无法直接在仓库中使用（例如，指向存储在 Git 外部的真实内容的 UUID，或加密内容）的内容，并在检出时将其转换为可用形式（例如，下载外部内容或解密加密内容）。

这两种过滤器行为不同，默认情况下，过滤器被视为前者，即将内容处理成更方便的形状。配置中缺少过滤器驱动程序的定义，或退出状态非零的过滤器驱动程序，都不是错误，而是使过滤器成为一个无操作的直通。

您可以通过设置 `filter..required` 配置变量为 true 来声明一个过滤器可以将本身无法使用但内容变为可用的内容。

注意：每当更改 clean 过滤器时，都应重新规范化仓库：$ git add --renormalize .

例如，在 .gitattributes 中，您会为路径分配 filter 属性。

然后，您将在 .git/config 中定义 "filter.indent.clean" 和 "filter.indent.smudge" 配置，以指定一对命令，用于在检入（运行 "clean"）和检出（因为命令是 "cat"，所以不进行更改）C 程序源文件时修改其内容。

为了获得最佳结果，`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 永远不会包含该字符。

过滤器应响应一个由 flush 包结束的 "key=value" 对列表。如果过滤器没有遇到问题，列表必须包含 "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" 标志。此标志表示过滤器可以通过响应不带内容但带有 "delayed" 状态和一个 flush 包来延迟过滤当前 blob（例如，以补偿网络延迟）。

如果过滤器支持 "delay" 功能，则它必须支持 "list_available_blobs" 命令。如果 Git 发送此命令，则过滤器应返回一个路径名列表，这些路径名代表先前已延迟的 blob，现在已可用。列表必须以 flush 包结束，后跟一个也以 flush 包结束的 "success" 状态。如果尚未提供延迟路径的 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 是生成文本补丁还是将路径视为二进制文件。它还可以影响将在块头 @@ -k,l +n,m @@ 行上显示的内容，告诉 Git 使用外部命令生成差异，或要求 Git 在生成差异之前将二进制文件转换为文本格式。

diff 驱动程序的定义是在 gitconfig 中完成的，而不是在 gitattributes 文件中，所以严格来说，本手册页不适合讨论它。然而……

要定义一个名为 jcdiff 的外部 diff 驱动，请在你的 $GIT_DIR/config 文件（或 $HOME/.gitconfig 文件）中添加一个如下所示的节：

当 Git 需要显示具有 diff 属性且值为 jcdiff 的路径的 diff 时，它会调用上述配置中指定的命令，即 j-c-diff，并带 7 个参数，就像调用 GIT_EXTERNAL_DIFF 程序一样。详情请参阅 git[1]。

如果程序能够忽略某些更改（类似于 git diff --ignore-space-change），那么也请将 trustExitCode 选项设置为 true。此时，程序应在发现重要更改时返回退出码 1，在未发现重要更改时返回 0。

diff 算法可以通过 diff.algorithm 配置键来设置，但有时按路径设置 diff 算法可能更有帮助。例如，你可能希望对 .json 文件使用 minimal diff 算法，对 .c 文件使用 histogram 算法，等等，而不必每次都通过命令行传递算法。

首先，在 .gitattributes 文件中，为路径分配 diff 属性。

然后，定义一个 "diff.<name>.algorithm" 配置来指定 diff 算法，可从 myers、patience、minimal 或 histogram 中选择。

此 diff 算法适用于用户可见的 diff 输出，如 git-diff(1)、git-show(1)，也用于 --stat 输出。合并机制不会使用通过此方法设置的 diff 算法。

文本 diff 输出中的每一组更改（称为“块”）前面都会加上一行如下形式的前缀：

这被称为 *块头*。“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 文件）中使用如下所示的正则表达式：

上一节中列出的所有语言都提供了一个内置模式。

有时，查看某些二进制文件的文本转换版本的 diff 是有益的。例如，可以将文字处理文档转换为 ASCII 文本表示，并显示文本的 diff。尽管这种转换会丢失一些信息，但生成的 diff 对人类查看很有用（但不能直接应用）。

textconv 配置选项用于定义一个执行此类转换的程序。该程序应该接受一个参数，即要转换的文件名，并将结果文本输出到 stdout。

例如，要显示文件 EXIF 信息而不是二进制信息的 diff（假设你已安装 exif 工具），请在你的 $GIT_DIR/config 文件（或 $HOME/.gitconfig 文件）中添加以下节：

由于文本转换可能很慢，尤其是在使用 git log -p 执行大量转换时，Git 提供了一种机制来缓存输出并在将来的 diff 中使用它。要启用缓存，请在你的 diff 驱动程序的配置中设置 "cachetextconv" 变量。例如：

这将在无限期内缓存运行 "exif" 在每个 blob 上的结果。如果你更改了 diff 驱动程序的 textconv 配置变量，Git 将自动使缓存条目失效并重新运行 textconv 过滤器。如果你想手动使缓存失效（例如，因为你的 "exif" 版本已更新并现在产生更好的输出），你可以使用 git update-ref -d refs/notes/textconv/jpg 手动删除缓存（其中 "jpg" 是 diff 驱动程序的名称，如上面的示例所示）。

如果你想显示仓库中二进制文件或特殊格式文件的差异，可以选择使用外部 diff 命令，或者使用 textconv 将它们转换为可 diff 的文本格式。你选择哪种方法取决于你的具体情况。

使用外部 diff 命令的优势在于灵活性。你不必局限于查找行定向的更改，也不必要求输出类似于统一 diff。你可以自由地以最适合你的数据格式的方式查找和报告更改。

相比之下，textconv 的限制要大得多。你提供了一个将数据转换为行定向文本格式的转换，然后 Git 使用其常规 diff 工具来生成输出。选择此方法有几个优点：

Git 通常通过检查内容开头来正确猜测 blob 是包含文本还是二进制数据。但是，有时你可能想覆盖它的决定，无论是由于 blob 在文件后面包含二进制数据，还是由于内容虽然技术上由文本字符组成，但对人类读者来说是不透明的。例如，许多 PostScript 文件仅包含 ASCII 字符，但会产生嘈杂且无意义的 diff。

将文件标记为二进制的最简单方法是在 .gitattributes 文件中取消设置 diff 属性：

这将导致 Git 生成 Binary files differ（如果启用了二进制补丁，则生成二进制补丁），而不是常规 diff。

然而，有时也可能需要指定其他 diff 驱动属性。例如，你可能希望使用 textconv 将 PostScript 文件转换为 ASCII 表示以供人类查看，但否则将其视为二进制文件。你不能同时指定 -diff 和 diff=ps 属性。解决方案是使用 diff.*.binary 配置选项：

当在 git merge、git revert 和 git cherry-pick 等命令需要进行文件级合并时，merge 属性会影响三份文件版本的合并方式。

有一些内置的低级合并驱动程序可以通过 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，将不会尝试进行 delta 压缩。

此属性的值指定 GUI 工具（例如 gitk[1] 和 git-gui[1]）应该使用的字符编码来显示相关文件的内容。请注意，由于性能考虑，gitk[1] 不会使用此属性，除非你在其选项中手动启用每个文件的编码。

如果未设置此属性或其值无效，则将使用 gui.encoding 配置变量的值（参见 git-config[1]）。