此属性将路径标记为文本文件，这将启用行尾转换：当将匹配的文件添加到索引时，文件的行尾将在索引中规范化为 LF。相反，当从索引复制到工作目录时，其行尾可能会根据eol属性、Git 配置和平台从 LF 转换为 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 网页前端默认情况下不会可视化这些文件的内容。

在这些情况下，您可以使用 working-tree-encoding 属性告诉 Git 工作目录中文件的编码。如果将具有此属性的文件添加到 Git，则 Git 会将内容从指定的编码重新编码为 UTF-8。最后，Git 将 UTF-8 编码的内容存储在其内部数据结构（称为“索引”）中。在检出时，内容将重新编码回指定的编码。

请注意，使用 working-tree-encoding 属性可能存在一些陷阱

仅当您无法以 UTF-8 编码存储文件并且希望 Git 能够将内容作为文本处理时，才使用 working-tree-encoding 属性。

例如，如果您的 *.ps1 文件以 UTF-16 编码（带 BOM），并且您希望 Git 根据您的平台执行自动行结束符转换，则使用以下属性。

如果您的 *.ps1 文件以 UTF-16 小端编码（不带 BOM），并且您希望 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 add --all。如果配置了长期运行的 process 过滤器，则它始终优先于配置的单个 blob 过滤器。有关用于与 process 过滤器通信的协议的说明，请参见下面的部分。

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

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

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

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

注意：每次更改干净过滤器时，都应重新规范化仓库：$ 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 可以使用单个过滤器调用处理所有 Blob，以持续整个 Git 命令的生命周期。这是通过使用长时间运行的进程协议（在 technical/long-running-process-protocol.txt 中描述）实现的。

当 Git 遇到第一个需要清理或涂抹的文件时，它会启动过滤器并执行握手。在握手过程中，Git 发送的欢迎消息是“git-filter-client”，仅支持版本 2，并且支持的功能是“clean”、“smudge”和“delay”。

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

预计过滤器将以一个以刷新数据包结尾的“key=value”对列表进行响应。如果过滤器没有遇到问题，则该列表必须包含“success”状态。在这些数据包之后，预计过滤器将以零个或多个 pkt-line 数据包发送内容，并在末尾使用刷新数据包。最后，预计将出现第二个以刷新数据包结尾的“key=value”对列表。过滤器可以在第二个列表中更改状态或保持状态不变并使用空列表。请注意，无论如何，空列表都必须以刷新数据包结尾。

如果结果内容为空，则预计过滤器将以“success”状态和一个刷新数据包进行响应，以表示空内容。

如果过滤器无法或不希望处理内容，则预计它将以“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”和刷新数据包来延迟过滤当前 Blob（例如，以补偿网络延迟）。

如果过滤器支持“delay”功能，则它必须支持“list_available_blobs”命令。如果 Git 发送此命令，则预计过滤器将返回一个路径名列表，这些路径名表示先前已延迟且现在可用的 Blob。该列表必须以刷新数据包结尾，然后是“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 如何为特定文件生成 diff。它可以告诉 Git 是否为路径生成文本补丁或将路径视为二进制文件。它还可以影响在分块标题 @@ -k,l +n,m @@ 行上显示哪一行，告诉 Git 使用外部命令生成 diff，或要求 Git 将二进制文件转换为文本格式后再生成 diff。

diff 驱动程序的定义是在 gitconfig 中完成的，而不是 gitattributes 文件中，因此严格来说，本手册页谈论它是不合适的。但是…​

要定义外部 diff 驱动程序 jcdiff，请向您的 $GIT_DIR/config 文件（或 $HOME/.gitconfig 文件）添加如下所示的部分

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

如果程序能够忽略某些更改（类似于 git diff --ignore-space-change），则还将选项 trustExitCode 设置为 true。然后，如果它发现重大更改，则预计它将返回退出代码 1，否则返回 0。

可以通过 diff.algorithm 配置键设置 diff 算法，但有时可能需要按路径设置 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配置选项用于定义执行此类转换的程序。该程序应接受一个参数，即要转换的文件名，并在标准输出上生成结果文本。

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

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

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

如果要显示存储库中二进制或特殊格式的 blob 之间的差异，可以选择使用外部 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配置选项

属性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.txt导致冲突时留下更长（而不是通常的 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]）。