Git 中文参考（四）（3）

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

使用-p 生成补丁

当“git-diff-index”，“git-diff-tree”或“git-diff-files”使用-p选项运行时，“git diff”不带--raw选项或“git log”使用“-p”选项，它们不会产生上述输出;相反，他们生成一个补丁文件。您可以通过GIT_EXTERNAL_DIFF和GIT_DIFF_OPTS环境变量自定义此类修补程序的创建。

-p 选项产生的内容与传统的 diff 格式略有不同：

1. 它前面有一个“git diff”标题，如下所示：

diff --git a/file1 b/file2

1. 除非涉及重命名/复制，否则a/和b/文件名是相同的。特别是，即使是创建或删除，/dev/null也是 _ 而不是 _ 来代替a/或b/文件名。
   当涉及重命名/复制时，file1和file2分别显示重命名/复制的源文件的名称和重命名/复制的文件的名称。
2. 它后跟一个或多个扩展标题行：

old mode <mode>
new mode <mode>
deleted file mode <mode>
new file mode <mode>
copy from <path>
copy to <path>
rename from <path>
rename to <path>
similarity index <number>
dissimilarity index <number>
index <hash>..<hash> <mode>

1. 文件模式打印为 6 位八进制数，包括文件类型和文件权限位。
   扩展标头中的路径名不包括a/和b/前缀。
   相似性指数是未更改行的百分比，相异性指数是更改行的百分比。它是一个向下舍入的整数，后跟一个百分号。因此，100％的相似性索引值保留用于两个相等的文件，而 100％的相异性意味着旧文件中的任何行都不会成为新文件。
   索引行包括更改前后的 SHA-1 校验和。 <模式>如果文件模式没有改变，则包括在内;否则，单独的行表示旧模式和新模式。
2. 具有“异常”字符的路径名被引用，如配置变量core.quotePath所述（参见 git-config [1] ）。
   
3. 输出中的所有file1文件在提交之前引用文件，并且所有file2文件在提交之后引用文件。将每个更改顺序应用于每个文件是不正确的。例如，此补丁将交换 a 和 b：

diff --git a/a b/b
rename from a
rename to b
diff --git a/b b/a
rename from b
rename to a

组合差异格式

在显示合并时，任何差异生成命令都可以使用-c或--cc选项生成 _ 组合差异 _。当显示与 git-diff [1] 或 git-show [1] 的合并时，这是默认格式。另请注意，您可以为这些命令中的任何一个提供-m选项，以强制使用合并的各个父项生成差异。

_ 组合 diff_ 格式如下所示：

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
  return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }
- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +  unsigned char sha1[20];
 +  struct commit *cmit;
  struct commit_list *list;
  static int initialized = 0;
  struct commit_name *n;
 +  if (get_sha1(arg, sha1) < 0)
 +    usage(describe_usage);
 +  cmit = lookup_commit_reference(sha1);
 +  if (!cmit)
 +    usage(describe_usage);
 +
  if (!initialized) {
    initialized = 1;
    for_each_ref(get_name);

1. 它前面有一个“git diff”标题，看起来像这样（当使用-c选项时）：

diff --combined file

1. 或者像这样（当使用--cc选项时）：

diff --cc file

1. 它后跟一个或多个扩展标题行（此示例显示了与两个父项的合并）：

index <hash>,<hash>..<hash>
mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>

1. 只有当< mode>中的至少一个出现时，mode ,..行才会出现。与其他人不同。具有关于检测到的内容移动（重命名和复制检测）的信息的扩展标题被设计为与两个< tree-ish>的差异一起工作。并且不会被组合 diff 格式使用。
2. 接下来是两行的文件/文件头

--- a/file
+++ b/file

1. 与传统 _ 统一 _ diff 格式的双行标题类似，/dev/null用于表示创建或删除的文件。
2. 修改了块头格式以防止人们意外地将其馈送到patch -p1。创建组合差异格式用于审查合并提交更改，并不适用于应用。此更改类似于扩展 _ 索引 _ 标头中的更改：

@@@ <from-file-range> <from-file-range> <to-file-range> @@@

1. 组合 diff 格式的块头中有（父项数+ 1）@个字符。

与传统的 _ 统一 _ 差异格式不同，后者显示两个文件 A 和 B，其中一列具有-（减去 - 出现在 A 中但在 B 中删除），+（加 - 缺少 A 但是添加到 B）或" "（空格 - 未更改）前缀，此格式将两个或多个文件 file1，file2，…与一个文件 X 进行比较，并显示 X 与每个文件 N 的不同之处。每个 fileN 的一列被添加到输出行之前，以指示 X 的行与它的不同之处。

N 列中的-字符表示该行出现在 fileN 中，但它不会出现在结果中。列 N 中的+字符表示该行出现在结果中，而 fileN 没有该行（换句话说，从该父项的角度添加了该行）。

在上面的示例输出中，函数签名已从两个文件中更改（因此，file1 和 file2 中的两个-删除加上++表示添加的一行未出现在 file1 或 file2 中）。另外八行与 file1 相同，但不出现在 file2 中（因此以+为前缀）。

当由git diff-tree -c显示时，它将合并提交的父项与合并结果进行比较（即 file1…fileN 是父项）。当由git diff-files -c显示时，它将两个未解析的合并父项与工作树文件进行比较（即 file1 是阶段 2 又名“我们的版本”，file2 是阶段 3 又名“他们的版本”）。

例子

git show v1.0.0 

显示标签v1.0.0以及标签指向的对象。

git show v1.0.0^{tree} 

显示标签v1.0.0指向的树。

git show -s --format=%s v1.0.0^{commit} 

显示标记v1.0.0指向的提交主题。

git show next~10:Documentation/README 

显示文件Documentation/README的内容，因为它们是分支next的第 10 次最后提交时的当前内容。

git show master:Makefile master:t/Makefile 

在分支master的头部连接所述 Makefile 的内容。

讨论

Git 在某种程度上是字符编码不可知的。

• blob 对象的内容是未解释的字节序列。核心级别没有编码转换。
  
• 路径名以 UTF-8 规范化形式 C 编码。这适用于树对象，索引文件，ref 名称，以及命令行参数，环境变量和配置文件中的路径名（.git/config（参见 git） -config [1] ）， gitignore [5] ， gitattributes [5] 和 gitmodules [5] ）。
  请注意，核心级别的  Git 仅将路径名称视为非 NUL 字节序列，没有路径名称编码转换（Mac 和 Windows 除外）。因此，即使在使用传统扩展 ASCII  编码的平台和文件系统上，使用非 ASCII 路径名也会起作用。但是，在此类系统上创建的存储库将无法在基于 UTF-8 的系统（例如  Linux，Mac，Windows）上正常工作，反之亦然。此外，许多基于 Git 的工具只是假设路径名为 UTF-8，并且无法正确显示其他编码。
  
• 提交日志消息通常以  UTF-8 编码，但也支持其他扩展 ASCII 编码。这包括 ISO-8859-x，CP125x 和许多其他，但 _ 不是 _  UTF-16/32，EBCDIC 和 CJK 多字节编码（GBK，Shift-JIS，Big5，EUC-x，CP9xx 等。 ）。
  

虽然我们鼓励提交日志消息以 UTF-8 编码，但核心和 Git 瓷器都不是为了强制项目使用 UTF-8。如果特定项目的所有参与者发现使用遗留编码更方便，Git 不会禁止它。但是，有一些事情需要牢记。

1. git commit 和 git commit-tree 发出警告，如果提供给它的提交日志消息看起来不像有效的 UTF-8 字符串，除非你明确说你的项目使用了遗产编码。说这个的方法是在.git/config文件中使用 i18n.commitencoding，如下所示：

[i18n]
  commitEncoding = ISO-8859-1

1. 使用上述设置创建的提交对象在其encoding标题中记录i18n.commitEncoding的值。这是为了帮助其他人以后再看。缺少此标头意味着提交日志消息以 UTF-8 编码。
2. git log ， git show ， git blame 和朋友们查看提交对象的encoding头，并尝试将日志消息重新编码为除非另有说明，否则为 UTF-8。您可以使用.git/config文件中的i18n.logOutputEncoding指定所需的输出编码，如下所示：

[i18n]
  logOutputEncoding = ISO-8859-1

1. 如果您没有此配置变量，则使用i18n.commitEncoding的值。

请注意，我们故意选择在提交以在提交对象级别强制使用 UTF-8 时不重新编写提交日志消息，因为重新编码为 UTF-8 不一定是可逆操作。

GIT

部分 git [1] 套件

git-log

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

名称

git-log - 显示提交日志

概要

git log [<options>] [<revision range>] [[--] <path>…]

描述

显示提交日志。

该命令采用适用于git rev-list命令的选项来控制显示的内容和方式，以及适用于git diff-*命令的选项，以控制每个提交引入的更改的显示方式。

OPTIONS

--follow 

继续列出重命名以外的文件历史记录（仅适用于单个文件）。

--no-decorate 

--decorate[=short|full|auto|no] 

打印出所有提交的引用名称。如果指定 _ 短 _，则引用名称前缀 refs / heads / ， refs / tags / 和 refs / remotes / 将不会打印。如果指定了 full ，将打印完整的引用名称（包括前缀）。如果指定了 auto ，那么如果输出到达终端，则 ref 名称显示为 short ，否则不显示 ref 名称。默认选项为 _ 短 _。

--decorate-refs=<pattern> 

--decorate-refs-exclude=<pattern> 

如果没有给出--decorate-refs，假装好像所有参考都被包括在内。对于每个候选人，如果它与--decorate-refs-exclude给出的任何模式匹配或者与--decorate-refs给出的任何模式都不匹配，请不要将其用于装饰。

--source 

打印出在每个提交到达的命令行上给出的引用名称。

--use-mailmap 

使用 mailmap 文件将作者和提交者名称以及电子邮件地址映射到规范的真实姓名和电子邮件地址。见 git-shortlog [1] 。

--full-diff 

如果没有此标志，git log -p ...将显示触摸指定路径的提交，并显示相同指定路径的差异。这样，就会显示完全差异，以便接触指定的路径。这意味着“< path> …”仅限制提交，并不限制这些提交的差异。

请注意，这会影响所有基于差异的输出类型，例如：那些由--stat等产生的

--log-size 

在每次提交的输出中包含“日志大小< number>”行，其中< number>是以字节为单位的提交消息的长度。旨在通过允许它们提前分配空间来加速从git log输出读取日志消息的工具。

-L <start>,<end>:<file> 

-L :<funcname>:<file> 

跟踪“< start>，< end>”给出的行范围的演变（或< file>）中的（或函数名称  regex< funcname>）。你可能不会给任何 pathpec  限制器。目前这仅限于从单个修订开始的步行，即，您可能只提供零个或一个正修订参数。您可以多次指定此选项。

<开始>和< end>可以采取以下形式之一：

• 数
  如果< start>或者< end>是一个数字，它指定一个绝对行号（行数从 1 开始）。
  
• /正则表达式/
  此表单将使用与给定 POSIX 正则表达式匹配的第一行。如果< start>是一个正则表达式，它将从前一个-L范围的末尾搜索，如果有的话，否则从文件的开头搜索。如果< start>是“^ / regex /”，它将从文件的开头搜索。如果< end>是一个正则表达式，它将从< start>给出的行开始搜索。
  

• offset 或-offset

• 这仅适用于< end>并将在< start>给出的行之前或之后指定行数。
  

如果给出“：< funcname>”代替< start>和<  end>，它是一个正则表达式，表示从匹配< funcname>的第一个 funcname 行到下一个 funcname  行的范围。 “：< funcname>”从上一个-L范围的末尾搜索（如果有的话），否则从文件的开头搜索。 “^：< funcname>”从文件的开头搜索。

<revision range> 

仅显示指定修订范围内的提交。当没有<修订范围>如果指定，则默认为HEAD（即导致当前提交的整个历史记录）。 origin..HEAD指定从当前提交可以访问的所有提交（即HEAD），但不是origin。有关拼写< revision range>的完整列表，请参阅 gitrevisions [7] 的 _ 指定范围 _ 部分。

[--] <path>… 

仅显示足以解释与指定路径匹配的文件的提交。有关详细信息和其他简化模式，请参见下面的 _ 历史简化 _。

当出现混淆时，路径可能需要以--作为前缀，以将它们与选项或修订范围分开。

提交限制

除了使用说明书中解释的特殊符号指定应列出的提交范围之外，还可以应用其他提交限制。

除非另有说明，否则使用更多选项通常会进一步限制输出（例如，--since=限制提交比更新，并将其与--grep=一起使用进一步限制其日志消息具有与匹配的行的提交）。

请注意，这些是在提交排序和格式化选项之前应用的，例如--reverse。

-<number> 

-n <number> 

--max-count=<number> 

限制要输出的提交数量。

--skip=<number> 

在开始显示提交输出之前，跳过 _ 编号 _ 提交。

--since=<date> 

--after=<date> 

显示比特定日期更新的提交。

--until=<date> 

--before=<date> 

显示超过特定日期的提交。

--author=<pattern> 

--committer=<pattern> 

将提交输出限制为具有与指定模式（正则表达式）匹配的作者/提交者标题行的输出。对于多个--author=，选择作者与任何给定模式匹配的提交（类似于多个--committer=）。

--grep-reflog=<pattern> 

将提交输出限制为具有与指定模式（正则表达式）匹配的 reflog 条目的输出。如果有多个--grep-reflog，则选择其 reflog 消息与任何给定模式匹配的提交。除非正在使用--walk-reflogs，否则使用此选项是错误的。

--grep=<pattern> 

将提交输出限制为具有与指定模式（正则表达式）匹配的日志消息的输出。如果有多个--grep=，则会选择其消息与任何给定模式匹配的提交（但请参见--all-match）。

当--show-notes生效时，来自注释的消息将被匹配，就像它是日志消息的一部分一样。

--all-match 

将提交输出限制为匹配所有给定--grep的输出，而不是匹配至少一个的输出。

--invert-grep 

将提交输出限制为具有与--grep=指定的模式不匹配的日志消息的输出。

-i 

--regexp-ignore-case 

匹配正则表达式限制模式而不考虑字母大小写。

--basic-regexp 

将限制模式视为基本正则表达式;这是默认值。

-E 

--extended-regexp 

考虑限制模式是扩展正则表达式而不是默认的基本正则表达式。

-F 

--fixed-strings 

将限制模式视为固定字符串（不要将模式解释为正则表达式）。

-P 

--perl-regexp 

将限制模式视为与 Perl 兼容的正则表达式。

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

--remove-empty 

当给定路径从树中消失时停止。

--merges 

仅打印合并提交。这与--min-parents=2完全相同。

--no-merges 

不要打印具有多个父级的提交。这与--max-parents=1完全相同。

--min-parents=<number> 

--max-parents=<number> 

--no-min-parents 

--no-max-parents 

仅显示至少（或最多）许多父提交的提交。特别是，--max-parents=1与--no-merges相同，--min-parents=2与--merges相同。 --max-parents=0给出所有 root 提交和--min-parents=3所有章鱼合并。

--no-min-parents和--no-max-parents再次重置这些限制（无限制）。等效形式是--min-parents=0（任何提交具有 0 或更多父母）和--max-parents=-1（负数表示无上限）。

--first-parent 

在看到合并提交时，仅遵循第一个父提交。在查看特定主题分支的演变时，此选项可以提供更好的概述，因为合并到主题分支往往只是关于不时调整到更新的上游，并且此选项允许您忽略引入的单个提交通过这样的合并你的历史。不能与–bisect 结合使用。

--not 

反转所有后续修订说明符的 ^ 前缀（或缺少）的含义，直到下一个--not。

--all 

假设refs/中的所有引用与HEAD一起在命令行中列为 < commit> 。

--branches[=<pattern>] 

假设refs/heads中的所有引用都在命令行中列为 < commit> 。如果 < pattern> 给出，将分支限制为匹配给定 shell glob 的分支。如果模式缺乏 _？最后暗示 _， * 或 [， / * 。

--tags[=<pattern>] 

假设refs/tags中的所有引用都在命令行中列为 < commit> 。如果 _< pattern>给出了 _，将标签限制为与给定 shell glob 匹配的标签。如果模式缺乏 _？最后暗示 _， * 或 [， / * 。

--remotes[=<pattern>] 

假设refs/remotes中的所有引用都在命令行中列为 < commit> 。如果 _< pattern>给出了 _，将远程跟踪分支限制为与给定 shell glob 匹配的分支。如果模式缺乏 _？最后暗示 _， * 或 [， / * 。

--glob=<glob-pattern> 

假设所有的 refs 匹配 shell glob < glob-pattern> 在命令行中列为 < commit> 。领先的 refs / 会在缺失时自动添加。如果模式缺乏 _？最后暗示 _， * 或 [， / * 。

--exclude=<glob-pattern> 

不包括引用匹配 < glob-pattern> 否则会考虑下一个--all，--branches，--tags，--remotes或--glob。重复此选项会累积排除模式，直至下一个--all，--branches，--tags，--remotes或--glob选项（其他选项或参数不会清除累积模式）。

当应用于--branches，--tags或--remotes时，给出的模式不应以refs/heads，refs/tags或refs/remotes开始，并且当应用于--glob时，它们必须以refs/开头]或--all。如果打算使用尾随 / * ，则必须明确给出。

--reflog 

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