Git 中文参考（四）（7）https://developer.aliyun.com/article/1565835
SEQUENCER SUBCOMMANDS
--continue
使用 .git / sequencer 中的信息继续进行中的操作。可以在解决失败的挑选或恢复中的冲突后继续使用。
--quit
忘记当前正在进行的操作。在樱桃挑选或恢复失败后，可用于清除顺序器状态。
--abort
取消操作并返回到预序列状态。
例子
git cherry-pick master
应用 master 分支顶端提交引入的更改，并使用此更改创建新提交。
git cherry-pick ..master
git cherry-pick ^HEAD master
应用所有提交引入的更改，这些提交是 master 的祖先但不是 HEAD 的祖先，以生成新的提交。
git cherry-pick maint next ^master
git cherry-pick maint master..next
应用作为 maint 或 next 的祖先的所有提交所引入的更改，但不应包含 master 或其任何祖先。注意，后者并不意味着maint和master和next之间的所有内容;具体而言，如果master中包含maint，则不会使用maint。
git cherry-pick master~4 master~2
应用 master 指向的第五个和第三个最后提交所引入的更改，并使用这些更改创建 2 个新提交。
git cherry-pick -n master~1 next
将工作树和索引应用于 master 指向的第二个最后一次提交所引入的更改以及 next 指向的最后一个提交，但不要使用这些更改创建任何提交。
git cherry-pick --ff ..next
如果历史是线性的并且 HEAD 是 next 的祖先，则更新工作树并使 HEAD 指针前进以匹配 next。否则，将下一个但不是 HEAD 的提交引入的更改应用于当前分支，为每个新更改创建一个新提交。
git rev-list --reverse master -- README | git cherry-pick -n --stdin
将触及 README 的主分支上的所有提交引入的更改应用到工作树和索引，因此可以检查结果并将其作为单个新提交（如果合适）。
以下序列尝试向后移植补丁，因为补丁适用的代码已经发生了太大的变化，然后再次尝试，这次会更加关注匹配上下文行。
$ git cherry-pick topic^ (1) $ git diff (2) $ git reset --merge ORIG_HEAD (3) $ git cherry-pick -Xpatience topic^ (4)
- 应用
git show topic^显示的更改。在此示例中，修补程序不能完全应用，因此有关冲突的信息将写入索引和工作树，而不会产生新的提交结果。 - 总结要调和的变化
- 取消樱桃挑选。换句话说，返回 pre-cherry-pick 状态，保留您在工作树中的任何本地修改。
- 尝试再次应用
topic^引入的更改，花费额外的时间来避免基于错误匹配的上下文行的错误。
也可以看看
GIT
部分 git [1] 套件
git-rebase
名称
git-rebase - 重新应用提交在另一个基本提示之上
概要
git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] [<upstream> [<branch>]] git rebase [-i | --interactive] [<options>] [--exec <cmd>] [--onto <newbase>] --root [<branch>] git rebase --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch
描述
如果< branch>如果指定， git rebase 将在执行任何其他操作之前执行自动git checkout 。否则它仍然在当前分支上。
如果< upstream>未指定，上游在分支中配置。< name> .remote 和 branch。将使用< name> .merge 选项（详见 git-config [1] ）和--fork-point假设选项。如果您当前不在任何分支上，或者当前分支没有配置上游，则 rebase 将中止。
由当前分支中的提交进行的所有更改，但不在< upstream>中。被保存到临时区域。这是git log ..HEAD显示的同一组提交;或git log 'fork_point'..HEAD，如果--fork-point有效（参见下面--fork-point的说明）;如果指定了--root选项，则按git log HEAD。
当前分支重置为< upstream>或< newbase>如果提供了–onto 选项。这与git reset --hard （或< newbase>）具有完全相同的效果。 ORIG_HEAD 设置为在重置之前指向分支的尖端。
之前保存到临时区域的提交将按顺序逐个重新应用于当前分支。请注意，HEAD 中的任何提交都会引入与 HEAD 中的提交相同的文本更改。< upstream>被省略（即，将跳过已经在上游接受的具有不同提交消息或时间戳的补丁）。
合并失败可能会阻止此过程完全自动化。您必须解决任何此类合并失败并运行git rebase --continue。另一种选择是绕过导致合并失败的提交git rebase --skip。要查看原始<分支>并删除.git / rebase-apply 工作文件，改为使用命令git rebase --abort。
假设存在以下历史记录，并且当前分支是“主题”：
A---B---C topic / D---E---F---G master
从这一点来看，以下任一命令的结果：
git rebase master git rebase master topic
将会：
A'--B'--C' topic / D---E---F---G master
**注意：**后一种形式只是git checkout topic的简写，后跟git rebase master。当 rebase 退出topic时，将保留签出分支。
如果上游分支已经包含您所做的更改（例如，因为您邮寄了上游应用的补丁），那么将跳过该提交。例如，在以下历史记录中运行git rebase master（其中A'和A引入相同的更改集，但具有不同的提交者信息）：
A---B---C topic / D---E---A'---F master
将导致：
B'---C' topic / D---E---A'---F master
以下是如何将基于一个分支的主题分支移植到另一个分支，假设您使用rebase --onto从后一分支分叉主题分支。
首先让我们假设您的 _ 主题 _ 基于分支 _ 下一个 。例如， 主题 _ 中开发的功能取决于 _ 下一个 _ 中的某些功能。
o---o---o---o---o master \ o---o---o---o---o next \ o---o---o topic
我们想从分支 master 分叉 _ 主题 _;例如，因为 _ 主题 _ 所依赖的功能被合并到更稳定的 _ 主 _ 分支中。我们希望我们的树看起来像这样：
o---o---o---o---o master | \ | o'--o'--o' topic \ o---o---o---o---o next
我们可以使用以下命令获取此信息：
git rebase --onto master next topic • 1
–onto 选项的另一个例子是重新定义分支的一部分。如果我们有以下情况：
H---I---J topicB / E---F---G topicA / A---B---C---D master
那么命令
git rebase --onto master topicA topicB
会导致：
H'--I'--J' topicB / | E---F---G topicA |/ A---B---C---D master
当 topicB 不依赖于 topicA 时，这很有用。
也可以使用 rebase 删除一系列提交。如果我们有以下情况：
E---F---G---H---I---J topicA
那么命令
git rebase --onto topicA~5 topicA~3 topicA
会导致删除提交 F 和 G：
E---H'---I'---J' topicA
如果 F 和 G 在某种程度上存在缺陷，或者不应该成为 topicA 的一部分，那么这很有用。注意 - -onto 和< upstream>的参数。参数可以是任何有效的 commit-ish。
如果发生冲突， git rebase 将在第一个有问题的提交时停止，并在树中留下冲突标记。您可以使用 git diff 来定位标记（<<<<<<<<<<<<<<<<<<<<<<<<对于您编辑的每个文件，您需要告诉 Git 冲突已经解决，通常可以这样做
git add <filename>
手动解决冲突并使用所需的分辨率更新索引后，您可以继续使用
git rebase --continue
或者，您可以撤消 git rebase
git rebase --abor
组态
rebase.useBuiltin
设置为false以使用 git-rebase [1] 的旧版 shellcript 实现。默认情况下是true，这意味着在 C 中使用内置的重写。
C 重写首先包含在 Git 版本 2.20 中。如果在重写中发现任何错误，此选项可用于重新启用旧版本。此选项和 git-rebase [1] 的 shellscript 版本将在以后的某个版本中删除。
如果您发现某些理由将此选项设置为false而非一次性测试，则应将行为差异报告为 git 中的错误。
rebase.stat
是否显示自上次 rebase 以来上游改变的差异。默认为 False。
rebase.autoSquash
如果设置为 true，则默认启用--autosquash选项。
rebase.autoStash
设置为 true 时，在操作开始之前自动创建临时存储条目，并在操作结束后应用它。这意味着您可以在脏工作树上运行 rebase。但是，谨慎使用：成功重组后的最终存储应用程序可能会导致非平凡的冲突。 git-rebase [1] 的--no-autostash和--autostash选项可以覆盖此选项。默认为 false。
rebase.missingCommitsCheck
如果设置为“warn”，git rebase -i 将在删除某些提交时打印警告（例如删除了一行），但是 rebase 仍将继续。如果设置为“error”，它将打印上一个警告并停止 rebase，然后可以使用 git rebase --edit-todo 来纠正错误。如果设置为“忽略”，则不进行检查。要在没有警告或错误的情况下删除提交，请使用待办事项列表中的drop命令。默认为“忽略”。
rebase.instructionFormat
git-log [1] 中指定的格式字符串，用于交互式 rebase 期间的待办事项列表。格式将自动在格式之前添加长提交哈希。
rebase.abbreviateCommands
如果设置为 true，git rebase将在待办事项列表中使用缩写的命令名称，结果如下：
p deadbee The oneline of the commit p fa1afe1 The oneline of the next commit ...
代替：
pick deadbee The oneline of the commit pick fa1afe1 The oneline of the next commit ...
默认为 false。
rebase.rescheduleFailedExec
自动重新安排失败的exec命令。这仅在交互模式下（或提供--exec选项时）才有意义。这与指定--reschedule-failed-exec选项相同。
OPTIONS
--onto <newbase>
创建新提交的起点。如果未指定–onto 选项，则起点为< upstream>。可以是任何有效的提交，而不仅仅是现有的分支名称。
作为特殊情况，如果只有一个合并库，则可以使用“A … B”作为 A 和 B 的合并基础的快捷方式。您最多可以省略 A 和 B 中的一个，在这种情况下，它默认为 HEAD。
<upstream>
上游分支进行比较。可以是任何有效的提交，而不仅仅是现有的分支名称。默认为当前分支的已配置上游。
<branch>
工作分支;默认为 HEAD。
--continue
解决合并冲突后重新启动重定位过程。
--abort
中止 rebase 操作并将 HEAD 重置为原始分支。如果< branch>在 rebase 操作开始时提供，然后 HEAD 将重置为< branch>。否则，HEAD 将重置为启动 rebase 操作时的位置。
--quit
中止 rebase 操作但 HEAD 不会重置回原始分支。结果，索引和工作树也保持不变。
--keep-empty
在结果中保留不改变其父项的任何提交。
另见下面的不兼容的选项。
--allow-empty-message
默认情况下，使用空消息进行的 rebasing 提交将失败。此选项会覆盖该行为，允许对具有空消息的提交进行重新定位。
另见下面的不兼容的选项。
--skip
跳过当前修补程序重新启动重定位过程。
--edit-todo
在交互式 rebase 期间编辑待办事项列表。
--show-current-patch
在交互式 rebase 中显示当前补丁，或者由于冲突而停止 rebase。这相当于git show REBASE_HEAD。
-m
--merge
使用合并策略进行 rebase。当使用递归（默认）合并策略时，这允许 rebase 知道上游侧的重命名。
请注意，通过从< upstream>顶部的工作分支重放每个提交来进行 rebase 合并。科。因此，当合并冲突发生时，报告为 _ 我们的 _ 的那一方是迄今为止重新命名的系列，从< upstream>开始，而 _ 他们的 _ 是工作分支。换句话说，双方交换。
另见下面的不兼容的选项。
-s <strategy>
--strategy=<strategy>
使用给定的合并策略。如果没有-s选项 ，则使用 git merge-recursive 。这意味着–merge。
因为 git rebase 重放来自< upstream>顶部的工作分支的每个提交。使用给定策略的分支，使用 _ 我们的 _ 策略简单地清空< branch>中的所有补丁，这没有多大意义。
另见下面的不兼容的选项。
-X <strategy-option>
--strategy-option=<strategy-option>
通过< strategy-option>通过合并策略。这意味着--merge，如果没有指定策略，则-s recursive。注意 _ 我们的 _ 和的逆转，如上所述-m选项。
另见下面的不兼容的选项。
-S[<keyid>]
--gpg-sign[=<keyid>]
GPG 签名提交。 keyid参数是可选的，默认为提交者标识;如果指定，它必须粘在没有空格的选项上。
-q
--quiet
安静。意味着–no-stat。
-v
--verbose
要冗长。意味着 - 停止。
--stat
显示自上次 rebase 以来上游更改的差异。 diffstat 也由配置选项 rebase.stat 控制。
-n
--no-stat
不要将 diffstat 显示为 rebase 过程的一部分。
--no-verify
此选项绕过 pre-rebase 挂钩。另见 githooks [5] 。
--verify
允许运行 pre-rebase 挂钩，这是默认值。此选项可用于覆盖–no-verify。另见 githooks [5] 。
-C<n>
确保至少< n>周围环境的线在每次更改之前和之后匹配。当存在较少的周围环境线时，它们都必须匹配。默认情况下，不会忽略任何上下文。
另见下面的不兼容的选项。
--no-f
--force-rebase
-f
单独重放所有重新提交的提交，而不是快速转发未更改的提交。这可以确保重新分支的整个历史记录由新提交组成。
在恢复主题分支合并之后，您可能会发现这很有用，因为此选项使用新提交重新创建主题分支，因此可以成功重新合并而无需“恢复恢复”（请参阅 revert-a-faulty-merge 如何 - 详情请）。
--fork-point
--no-fork-point
使用 reflog 在< upstream>之间找到更好的共同祖先。和< branch>在计算由< branch>引入的提交时。
当–fork-point 激活时，将使用 fork_point 代替< upstream>计算 rebase 的提交集，其中 fork_point 是git merge-base --fork-point 命令的结果（参见 git-merge-base [1] ）。如果 fork_point 最终为空，则< upstream>将被用作后备。
如果是< upstream>或–root 在命令行中给出，则默认为--no-fork-point，否则默认为--fork-point。
--ignore-whitespace
--whitespace=<option>
这些标志被传递给应用补丁的 git apply 程序（参见 git-apply [1] ）。
另见下面的不兼容的选项。
--committer-date-is-author-date
--ignore-date
这些标志传递给 git am 以轻松更改重新提交的提交日期（参见 git-am [1] ）。
另见下面的不兼容的选项。
--signoff
添加 Signed-off-by：预告片到所有重新提交的提交。请注意，如果给出了--interactive，那么只有标记为要挑选，编辑或重新编号的提交才会添加预告片。
另见下面的不兼容的选项。
-i
--interactive
列出即将重新定位的提交。让用户在变基之前编辑该列表。此模式也可用于拆分提交（请参阅下面的 SPLITTING COMMITS）。
可以通过设置配置选项 rebase.instructionFormat 来更改提交列表格式。自定义指令格式将自动将长提交哈希添加到格式之前。
另见下面的不兼容的选项。
-r
--rebase-merges[=(rebase-cousins|no-rebase-cousins)]
默认情况下，rebase 将简单地从 todo 列表中删除合并提交，并将重新提交的提交放入单个线性分支中。使用--rebase-merges，rebase 将通过重新创建合并提交来尝试保留要重新提交的提交中的分支结构。必须手动解决/重新应用这些合并提交中的任何已解决的合并冲突或手动修改。
默认情况下，或者当指定no-rebase-cousins时，没有作为直接祖先的提交将保留其原始分支点，即 git 1 的--ancestry-path选项将被排除的提交默认情况下会保留原始血统。如果打开rebase-cousins模式，则此类提交将改为（或，如果指定）。
--rebase-merges模式在精神上与--preserve-merges类似，但与此选项相反，在交互式 rebase 中效果很好：可以随意重新排序，插入和删除提交。
目前只能使用recursive合并策略重新创建合并提交;只能通过显式exec git merge -s [...]命令使用不同的合并策略。
另请参见下面的“重新合并和不兼容的选项”。
-p
--preserve-merges
通过重放合并提交引入的提交来重新创建合并提交，而不是展平历史记录。不保留合并冲突解决方案或手动修改合并提交。
这在内部使用--interactive机器，但明确地将它与--interactive选项结合使用通常不是一个好主意，除非你知道你在做什么（参见下面的 BUGS）。
另见下面的不兼容的选项。
-x <cmd>
--exec <cmd>
附加“exec< cmd>”在每行创建最终历史记录中的提交之后。 < CMD>将被解释为一个或多个 shell 命令。任何失败的命令都会中断 rebase，退出代码为 1。
您可以通过使用--exec的一个实例和几个命令来执行多个命令：
git rebase -i --exec "cmd1 && cmd2 && ..."
或者通过提供多个--exec：
git rebase -i --exec "cmd1" --exec "cmd2" --exec ...
如果使用--autosquash，则不会为中间提交附加“exec”行，并且只会出现在每个 squash / fixup 系列的末尾。
这在内部使用--interactive机器，但可以在没有显式--interactive的情况下运行。
另见下面的不兼容的选项。
--root
重新引用从< branch>可到达的所有提交，而不是用< upstream>来限制它们。这允许您在树枝上重新定义根提交。与–onto 一起使用时，它将跳过< newbase>中已包含的更改（而不是< upstream>）而没有–onto 它将在每次变化时运行。当与–onto 和–preserve-merges 一起使用时，_ 所有 _ 根提交将被重写为< newbase>作为父母代替。
另见下面的不兼容的选项。
--autosquash
--no-autosquash
当提交日志消息以“squash！…”（或“fixup！…”）开头，并且 todo 列表中已经存在与相同...匹配的提交时，自动修改 rebase -i 的待办事项列表因此，标记为压缩的提交在修改提交之后立即生效，并将移动的提交的操作从pick更改为squash（或fixup）。如果提交主题匹配，或者...引用提交的哈希，则提交与...匹配。作为后备，提交主题的部分匹配也起作用。创建 fixup / squash 提交的推荐方法是使用 git-commit [1] 的--fixup / --squash选项。
如果使用配置变量rebase.autoSquash默认启用--autosquash选项，则此选项可用于覆盖和禁用此设置。
另见下面的不兼容的选项。
--autostash
--no-autostash
在操作开始之前自动创建临时存储条目，并在操作结束后应用它。这意味着您可以在脏工作树上运行 rebase。但是，谨慎使用：成功重组后的最终存储应用程序可能会导致非平凡的冲突。
--reschedule-failed-exec
--no-reschedule-failed-exec
自动重新安排失败的exec命令。这仅在交互模式下（或提供--exec选项时）才有意义。
不兼容的选择
以下选项：
- –committer-日期是执笔者最新
- 忽略日期
- –whitespace
- 忽略空白
- -C
与以下选项不兼容：
- 合并
- 战略
- –strategy 选项
- –allow 空消息
- [无糖] autosquash
- –rebase，合并
- –preserve-合并
- 互动
- –exec
- –keep 空
- –edit-待办事项
- 与–onto 组合使用时
此外，以下两对选项不兼容：
- –preserve-merges 和–interactive
- –preserve-merges 和–signoff
- –preserve-merges 和–rebase-merges
- –rebase-merges 和–strategy
- –rebase-merges 和–strategy-option
Git 中文参考（四）（9）https://developer.aliyun.com/article/1565837
