Git 中文参考(三)(1)

本文涉及的产品
全局流量管理 GTM,标准版 1个月
日志服务 SLS,月写入数据量 50GB 1个月
云解析 DNS,旗舰版 1个月
简介: Git 中文参考(三)

git-mergetool

原文: git-scm.com/docs/git-mergetool

名称

git-mergetool - 运行合并冲突解决工具来解决合并冲突

概要

git mergetool [--tool=<tool>] [-y | --[no-]prompt] [<file>…]

描述

使用git mergetool运行多个合并实用程序之一来解决合并冲突。它通常在 git merge 之后运行。

如果一个或多个< file>给出参数,将运行合并工具程序以解决每个文件的差异(跳过那些没有冲突的文件)。指定目录将包括该路径中的所有未解析文件。如果没有< file>如果指定了名称, git mergetool 将在每个具有合并冲突的文件上运行合并工具程序。

OPTIONS

-t <tool> 
--tool=<tool> 

使用< tool>指定的合并解析程序。有效值包括 emerge,gvimdiff,kdiff3,meld,vimdiff 和 tortoisemerge。运行git mergetool --tool-help以获取有效< tool>的列表设置。

如果未指定合并解析程序, git mergetool 将使用配置变量merge.tool。如果未设置配置变量merge.toolgit mergetool 将选择合适的默认值。

您可以通过设置配置变量mergetool..path显式提供工具的完整路径。例如,您可以通过设置mergetool.kdiff3.path配置 kdiff3 的绝对路径。否则, git mergetool 假定该工具在 PATH 中可用。

可以通过指定要在配置变量mergetool..cmd中调用的命令行来自定义 git mergetool 来运行备用程序,而不是运行其中一个已知的合并工具程序。

当使用此工具调用 git mergetool 时(通过-t--tool选项或merge.tool配置变量),将在$BASE设置为名称的情况下调用配置的命令行包含合并公共基础的临时文件(如果有); $LOCAL设置为包含当前分支上文件内容的临时文件的名称; $REMOTE设置为包含要合并的文件内容的临时文件的名称,$MERGED设置为合并工具应写入合并解析结果的文件的名称。

如果自定义合并工具正确指示合并解析及其退出代码成功,则配置变量mergetool..trustExitCode可以设置为true。否则, git mergetool 将提示用户在自定义工具退出后指示分辨率是否成功。

--tool-help 

打印可能与--tool一起使用的合并工具列表。

-y 
--no-prompt 

在每次调用合并解析程序之前不要提示。如果使用--tool选项或merge.tool配置变量显式指定了合并解析程序,则这是默认值。

--prompt 

在每次调用合并解析程序之前提示,以便为用户提供跳过路径的机会。

-g 
--gui 

当使用-g--gui选项调用 git-mergetool 时,将从配置的merge.guitool变量而不是merge.tool中读取默认合并工具。

--no-gui 

这将覆盖先前的-g--gui设置,并且将从配置的merge.tool变量中读取默认合并工具。

-O<orderfile> 

按照< orderfile>中指定的顺序处理文件,每行有一个 shell glob 模式。这会覆盖diff.orderFile配置变量(参见 git-config [1] )。要取消diff.orderFile,请使用-O/dev/null

临时文件

git mergetool在解析合并时创建*.orig备份文件。一旦文件合并并且其git mergetool会话已完成,可以安全地删除它们。

mergetool.keepBackup配置变量设置为false会导致git mergetool在文件成功合并时自动删除备份。

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/headsrefs/tagsrefs/remotes开始,并且当应用于--glob时,它们必须以refs/开头]或--all。如果打算使用尾随 / * ,则必须明确给出。

--reflog 

假设 reflog 所提到的所有对象都在命令行中列为

--single-worktree 

默认情况下,当有多个工作树时,将通过以下选项检查所有工作树(参见 git-worktree [1] ):--all--reflog--indexed-objects。此选项强制它们仅检查当前工作树。

--ignore-missing 

在输入中看到无效的对象名称时,假装没有给出错误的输入。

--bisect 

假设好像已经列出了错误的二分法refs/bisect/bad并且好像它后面跟着--not并且良好的二分法在命令行上引用了refs/bisect/good-*。不能与–first-parent 结合使用。

--stdin 

除了 _< commit>在命令行中列出 _,从标准输入中读取它们。如果看到--分隔符,请停止读取提交并开始读取路径以限制结果。

--cherry-mark 

--cherry-pick(见下文)相同,但标记等效提交与=而不是省略它们,而与+不等价。

--cherry-pick 

当提交集受限于对称差异时,省略任何引用与“另一方”上的另一个提交相同的更改的提交。

例如,如果您有两个分支,AB,通常只在一侧列出所有提交的方法是使用--left-right(请参阅下面--left-right选项说明中的示例) 。但是,它显示了从另一个分支中挑选出来的提交(例如,“b 上的第 3 个”可以从分支 A 中挑选出来)。使用此选项,将从输出中排除此类提交对。

--left-only 
--right-only 

列表仅在对称差异的相应侧提交,即仅在那些将被标记为<的那些。 > --left-right

例如,--cherry-pick --right-only A...B省略了来自B的提交,这些提交位于A中,或者补丁等效于A中的提交。换句话说,这列出了git cherry A B+提交。更确切地说,--cherry-pick --right-only --no-merges给出了确切的列表。

--cherry 

--right-only --cherry-mark --no-merges的同义词;有用的是将输出限制在我们这一侧的提交中,并用git log --cherry upstream...mybranch标记已应用于分叉历史记录另一侧的输出,类似于git cherry upstream mybranch

-g 
--walk-reflogs 

而不是走提交祖先链,将 reflog 条目从最新的条目转到较旧的条目。使用此选项时,您无法指定要排除的提交(即 ^ commitcommit1…commit2commit1 … commit2 表示法不能用过的)。

使用oneline以外的--pretty格式(出于显而易见的原因),这会导致输出从 reflog 中获取两行额外的信息。输出中的 reflog 指示符可能显示为ref@{Nth}(其中Nth是 reflog 中的反向时间顺序索引)或ref@{timestamp}(带有该条目的时间戳),具体取决于以下几条规则:

  1. 如果起始点指定为ref@{Nth},则显示索引格式。
  2. 如果起始点指定为ref@{now},则显示时间戳格式。
  3. 如果两者均未使用,但在命令行中给出了--date,则以--date请求的格式显示时间戳。
  4. 否则,显示索引格式。

--pretty=oneline下,提交消息在同一行上以此信息为前缀。此选项不能与--reverse组合使用。另见 git-reflog [1]

--merge 

合并失败后,show refs 触摸有冲突的文件,并且在所有头上都不存在要合并的文件。

--boundary 

输出排除边界提交。边界提交以-为前缀。

历史简化

有时您只对历史记录的某些部分感兴趣,例如修改特定< path>的提交。但 _ 历史简化 _ 有两个部分,一部分是选择提交,另一部分是如何做,因为有各种策略来简化历史。

以下选项选择要显示的提交:

<paths> 

提交修改给定的<路径>被选中。

--simplify-by-decoration 

选择某些分支或标记引用的提交。

请注意,可以显示额外的提交以提供有意义的历史记录。

以下选项会影响简化的执行方式:

Default mode

将历史简化为最简单的历史,解释树的最终状态。最简单的,因为如果最终结果相同(即合并具有相同内容的分支),它会修剪一些侧分支

--full-history 

与默认模式相同,但不修剪某些历史记录。

--dense 

仅显示选定的提交,并显示一些具有有意义的历史记录。

--sparse 

显示简化历史记录中的所有提交。

--simplify-merges 

--full-history的附加选项,用于从生成的历史记录中删除一些不必要的合并,因为没有选定的提交有助于此合并。

--ancestry-path 

当给出一系列要显示的提交时(例如 commit1…commit2commit2 ^ commit1 ),只显示直接存在于 commit1 之间的祖先链上的提交]和 commit2 ,即提交既是 commit1 的后代,又是 commit2 的祖先。

下面是更详细的解释。

假设您将foo指定为< paths>。我们将调用修改foo!TREESAME 的提交,以及其余的 TREESAME。 (在foo的差异滤波中,它们分别看起来不同且相等。)

在下文中,我们将始终参考相同的示例历史记录来说明简化设置之间的差异。我们假设您正在过滤此提交图中的文件foo

.-A---M---N---O---P---Q
   /     /   /   /   /   /
  I     B   C   D   E   Y
   \   /   /   /   /   /
    `-------------'   X

历史 A — Q 的水平线被视为每次合并的第一个父级。提交是:

  • I是初始提交,其中foo存在内容“asdf”,文件quux存在,内容为“quux”。初始提交与空树进行比较,因此I是!TREESAME。
  • A中,foo仅包含“foo”。
  • B包含与A相同的更改。它的合并M是微不足道的,因此对所有父母都是 TREESAME。
  • C不会更改foo,但是它的合并N会将其更改为“foobar”,因此它不是任何父级的 TREESAME。
  • Dfoo设置为“baz”。它的合并OND的字符串组合成“foobarbaz”;即,它不是任何父母的 TREESAME。
  • Equux更改为“xyzzy”,其合并P将字符串组合为“quux xyzzy”。 P是 TREESAME 到O,但不是E
  • X是一个独立的根提交,它添加了一个新文件sideY修改了它。 Y是 TREESAME 到X。它的合并Qside添加到PQ将 TREESAME 添加到P,但不添加到Y

rev-list根据是否使用--full-history和/或父改写(通过--parents--children)来回溯历史记录,包括或排除提交。可以使用以下设置。

Default mode 

如果对任何父母不是 TREESAME,则包含提交(尽管可以更改,请参阅下面的--sparse)。如果提交是合并,并且它是一个父级的 TREESAME,则只关注该父级。 (即使有几个 TREESAME 父母,也只能跟随他们中的一个。)否则,请跟随所有父母。

这导致:

.-A---N---O
   /     /   /
  I---------D

请注意,仅遵循 TREESAME 父级的规则(如果有的话)将完全从考虑中删除BC被认为是通过N,但是是 TREESAME。 Root 提交与空树进行比较,因此I是!TREESAME。

父/子关系仅在--parents中可见,但这不会影响在默认模式下选择的提交,因此我们显示了父行。

--full-history without parent rewriting 

此模式与默认值在一点上不同:始终跟随合并的所有父项,即使它是其中一个的 TREESAME。即使合并的多个方面包含了包含的提交,这并不意味着合并本身就是!在这个例子中,我们得到了

I  A  B  N  D  O  P  Q

M被排除在外,因为对父母双方都是 TREESAME。 ECB都走了,但只有B是!TREESAME,所以没有出现。

请注意,如果没有父改写,就不可能谈论提交之间的父/子关系,因此我们将它们显示为断开连接。

--full-history with parent rewriting 

只有普通提交才包括在内!TREESAME(虽然可以更改,但请参见下面的--sparse)。

合并始终包括在内。但是,它们的父列表会被重写:沿着每个父项删除不包含在其中的提交。这导致了

.-A---M---N---O---P---Q
   /     /   /   /   /
  I     B   /   D   /
   \   /   /   /   /
    `-------------'

--full-history比较而不重写上述内容。请注意,E被删除,因为它是 TREESAME,但是 P 的父列表被重写为包含E的父ICNXYQ也发生了同样的情况。

除上述设置外,您还可以更改 TREESAME 是否影响包含:

--dense 

如果他们不是任何父母的 TREESAME,则包括走路的提交。

--sparse 

包括所有步行的提交。

请注意,如果没有--full-history,这仍然可以简化合并:如果其中一个父项是 TREESAME,我们只遵循那个,所以合并的其他方面永远不会走。

--simplify-merges 

首先,以与父改写的--full-history相同的方式构建历史图(参见上文)。

然后根据以下规则将每个提交C简化为最终历史记录中的替换C'

  • C'设置为C
  • C'的每个父P替换为其简化P'。在这个过程中,删除作为其他父母或祖先的祖先的父母将 TREESAME 提交到空树,并删除重复项,但要注意永远不要删除我们所有父母的 TREESAME。
  • 如果在此父级重写之后,C'是根或合并提交(具有零或> 1 父级),边界提交或!TREESAME,它仍然存在。否则,它将替换为其唯一的父级。

通过与--full-history与父重写进行比较,可以最好地显示出这种效果。这个例子变成了:

.-A---M---N---O
   /     /       /
  I     B       D
   \   /       /
    `---------'

注意NPQ--full-history的主要差异:

  • N的父列表删除了I,因为它是另一个父M的祖先。仍然,N仍然是因为它是!TREESAME。
  • P的父列表同样删除了IP然后被完全删除,因为它有一个父母并且是 TREESAME。
  • Q的父列表将Y简化为X。然后删除X,因为它是 TREESAME 根。 Q然后被完全删除,因为它有一个父母并且是 TREESAME。

最后,还有第五种简化模式:

--ancestry-path 

将显示的提交限制为直接在给定提交范围中的“from”和“to”提交之间的祖先链上的提交。即只显示“to”提交的祖先和“from”提交的后代的提交。

作为示例用例,请考虑以下提交历史记录:

D---E-------F
     /     \       \
    B---C---G---H---I---J
   /                     \
  A-------K---------------L--M

常规 D…M 计算作为M的祖先的提交集,但不包括作为D的祖先的提交。这对于从D以来导致M的历史发生了什么是有用的,因为“D中没有M具有什么M”。这个例子中的结果将是所有提交,除了AB(当然还有D本身)。

当我们想知道M中的提交被D引入的 bug 污染并需要修复时,我们可能只想查看实际上 D…M 的子集D的后代,即排除CK。这正是--ancestry-path选项的作用。应用于 D…M 范围,它会导致:

E-------F
     \       \
      G---H---I---J
             \
        L--M

--simplify-by-decoration选项允许您通过省略未由标记引用的提交来仅查看历史拓扑的大图。如果(1)它们被标记引用,或(2)它们改变命令行上给出的路径的内容,则提交被标记为!TREESAME(换句话说,保持在上述历史简化规则之后)。所有其他提交都标记为 TREESAME(可以简化)。


Git 中文参考(三)(2)https://developer.aliyun.com/article/1565821

相关文章
|
1月前
|
机器学习/深度学习 Shell 网络安全
【Git】Git 命令参考手册
Git 命令参考手册的扩展部分,包含了从基础操作到高级功能的全面讲解。
44 3
|
5月前
|
监控 程序员 开发工具
如何规范Git提交-参考阿里云开发者社区
这篇文章分享了如何规范Git提交,介绍了commit message的格式规范,并通过webhook监控机制来确保代码提交的规范性,从而提高研发效率和代码维护质量。
|
6月前
|
存储 缓存 网络安全
Git 中文参考(一)(8)
Git 中文参考(一)
60 2
|
6月前
|
存储 网络安全 开发工具
Git 中文参考(一)(7)
Git 中文参考(一)
68 2
|
6月前
|
存储 算法 Java
Git 中文参考(一)(6)
Git 中文参考(一)
59 2
|
6月前
|
存储 Shell 开发工具
Git 中文参考(一)(5)
Git 中文参考(一)
46 2
|
6月前
|
存储 开发工具 git
Git 中文参考(一)(4)
Git 中文参考(一)
47 2
|
6月前
|
存储 安全 开发工具
Git 中文参考(一)(3)
Git 中文参考(一)
31 2
|
6月前
|
存储 Shell 开发工具
Git 中文参考(一)(2)
Git 中文参考(一)
55 2
|
6月前
|
存储 人工智能 开发工具
Git 中文参考(五)(9)
Git 中文参考(五)
147 2