Git 中文参考（五）（3）

Git 中文参考（五）（2）https://developer.aliyun.com/article/1565846

默认情况下，该命令显示每个匹配的文件名。 -h选项用于抑制此输出。 -H是完整性的，除了它覆盖了之前在命令行中给出的-h之外什么都不做。

--full-name 

从子目录运行时，该命令通常输出相对于当前目录的路径。此选项强制路径相对于项目顶级目录输出。

-E 

--extended-regexp 

-G 

--basic-regexp 

使用 POSIX 扩展/基本正则表达式来表示模式。默认是使用基本正则表达式。

-P 

--perl-regexp 

对模式使用与 Perl 兼容的正则表达式。

对这些类型的正则表达式的支持是可选的编译时依赖性。如果 Git 没有编译并支持它们，那么提供此选项将导致它死亡。

-F 

--fixed-strings 

对模式使用固定字符串（不要将模式解释为正则表达式）。

-n 

--line-number 

将行号前缀为匹配行。

--column 

从匹配行的开头开始对第一个匹配的 1 索引字节偏移进行前缀。

-l 

--files-with-matches 

--name-only 

-L 

--files-without-match 

不显示每个匹配的行，而是仅显示包含（或不包含）匹配的文件的名称。为了更好地与 git diff 兼容，--name-only是--files-with-matches的同义词。

-O[<pager>] 

--open-files-in-pager[=<pager>] 

打开寻呼机中的匹配文件（不是 grep 的输出）。如果寻呼机恰好是“较少”或“vi”，并且用户仅指定了一个模式，则第一个文件将自动定位在第一个匹配位置。 pager参数是可选的;如果指定，它必须粘在没有空格的选项上。如果未指定pager，将使用默认寻呼机（参见 git-config [1] 中的core.pager）。

-z 

--null 

输出\ 0 而不是通常在文件名后面的字符。

-o 

--only-matching 

仅打印匹配行的匹配（非空）部分，每个此类部分位于单独的输出行上。

-c 

--count 

而不是显示每个匹配的行，而是显示匹配的行数。

--color[=<when>] 

显示彩色火柴。该值必须始终为（默认值），never 或 auto。

--no-color 

关闭匹配突出显示，即使配置文件提供默认的颜色输出。与--color=never相同。

--break 

在不同文件的匹配项之间打印空行。

--heading 

在该文件中的匹配项上方显示文件名，而不是在每个显示的行的开头。

-p 

--show-function 

显示包含匹配函数名称的上一行，除非匹配行是函数名称本身。名称的确定方式与 git diff 计算出补丁程序块标题的方式相同（参见 _ 在 gitattributes [5] 中定义自定义的 hunk-header_ ）。

-<num> 

-C <num> 

--context <num> 

显示< num>前导和尾随行，并在连续的匹配组之间放置包含--的行。

-A <num> 

--after-context <num> 

显示< num>尾随行，并在连续的匹配组之间放置一行包含--。

-B <num> 

--before-context <num> 

显示< num>引导线，并在连续的匹配组之间放置包含--的行。

-W 

--function-context 

显示上一行中包含函数名称的周围文本，直到下一个函数名称之前的文本，有效地显示了找到匹配项的整个函数。

--threads <num> 

要使用的 grep 工作线程数。有关详细信息，请参见 CONFIGURATION 中的grep.threads。

-f <file> 

从< file>中读取模式，每行一个。

-e 

下一个参数是模式。此选项必须用于以-开头的模式，并且应该在将用户输入传递给 grep 的脚本中使用。多个模式由 _ 或 _ 组合。

--and 

--or 

--not 

( … ) 

指定如何使用布尔表达式组合多个模式。 --or是默认运算符。 --and的优先级高于--or。 -e必须用于所有模式。

--all-match 

当给出多个模式表达式与--or组合时，指定此标志以限制匹配到具有匹配所有这些行的行的文件。

-q 

--quiet 

不输出匹配的线;相反，当匹配时退出状态 0，当没有匹配时退出非零状态。

<tree>… 

不是搜索工作树中的跟踪文件，而是搜索给定树中的 blob。

-- 

表示选项的结束;其余参数是< pathspec>限制器。

<pathspec>… 

如果给定，则将搜索限制为与至少一个模式匹配的路径。两个前导路径匹配，并支持 glob（7）模式。

有关< pathspec>的详细信息语法，请参阅 gitglossary [7] 中的 pathspec 条目。

例子

git grep 'time_t' -- '*.[ch]' 

在工作目录及其子目录中的所有跟踪的.c 和.h 文件中查找time_t。

git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \) 

查找具有#define和MAX_PATH或PATH_MAX的行。

git grep --all-match -e NODE -e Unexpected 

在具有与两者匹配的行的文件中查找具有NODE或Unexpected的行。

git grep solution -- :^Documentation 

查找solution，不包括Documentation中的文件。

GIT

部分 git [1] 套件

gitattributes

原文： git-scm.com/docs/gitattributes

名称

gitattributes - 定义每个路径的属性

概要

$ GIT_DIR / info / attributes，.gitattributes

描述

gitattributes文件是一个简单的文本文件，它为路径名提供attributes。

gitattributes文件中的每一行都是以下形式：

pattern attr1 attr2 ...

也就是说，一个模式后跟一个属性列表，用空格分隔。前导空格和尾随空格被忽略。以 ＃ 开头的行将被忽略。以双引号开头的模式以 C 风格引用。当模式匹配相关路径时，该行上列出的属性将被赋予路径。

对于给定路径，每个属性可以处于以下状态之一：

Set 

该路径具有特殊值“true”的属性;这是通过仅列出属性列表中属性的名称来指定的。

Unset 

该路径具有特殊值“false”的属性;这是通过在属性列表中列出前缀为短划线-的属性的名称来指定的。

Set to a value 

该路径具有指定字符串值的属性;这是通过列出属性的名称，后跟等号=及其在属性列表中的值来指定的。

Unspecified 

没有模式匹配路径，没有任何说明路径是否具有属性，路径的属性被称为未指定。

当多个模式与路径匹配时，后一行会覆盖较早的行。这个覆盖是按属性完成的。

模式匹配路径的规则与.gitignore文件中的规则相同（参见 gitignore [5] ），但有一些例外：

• 消极的模式被禁止
  
• 与目录匹配的模式不会递归地匹配该目录中的路径（因此在属性文件中使用尾部斜杠path/语法是没有意义的;使用path/**代替）
  

在确定为路径分配了哪些属性时，Git 会查询$GIT_DIR/info/attributes文件（具有最高优先级），.gitattributes文件与相关路径位于同一目录中，其父目录最多为工作树的顶层（包含.gitattributes的目录越远离有问题的路径，其优先级越低）。最后考虑全局和系统范围的文件（它们具有最低优先级）。

当工作树中缺少.gitattributes文件时，索引中的路径将用作后退。在检出过程中，使用索引中的.gitattributes，然后将工作树中的文件用作后备。

如果您希望仅影响单个存储库（即，将属性分配给特定于该存储库的一个用户工作流的文件），则应将属性放在$GIT_DIR/info/attributes文件中。应该由版本控制并分发到其他存储库的属性（即，所有用户感兴趣的属性）应该进入.gitattributes文件。应该影响单个用户的所有存储库的属性应该放在由core.attributesFile配置选项指定的文件中（参见 git-config [1] ）。其默认值为XDGCONFIGHOME/git/attributes。如果XDGCONFIGHOME/git/attributes。如果 XDG_CONFIG_HOME / git / attributes。如果 XDG_CONFIG_HOME 未设置或为空，则使用$ HOME / .config / git / attributes。系统中所有用户的属性应放在$(prefix)/etc/gitattributes文件中。

有时您需要覆盖Unspecified状态路径的属性设置。这可以通过列出前缀为感叹号!的属性的名称来完成。

影响

通过为路径分配特定属性可以影响 Git 的某些操作。目前，以下操作是属性感知的。

退房和登记入住

当 git checkout 和 git merge 等命令运行时，这些属性会影响存储库中存储的内容如何复制到工作树文件。它们还会影响 Git 如何在 git add 和 git commit 中存储您在存储库中的工作树中准备的内容。

text

此属性启用并控制行尾标准化。对文本文件进行规范化后，其行结尾将在存储库中转换为 LF。要控制工作目录中使用的行结束样式，请对单个文件使用eol属性，对所有文本文件使用core.eol配置变量。请注意，将core.autocrlf设置为true或input会覆盖core.eol（请参阅 git-config [1] 中这些选项的定义）。

Set 

在路径上设置text属性可启用行尾标准化，并将路径标记为文本文件。在不猜测内容类型的情况下进行行尾转换。

Unset 

取消设置路径上的text属性会告诉 Git 在签入或结帐时不要尝试任何行尾转换。

Set to string value "auto" 

当text设置为“auto”时，路径将标记为自动行结束转换。如果 Git 决定内容是文本，则其行结尾将在签入时转换为 LF。使用 CRLF 提交文件时，不会进行任何转换。

Unspecified 

如果未指定text属性，Git 使用core.autocrlf配置变量来确定是否应转换文件。

任何其他值都会导致 Git 表现为好像没有指定text。

eol

此属性设置要在工作目录中使用的特定行结束样式。它可以在没有任何内容检查的情况下实现行尾转换，从而有效地设置text属性。请注意，在具有 CRLF 行结尾的索引中的路径上设置此属性可能会使路径被视为脏。再次将索引添加到索引将规范化索引中的行结尾。

Set to string value "crlf" 

此设置强制 Git 在签入时规范化此文件的行结尾，并在签出文件时将它们转换为 CRLF。

Set to string value "lf" 

此设置强制 Git 在签入时将行结尾标准化为 LF，并在签出文件时阻止转换为 CRLF。

向后兼容crlf属性

为了向后兼容，crlf属性解释如下：

crlf    text
-crlf   -text
crlf=input  eol=lf

行尾转换

虽然 Git 通常单独保留文件内容，但可以将其配置为将行结尾标准化为存储库中的 LF，并且可选地，在检出文件时将它们转换为 CRLF。

如果您只想在工作目录中使用 CRLF 行结尾，而不管您正在使用哪个存储库，则可以设置配置变量“core.autocrlf”而不使用任何属性。

[core]
  autocrlf = true

这不会强制文本文件的规范化，但确保引入存储库的文本文件在添加时将其行结尾标准化为 LF，并且已在存储库中标准化的文件保持规范化。

如果要确保任何贡献者引入存储库的文本文件的行结束标准化，可以将 _ 所有 _ 文件的text属性设置为“auto”。

* text=auto

这些属性允许细粒度控制，如何转换行结尾。下面是一个示例，它将使 Git 规范化.txt，.vcproj 和.sh 文件，确保.vcproj 文件的 CRLF 和.sh 文件在工作目录中具有 LF，并防止.jpg 文件无论其内容如何都被规范化。

*               text=auto
*.txt   text
*.vcproj  text eol=crlf
*.sh    text eol=lf
*.jpg   -text

| 注意 | 使用推送和拉到中央存储库的跨平台项目中启用text=auto转换时，应对包含 CRLF 的文本文件进行规范化。 |

从干净的工作目录：

$ echo "* text=auto" >.gitattributes
$ git add --renormalize .
$ git status        # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"

如果任何不应归一化的文件出现在 git status 中，请在运行 git add -u 之前取消设置text属性。

manual.pdf  -text

相反，Git 未检测到的文本文件可以手动启用规范化。

weirdchars.txt  text

如果core.safecrlf设置为“true”或“warn”，Git 将验证当前设置core.autocrlf的转换是否可逆。对于“真实”，Git 拒绝不可逆转的转换;对于“警告”，Git 仅打印警告但接受不可逆转的转换。安全触发器可以防止对工作树中的文件进行此类转换，但也有一些例外情况。即使…

• git add 本身不会触及工作树中的文件，下次检出就会，所以安全触发器;
  
• git apply 用补丁更新文本文件确实触摸了工作树中的文件，但操作是关于文本文件而 CRLF 转换是关于修复行结尾不一致的，所以安全性不会触发;
  
• git diff 本身不会触及工作树中的文件，它经常运行以检查你打算下一步的更改 git add 。为了及早发现潜在问题，安全触发。
  

working-tree-encoding

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属性可能会有一些陷阱：

• 替代 Git 实现（例如 JGit 或 libgit2）和较旧的 Git 版本（截至 2018 年 3 月）不支持working-tree-encoding属性。如果决定使用存储库中的working-tree-encoding属性，则强烈建议确保使用存储库的所有客户端都支持它。
  例如，Microsoft Visual Studio 资源文件（*.rc）或 PowerShell 脚本文件（*.ps1）有时以 UTF-16 编码。如果将*.ps1声明为 UTF-16 文件并添加foo.ps1并启用working-tree-encoding Git 客户端，则foo.ps1将在内部存储为 UTF-8。没有working-tree-encoding支持的客户端将foo.ps1签出为 UTF-8 编码文件。这通常会给该文件的用户带来麻烦。
  如果不支持working-tree-encoding属性的 Git 客户端添加新文件bar.ps1，则bar.ps1将在内部“按原样”存储（在此示例中可能为 UTF-16）。具有working-tree-encoding支持的客户端将内部内容解释为 UTF-8 并尝试在检出时将其转换为 UTF-16。该操作将失败并导致错误。
  
• 将内容重新编码为非 UTF 编码可能会导致错误，因为转换可能不是 UTF-8 往返安全。如果您怀疑您的编码不是往返安全，那么将其添加到core.checkRoundtripEncoding以使 Git 检查往返编码（参见 git-config [1] ）。已知 SHIFT-JIS（日语字符集）具有 UTF-8 的往返问题，默认情况下会进行检查。
  
• 重新编码内容需要可能减慢某些 Git 操作的资源（例如 git checkout 或 git add ）。
  

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

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

*.ps1   text working-tree-encoding=UTF-16

如果您的 * .ps1 文件是 UTF-16 小端编码而没有 BOM，并且您希望 Git 在工作目录中使用 Windows 行结尾，请使用以下属性（如果您使用UTF-16-LE-BOM而不是UTF-16LE想要带有 BOM 的 UTF-16 小端。请注意，如果使用working-tree-encoding属性来避免歧义，强烈建议使用eol明确定义行结尾。

*.ps1   text working-tree-encoding=UTF-16LE eol=CRLF

您可以使用以下命令获取平台上所有可用编码的列表：

iconv --list

如果您不知道文件的编码，则可以使用file命令猜测编码：

file foo.ps1

ident

当为路径设置属性ident时，Git 用$Id:替换 blob 对象中的$Id$，后跟 40 个字符的十六进制 blob 对象名称，然后在结帐时使用美元符号$。任何以$Id:开头并以 worktree 文件中的$结尾的字节序列在签入时将替换为$Id$。

filter

可以将filter属性设置为字符串值，该值指定配置中指定的过滤器驱动程序。

过滤器驱动程序由clean命令和smudge命令组成，其中任何一个都可以不指定。签出时，当指定smudge命令时，命令从其标准输入中提供 blob 对象，其标准输出用于更新工作树文件。同样，clean命令用于在签入时转换 worktree 文件的内容。默认情况下，这些命令仅处理单个 blob 并终止。如果使用长时间运行的process过滤器代替clean和/或smudge过滤器，那么 Git 可以在单个 Git 命令的整个生命周期内使用单个过滤器命令调用处理所有 blob，例如git add --all。如果配置了长时间运行的process过滤器，则它始终优先于配置的单个 blob 过滤器。有关用于与process过滤器通信的协议的说明，请参阅以下部分。

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

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

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

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

注意：每当更改清理过滤器时，repo 应重新规范化：$ git add --renormalize。

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

*.c filter=indent

然后，您将在.git / config  中定义“filter.indent.clean”和“filter.indent.smudge”配置，以指定一对命令，以便在签入源文件时修改 C  程序的内容（“clean” “运行”并检出（因为命令是“cat”而没有进行任何更改）。

[filter "indent"]
  clean = indent
  smudge = cat

为了获得最佳效果，clean如果运行两次（“清洁→清洁”应相当于“清洁”），则不应进一步改变其输出，并且多个smudge命令不应改变clean的输出（“涂抹→涂抹→清洁“应相当于”清洁“）。请参阅下面的合并部分。

“indent”过滤器在这方面表现良好：它不会修改已经正确缩进的输入。在这种情况下，没有污迹过滤器意味着清洁过滤器 _ 必须 _ 接受自己的输出而不修改它。

如果过滤器 _ 必须 _ 成功才能使存储的内容可用，您可以在配置中声明过滤器为required：

[filter "crypt"]
  clean = openssl enc ...
  smudge = openssl enc -d ...
  required

过滤器命令行上的序列“％f”将替换为过滤器正在处理的文件的名称。过滤器可能会在关键字替换中使用它。例如：

[filter "p4"]
  clean = git-p4-filter --clean %f
  smudge = git-p4-filter --smudge %f

请注意，“％f”是正在处理的路径的名称。根据要过滤的版本，磁盘上的相应文件可能不存在，或者可能具有不同的内容。因此，涂抹和清除命令不应该尝试访问磁盘上的文件，而只是作为标准输入上提供给它们的内容的过滤器。

Git 中文参考（五）（4）https://developer.aliyun.com/article/1565848