Git 中文参考（四）（6）https://developer.aliyun.com/article/1565834
映射作者
.mailmap功能用于将短名中的同一个人合并到一起，其中他们的姓名和/或电子邮件地址拼写不同。
如果文件.mailmap存在于存储库的顶层，或者位于 mailmap.file 或 mailmap.blob 配置选项所指向的位置，则它用于将作者和提交者名称以及电子邮件地址映射到规范的真实姓名和电子邮件地址。
在简单形式中，文件中的每一行都包含作者的规范实名，空格和提交中使用的电子邮件地址（由 < 和 > 括起来）映射到名称。例如：
Proper Name <commit@email.xx>
更复杂的形式是：
<proper@email.xx> <commit@email.xx>
允许 mailmap 仅替换提交的电子邮件部分，并且：
Proper Name <proper@email.xx> <commit@email.xx>
它允许 mailmap 替换与指定的提交电子邮件地址匹配的提交的名称和电子邮件，并且：
Proper Name <proper@email.xx> Commit Name <commit@email.xx>
它允许 mailmap 替换与指定的提交名称和电子邮件地址匹配的提交的名称和电子邮件。
示例 1：您的历史记录包含两位作者 Jane 和 Joe 的提交，其名称以多种形式出现在存储库中：
Joe Developer <joe@example.com> Joe R. Developer <joe@example.com> Jane Doe <jane@example.com> Jane Doe <jane@laptop.(none)> Jane D. <jane@desktop.(none)>
现在假设 Joe 希望他的中间名最初使用，而 Jane 更喜欢她的姓氏完全拼写出来。一个合适的.mailmap文件看起来像：
Jane Doe <jane@desktop.(none)> Joe R. Developer <joe@example.com>
注意如何不需要的条目，因为该作者的真实姓名已经正确。
示例 2：您的存储库包含以下作者的提交：
nick1 <bugs@company.xx> nick2 <bugs@company.xx> nick2 <nick2@company.xx> santa <me@company.xx> claus <me@company.xx> CTO <cto@coompany.xx>
然后你可能想要一个看起来像这样的.mailmap文件：
<cto@company.xx> <cto@coompany.xx> Some Dude <some@dude.xx> nick1 <bugs@company.xx> Other Author <other@author.xx> nick2 <bugs@company.xx> Other Author <other@author.xx> <nick2@company.xx> Santa Claus <santa.claus@northpole.xx> <me@company.xx>
将哈希 ＃ 用于自己的行或电子邮件地址之后的注释。
GIT
部分 git [1] 套件
git-describe
名称
git-describe - 根据可用的 ref 给对象一个人类可读的名称
概要
git describe [--all] [--tags] [--contains] [--abbrev=<n>] [<commit-ish>…] git describe [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>] git describe <blob>
描述
该命令查找可从提交访问的最新标记。如果标记指向提交，则仅显示标记。否则，它将标记名称后缀为标记对象顶部的附加提交数和最近提交的缩写对象名称。结果是一个“人类可读”的对象名称，它也可用于标识对其他 git 命令的提交。
默认情况下（不带–all 或–tags）git describe仅显示带注释的标签。有关创建带注释标签的更多信息，请参阅 git-tag [1] 的-a 和-s 选项。
如果给定对象引用 blob，则将其描述为:，以便可以在中的处找到 blob，它本身描述了在反向修订中出现此 blob 的第一次提交从 HEAD 步行。
OPTIONS
<commit-ish>…
要描述的 Commit-ish 对象名称。如果省略，则默认为 HEAD。
--dirty[=<mark>]
--broken[=<mark>]
描述工作树的状态。当工作树与 HEAD 匹配时，输出与“git describe HEAD”相同。如果工作树具有本地修改，则附加“-dirty”。如果存储库已损坏并且 Git 无法确定是否存在本地修改，则 Git 将出错，除非给出“–broken”，而后缀为“-broken”。
--all
不要只使用带注释的标签，而是使用refs/命名空间中的任何引用。此选项可以匹配任何已知分支，远程跟踪分支或轻量级标记。
--tags
不使用带注释的标签，而是使用refs/tags命名空间中的任何标签。此选项可以匹配轻量级（非注释）标记。
--contains
而不是找到提交之前的标记，找到提交后出现的标记，从而包含它。自动暗示–tags。
--abbrev=<n>
不使用默认的 7 个十六进制数字作为缩写对象名称，而是使用< n>数字，或形成唯一对象名称所需的数字。 < n> 0 将禁止长格式，仅显示最接近的标记。
--candidates=<n>
而不是仅仅考虑 10 个最近的标签作为描述输入提交的候选者，而是考虑到< n>。候选人。增加< n>超过 10 将需要稍长但可能产生更准确的结果。 < n>为 0 将导致仅输出完全匹配。
--exact-match
仅输出完全匹配（标记直接引用提供的提交）。这是–candidates = 0 的同义词。
--debug
详细显示有关用于标准错误的搜索策略的信息。标签名称仍将打印到标准输出。
--long
即使与标记匹配，也始终输出长格式（标记，提交数和缩写提交名称）。当您想要在“describe”输出中查看提交对象名称的某些部分时，这很有用，即使有问题的提交恰好是标记版本。它不会仅仅发出标记名称，而是将这样的提交描述为 v1.2-0-gdeadbee（自标记 v1.2 以来第 0 次提交指向对象 deadbee …）。
--match <pattern>
仅考虑与给定glob(7)模式匹配的标记，不包括“refs / tags /”前缀。如果与--all一起使用，它还会考虑与模式匹配的本地分支和远程跟踪引用，分别排除“refs / heads /”和“refs / remotes /”前缀;从不考虑其他类型的参考。如果多次给出，将累积模式列表，并且将考虑匹配任何模式的标签。使用--no-match清除和重置模式列表。
--exclude <pattern>
不要考虑与给定glob(7)模式匹配的标记，不包括“refs / tags /”前缀。如果与--all一起使用，它也不会考虑与模式匹配的本地分支和远程跟踪引用，分别排除“refs / heads /”和“refs / remotes /”前缀;从不考虑其他类型的参考。如果多次给出，则将累积模式列表，并且将排除匹配任何模式的标签。与–match 结合使用时，如果标记与至少一个匹配模式匹配且与任何–exclude 模式不匹配，则会考虑使用该标记。使用--no-exclude清除和重置模式列表。
--always
将唯一缩写的提交对象显示为后备。
--first-parent
在看到合并提交时，仅遵循第一个父提交。当您希望不匹配目标提交历史记录中合并的分支上的标记时，这非常有用。
例子
有了类似 git.git 当前树的东西，我得到：
[torvalds@g5 git]$ git describe parent v1.0.4-14-g2414721
即我的“父”分支的当前头部基于 v1.0.4，但由于它上面有一些提交，因此 describe 添加了额外提交的数量（“14”）和提交的缩写对象名称本身（“2414721”）在最后。
附加提交的数量是“git log v1.0.4…parent”显示的提交数。哈希后缀是父项提示提交的“-g”+ 7-char 缩写（即2414721b194453f058079d897d13c4e377f92dc6）。 “g”前缀代表“git”，用于根据管理软件的 SCM 描述软件版本。这在人们可能使用不同 SCM 的环境中很有用。
在标签名称上执行 git describe 只会显示标签名称：
[torvalds@g5 git]$ git describe v1.0.4 v1.0.4
使用–all，该命令可以使用分支头作为引用，因此输出也显示引用路径：
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5² tags/v1.0.0-21-g975b
[torvalds@g5 git]$ git describe --all --abbrev=4 HEAD^ heads/lt/describe-7-g975b
将–abbrev 设置为 0，该命令可用于查找最接近的标记名，不带任何后缀：
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5² tags/v1.0.0
请注意，如果今天键入这些命令，您获得的后缀可能比 Linus 在运行这些命令时看到的更长，因为您的 Git 存储库可能有新的提交，其对象名称以 975b 开头，当时不存在，并且“ - g975b“单独的后缀可能不足以消除这些提交的歧义。
搜索策略
对于每个提交的提交， git describe 将首先查找标记该提交的标记。带注释的标签将始终优先于轻量级标签，具有较新日期的标签将始终优先于具有较旧日期的标签。如果找到完全匹配，将输出其名称并停止搜索。
如果未找到完全匹配， git describe 将返回提交历史记录以找到已标记的祖先提交。祖先的标记将与输入 commit-ish 的 SHA-1 的缩写一起输出。如果指定了--first-parent，则 walk 将仅考虑每个提交的第一个父级。
如果在步行期间发现多个标签，则将选择并输出具有与输入 commit-ish 不同的最少提交的标签。这里提交的最小不同定义为git log tag..input显示的提交数量将是可能的最小提交数量。
BUGS
无法描述树对象以及不指向提交的标记对象。在描述 blob 时，忽略指向 blob 的轻量级标记，但 blob 仍被描述为< committ-ish>：< path>尽管轻量级标签是有利的。
GIT
部分 git [1] 套件
git-apply
名称
git-apply - 将补丁应用于文件和/或索引
概要
git apply [--stat] [--numstat] [--summary] [--check] [--index | --intent-to-add] [--3way] [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse] [--allow-binary-replacement | --binary] [--reject] [-z] [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached] [--ignore-space-change | --ignore-whitespace] [--whitespace=(nowarn|warn|fix|error|error-all)] [--exclude=<path>] [--include=<path>] [--directory=<root>] [--verbose] [--unsafe-paths] [<patch>…]
描述
读取提供的 diff 输出（即“补丁”）并将其应用于文件。从存储库中的子目录运行时，将忽略目录外的修补路径。使用--index选项，补丁也会应用于索引，而使用--cached选项，补丁仅应用于索引。如果没有这些选项，该命令仅将补丁应用于文件，并且不要求它们位于 Git 存储库中。
此命令应用修补程序但不创建提交。使用 git-am [1] 从 git-format-patch [1] 生成的补丁创建提交和/或通过电子邮件接收。
OPTIONS
<patch>…
从中读取补丁的文件。 - 可用于从标准输入读取。
--stat
而不是应用补丁，输入 diffstat 作为输入。关闭“申请”。
--numstat
与--stat类似，但以十进制表示法显示添加和删除的行数，不使用缩写表示路径名，以使其更加机器友好。对于二进制文件，输出两个-而不是0 0。关闭“申请”。
--summary
而不是应用补丁，输出从 git diff 扩展头获取的信息的精简摘要，例如创建，重命名和模式更改。关闭“申请”。
--check
而不是应用修补程序，查看修补程序是否适用于当前工作树和/或索引文件并检测错误。关闭“申请”。
--index
当--check生效时，或者应用补丁时（默认情况下，如果没有禁用它的选项生效），请确保补丁适用于当前索引文件记录的内容。如果要在工作树中修补的文件不是最新的，则会将其标记为错误。此标志还会导致更新索引文件。
--cached
在不触及工作树的情况下应用补丁。而是使用缓存数据，应用补丁，并将结果存储在索引中，而不使用工作树。这意味着--index。
--intent-to-add
仅将补丁应用于工作树时，请稍后将新文件标记为添加到索引中（请参阅 git-add [1] 中的--intent-to-add选项）。除非在 Git 存储库中运行并且未指定--index，否则将忽略此选项。请注意，--index可能隐含在--cached或--3way等其他选项中。
-3
--3way
当补丁不能干净地应用时，如果补丁记录了应该应用的 blob 的身份，则回退到三向合并，并且我们在本地可以使用这些 blob，可能会将冲突标记留在工作树中的文件中供用户解决。此选项隐含--index选项，与--reject和--cached选项不兼容。
--build-fake-ancestor=<file>
较新的 git diff 输出为每个 blob 嵌入了 _ 索引信息 _，以帮助识别该补丁适用的原始版本。给出此标志，并且如果 Blob 的原始版本在本地可用，则构建包含这些 blob 的临时索引。
遇到纯模式更改（没有索引信息）时，将从当前索引读取信息。
-R
--reverse
反向应用补丁。
--reject
对于原子性，默认情况下 git apply 会使整个补丁失败，并且当某些黑客不适用时不会触及工作树。此选项使其应用适用的修补程序部分，并将拒绝的数据保留在相应的* .rej 文件中。
-z
当给出--numstat时，不要使用路径名，而是使用 NUL 终止的机器可读格式。
如果没有此选项，则会引用具有“异常”字符的路径名，如配置变量core.quotePath所述（参见 git-config [1] ）。
-p<n>
删除< n>传统差异路径的前导路径组件（由斜线分隔）。例如，使用-p2，针对a/dir/file的补丁将直接应用于file。默认值为 1。
-C<n>
确保至少< n>周围环境的线在每次更改之前和之后匹配。当存在较少的周围环境线时，它们都必须匹配。默认情况下，不会忽略任何上下文。
--unidiff-zero
默认情况下， git apply 期望应用的补丁是具有至少一行上下文的统一差异。这提供了良好的安全措施，但在应用--unified=0生成的差异时会出现故障。要绕过这些检查，请使用--unidiff-zero。
请注意，由于上述原因，不鼓励使用无上下文补丁。
--apply
如果您使用上面标记为“关闭 _ 应用 _”的任何选项， git apply 将读取并输出所请求的信息，而不实际应用该补丁。在这些标志之后给这个标志也应用补丁。
--no-add
应用补丁时，忽略补丁所做的添加。这可用于通过首先在它们上运行 diff 并使用此选项应用结果来提取两个文件之间的公共部分，这将应用删除部分但不应用添加部分。
--allow-binary-replacement
--binary
从历史上看，我们不允许在没有用户明确许可的情况下应用二进制补丁，并且这个标志就是这样做的。目前我们总是允许二进制补丁应用，所以这是一个无操作。
--exclude=<path-pattern>
不要对与给定路径模式匹配的文件应用更改。在导入要在其中排除某些文件或目录的补丁集时，这非常有用。
--include=<path-pattern>
将更改应用于与给定路径模式匹配的文件。在导入要包含某些文件或目录的补丁集时，这非常有用。
使用--exclude和--include模式时，将按照它们在命令行中出现的顺序检查它们，第一个匹配项确定是否使用了每个路径的补丁。如果命令行上没有包含模式，则默认情况下使用与任何包含/排除模式不匹配的路径的修补程序，如果存在任何包含模式，则忽略该修补程序。
--ignore-space-change
--ignore-whitespace
应用修补程序时，如有必要，请忽略上下文行中的空白更改。上下文行将保留其空白，并且无论--whitespace选项的值如何，它们都不会进行空白修复。不过，新线仍将被修复。
--whitespace=<action>
应用修补程序时，检测具有空白错误的新行或已修改行。什么被认为是空白错误由core.whitespace配置控制。默认情况下，尾随空格（包括仅由空格组成的行）和在行的初始缩进内紧跟着制表符的空格字符被视为空格错误。
默认情况下，该命令会输出警告消息，但会应用修补程序。当git-apply用于统计而不应用补丁时，默认为nowarn。
您可以使用不同的值来控制此行为：
nowarn关闭尾随空白警告。warn输出一些此类错误的警告，但按原样应用补丁（默认）。fix输出一些此类错误的警告，并在修复它们之后应用补丁（strip是一个同义词—用于考虑仅将空白字符作为错误尾随的工具，并且修复涉及 _ 剥离 _ 他们，但现代 Gits 做得更多）。error输出一些此类错误的警告，并拒绝应用补丁。error-all类似于error，但显示所有错误。
--inaccurate-eof
在某些情况下， diff 的某些版本无法在文件末尾正确检测到丢失的换行符。因此，由 diff 程序创建的补丁不能正确记录不完整的行。此选项通过解决此错误添加了对应用此类修补程序的支持。
-v
--verbose
向 stderr 报告进度。默认情况下，仅打印有关当前正在应用的修补程序的消息。此选项将导致报告其他信息。
--recount
不要信任 hunk 标头中的行数，而是通过检查补丁来推断它们（例如，在编辑补丁之后没有适当地调整 hunk 标头）。
--directory=<root>
前置< root>到所有文件名。如果还传递了“-p”参数，则在添加新根之前应用它。
例如，通过运行git apply --directory=modules/git-gui，可以将关于更新a/git-gui.sh到b/git-gui.sh的补丁应用于工作树modules/git-gui/git-gui.sh中的文件。
--unsafe-paths
默认情况下，影响工作区域外的补丁（Git 控制的工作树或当“git apply”用作 GNU 补丁的替代时的当前工作目录）被拒绝为错误（或恶作剧）。
当git apply用作“更好的 GNU 补丁”时，用户可以通过--unsafe-paths选项来覆盖此安全检查。使用--index或--cached时，此选项无效。
组态
apply.ignoreWhitespace
如果要在默认情况下忽略空白更改，请设置为 _ 更改 _。如果您希望空格中的更改很重要，请设置为以下之一：no，none，never，false。
apply.whitespace
如果没有从命令行给出--whitespace标志，则此配置项将用作默认值。
子模
如果补丁包含对子模块的任何更改，则 git apply 会按如下方式处理这些更改。
如果指定--index（显式或隐式），则子模块提交必须与要应用的修补程序的索引完全匹配。如果检出任何子模块，则完全忽略这些检出，即，它们不需要是最新的或清洁的，并且它们不会被更新。
如果未指定--index，则忽略补丁中的子模块提交，并且仅检查相应子目录的缺失或存在，并且（如果可能）更新。
也可以看看
GIT
部分 git [1] 套件
git-cherry-pick
名称
git-cherry-pick - 应用某些现有提交引入的更改
概要
git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] [-S[<keyid>]] <commit>… git cherry-pick --continue git cherry-pick --quit git cherry-pick --abort
描述
给定一个或多个现有提交，应用每个引入的更改，为每个提交记录一个新提交。这需要您的工作树是干净的（没有 HEAD 提交的修改）。
如果不明显如何应用更改，则会发生以下情况：
- 当前分支和
HEAD指针保持在最后一次成功提交。 CHERRY_PICK_HEADref 设置为指向引入难以应用的更改的提交。- 干净地应用更改的路径在索引文件和工作树中都会更新。
- 对于冲突路径，索引文件最多可记录三个版本，如 git-merge [1] 的“TRUE MERGE”部分所述。工作树文件将包含由通常的冲突标记
<<<<<<<和>>>>>>>括起来的冲突的描述。 - 没有进行其他修改。
有关解决此类冲突的一些提示，请参阅 git-merge [1] 。
OPTIONS
<commit>…
承诺挑选樱桃。有关拼写提交方法的更完整列表，请参阅 gitrevisions [7] 。可以传递提交集，但默认情况下不执行遍历，就像指定了--no-walk选项一样，请参阅 git-rev-list [1] 。请注意，指定范围会将所有< commit> …参数提供给单个修订版步行（请参阅后面使用 maint master…next 的示例）。
-e
--edit
使用此选项， git cherry-pick 将允许您在提交之前编辑提交消息。
-x
记录提交时，在原始提交消息中附加一行“（从提交中挑选出来的樱桃）”，以指示从哪个提交中挑选出这个更改。这只适用于没有冲突的樱桃选择。如果您从私人分支机构挑选，则不要使用此选项，因为该信息对收件人无用。另一方面，如果您在两个公开可见的分支之间进行挑选（例如，从开发分支向旧版本的维护分支向后端移植修复），添加此信息可能很有用。
-r
过去，命令默认执行上述-x，-r禁用它。现在默认情况下不执行-x所以此选项是无操作。
-m parent-number
--mainline parent-number
通常你不能挑选合并因为你不知道合并的哪一边应该被认为是主线。此选项指定主线的父编号（从 1 开始），并允许 cherry-pick 重放相对于指定父级的更改。
-n
--no-commit
通常，该命令会自动创建一系列提交。此标志应用必要的更改来挑选您的工作树和索引的每个命名提交，而不进行任何提交。此外，使用此选项时，索引不必与 HEAD 提交匹配。樱桃选择是针对索引的开始状态完成的。
当在一行中挑选多个提交效果时，这非常有用。
-s
--signoff
在提交消息的末尾添加 Sign-by-by 行。有关详细信息，请参阅 git-commit [1] 中的签收选项。
-S[<keyid>]
--gpg-sign[=<keyid>]
GPG 签名提交。 keyid参数是可选的，默认为提交者标识;如果指定，它必须粘在没有空格的选项上。
--ff
如果当前 HEAD 与 cherry-pick’ed 提交的父级相同，则将执行此提交的快进。
--allow-empty
在默认情况下，挑选空提交将失败，表明需要显式调用git commit --allow-empty。此选项会覆盖该行为，允许在提取中自动保留空提交。请注意，当“ - ff”生效时，即使没有此选项，也会保留满足“快进”要求的空提交。另请注意，使用此选项仅保留最初为空的提交（即提交记录与其父项相同的树）。由于先前提交而变为空的提交被删除。要强制包含这些提交，请使用--keep-redundant-commits。
--allow-empty-message
默认情况下，使用空消息挑选提交将失败。此选项会覆盖该行为，允许提取空消息的提交。
--keep-redundant-commits
如果提取的提交重复了当前历史记录中的提交，则它将变为空。默认情况下，这些冗余提交会导致cherry-pick停止，以便用户可以检查提交。此选项会覆盖该行为并创建一个空提交对象。意味着--allow-empty。
--strategy=<strategy>
使用给定的合并策略。应该只使用一次。有关详细信息，请参阅 git-merge [1] 中的 MERGE STRATEGIES 部分。
-X<option>
--strategy-option=<option>
将合并策略特定选项传递给合并策略。有关详细信息，请参阅 git-merge [1] 。
Git 中文参考（四）（8）https://developer.aliyun.com/article/1565836
