此属性将路径标记为文本文件，从而启用换行符转换：当匹配的文件添加到索引时，文件的换行符会在索引中标准化为 LF。反之，当文件从索引复制到工作目录时，其换行符可能会根据 eol 属性、Git 配置和平台转换为 CRLF（见下文对 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 可以在单个 Git 命令的整个生命周期（例如 git add --all）中，通过单次调用过滤器命令处理所有 blob。如果配置了长效 process 过滤器，它总是优先于配置的单 blob 过滤器。有关用于与 process 过滤器通信的协议的说明，请参见下文。

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

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

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

通过将 filter.<driver>.required 配置变量设置为 true，您可以声明过滤器将本身不可用的内容转换为可用的内容。

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

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

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

为了获得最佳效果，如果运行两次，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 遇到第一个需要 clean 或 smudge 的文件时，它会启动过滤器并执行握手。在握手中，Git 发送的欢迎消息是 "git-filter-client"，仅支持版本 2，支持的功能是 "clean"、"smudge" 和 "delay"。

随后，Git 发送一组以 flush 数据包结尾的 "key=value" 键值对列表。该列表将至少包含过滤器命令（基于支持的功能）和相对于仓库根目录要过滤的文件路径名。在 flush 数据包之后，Git 会立即发送拆分为零个或多个 pkt-line 数据包的内容，并以 flush 数据包结束内容。请注意，过滤器在接收到内容和最终 flush 数据包之前，不得发送任何响应。另请注意，"key=value" 键值对的 "value" 可以包含 "=" 字符，而键永远不会包含该字符。

预期过滤器以一个以 flush 数据包结束的 "key=value" 键值对列表进行响应。如果过滤器没有遇到问题，该列表必须包含 "success" 状态。在这些数据包之后，预期过滤器以零个或多个 pkt-line 数据包发送内容，最后以一个 flush 数据包结束。最后，预期第二个以 flush 数据包结束的 "key=value" 列表。过滤器可以在第二个列表中更改状态，或保持状态不变（使用空列表）。请注意，无论如何空列表都必须以 flush 数据包结束。

如果结果内容为空，则预期过滤器响应 "success" 状态和 flush 数据包以发出空内容信号。

如果过滤器不能或不想处理内容，则预期它返回 "error" 状态。

如果过滤器在处理过程中遇到错误，它可以在内容（部分或全部）发送后发送 "error" 状态。

如果过滤器在 Git 进程的生命周期内既不能也不想处理该内容以及任何未来的内容，则预期它在协议的任何点响应 "abort" 状态。

如果设置了 "error"/"abort" 状态，Git 既不会停止也不会重新启动过滤器进程。但是，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。这些请求包含一个路径名和一个空内容部分。预期过滤器以常规方式响应经过 smudge 处理的内容，如上所述。

长效过滤器演示实现可以在 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" 的结果相同（即使是对已经 smudge 处理过的文件），这种策略就会自动解决所有与过滤器相关的冲突。不以此方式运行的过滤器可能会导致额外的合并冲突，必须手动解决。

diff 属性影响 Git 如何为特定文件生成差异。它可以告诉 Git 是为路径生成文本补丁还是将路径视为二进制文件。它还可以影响 hunk 标题行 @@ -k,l +n,m @@ 显示的内容，告诉 Git 使用外部命令生成差异，或要求 Git 在生成差异之前将二进制文件转换为文本格式。

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

要定义外部 diff 驱动程序 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 配置选项用于定义执行此类转换的程序。该程序应接受一个参数（要转换的文件名），并在 stdout 上生成生成的文本。

例如，要显示文件的 exif 信息差异而不是二进制信息（假设您安装了 exif 工具），请向您的 $GIT_DIR/config 文件（或 $HOME/.gitconfig 文件）添加以下部分：

因为文本转换可能很慢，特别是当使用 git log -p 进行大量转换时，Git 提供了一种缓存输出并在未来差异中使用的机制。要启用缓存，请在 diff 驱动程序的配置中设置 "cachetextconv" 变量。例如：

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

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

使用外部 diff 命令的优点是灵活性。您不受限于查找面向行的更改，输出也不必类似于统一差异 (unified diff)。您可以自由地以最适合您的数据格式的方式定位和报告更改。

相比之下，textconv 的限制要多得多。您提供数据到面向行的文本格式的转换，Git 使用其常规 diff 工具生成输出。选择这种方法有几个优点：

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

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

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

然而，人们可能还想指定其他 diff 驱动程序属性。例如，您可能想使用 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 获知合并结果将存储的路径名。用于共同祖先、本地 HEAD 和其他 HEAD 的冲突标签可以分别使用 %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]）。