此属性将路径标记为文本文件，从而启用行尾转换：当将匹配的文件添加到索引时，该文件的行尾将在索引中规范化为 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 可以在单个 Git 命令的整个生命周期内使用单个筛选器命令调用处理所有 blob，例如 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 会发送一个以刷新数据包结尾的 “key=value” 对列表。 该列表将至少包含筛选器命令（基于支持的功能）和要筛选的相对于仓库根目录的文件路径名。 紧接着刷新数据包，Git 会将内容拆分为零个或多个 pkt-line 数据包和一个刷新数据包，以终止内容。 请注意，筛选器在收到内容和最终刷新数据包之前不得发送任何响应。 另请注意，“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。 这些请求包含一个路径名和一个空内容部分。 过滤器应以上述通常方式返回经过涂抹的内容。

可以在 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 属性，那么合并任何没有该属性的内容通常会导致合并冲突。

为了防止这些不必要的合并冲突，可以告诉 Git 对每个需要三向内容合并的文件的所有三个阶段运行虚拟签出和签入，方法是设置 merge.renormalize 配置变量。 这可以防止因签入转换引起的更改在合并已转换文件和未转换文件时导致虚假的合并冲突。

只要 "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 标头。"TEXT" 部分默认是一行，以字母、下划线或美元符号开头； 这与 GNU diff -p 输出使用的相匹配。 然而，这种默认选择不适合某些内容，您可以使用自定义模式来进行选择。

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

然后，您将定义一个 "diff.tex.xfuncname" 配置来指定一个正则表达式，该表达式与您希望显示为 hunk 标头 "TEXT" 的行匹配。 向您的 $GIT_DIR/config 文件（或 $HOME/.gitconfig 文件）添加一个像这样的部分

注意：配置文件的解析器会吃掉单层反斜杠，因此您需要将反斜杠加倍； 上面的模式选择一个以反斜杠开头的行，以及零个或多个出现的 sub，后跟 section，后跟左大括号，直到行尾。

有一些内置模式可以简化此操作，而 tex 就是其中之一，因此您不必在配置文件中编写上述内容（您仍然需要通过属性机制，通过 .gitattributes 来启用此功能）。 以下内置模式可用

你可以自定义 git diff --word-diff 用来分割一行中单词的规则，通过在 "diff.*.wordRegex" 配置变量中指定合适的正则表达式。例如，在 TeX 中，反斜杠后跟一系列字母组成一个命令，但多个这样的命令可以不带空格地运行在一起。要分隔它们，可以在你的 $GIT_DIR/config 文件（或 $HOME/.gitconfig 文件）中使用如下的正则表达式：

为前一节中列出的所有语言提供了内置模式。

有时，希望看到一些二进制文件的文本转换版本的差异。 例如，可以将文字处理器文档转换为 ASCII 文本表示形式，并显示该文本的差异。 即使此转换会丢失一些信息，但生成的差异对于人工查看仍然很有用（但不能直接应用）。

textconv 配置选项用于定义执行此类转换的程序。 该程序应采用一个参数，即要转换的文件的名称，并在 stdout 上生成结果文本。

例如，要显示文件的 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 之间的差异，可以选择使用外部 diff 命令，或者使用 textconv 将它们转换为可差异的文本格式。 你选择哪种方法取决于你的具体情况。

使用外部 diff 命令的优点是灵活性。 你不必局限于查找面向行的更改，也不需要输出类似于统一差异。 你可以自由地找到并报告最适合你的数据格式的更改。

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

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

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

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

但是，也可能需要指定其他差异驱动程序属性。 例如，你可能想要使用 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，将不会尝试增量压缩。

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

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