我可以将“git rebase”表示为一系列精选内容吗？答案

【问题标题】：Can I represent a "git rebase" as a series of cherry-picks?我可以将“git rebase”表示为一系列精选内容吗？
【发布时间】：2019-05-13 18:34:28
【问题描述】：

似乎“git rebase”有额外的回退逻辑来处理合并失败：

Falling back to patching base and 3-way merge...

它在那里做什么，我需要如何调用我的樱桃选择来获得相同的行为？

可能正确的解决方案是不尝试将变基表示为一系列精选，但如果这可能会很好，因为我可以使用相同的方法处理变基和任意更改集合流。

【问题讨论】：

你能详细说明你想要做什么吗？图表可能会有所帮助。
我有一个 CI 工作流，它可以使用一个变基或一组不同的补丁。不必区分这两种情况，我宁愿将 rebase 转换为一组精选，而不必在结帐时考虑。

标签： git git-rebase git-cherry-pick

【解决方案1】：

大多数git rebase 命令实际上执行运行git cherry-pick。

您看到的回退发生在git rebase 的一种形式中，由于历史原因，不使用git cherry-pick。当您调用 non-interactive git-rebase 并且时使用该一种形式，不要使用任何使其使用新的和改进的 rebase-invoking 的选项方法。

旧形式通常产生相同的效果。它包括使用git format-patch 将每个提交转换为补丁，然后使用git am --3way 应用所有格式化补丁。 --3way 选项告诉git am，如果不能盲目地应用补丁，它应该使用每个格式化补丁中的index 行来实现git cherry-pick 自动完成的部分操作 .

如果你想 rebase 直接使用git cherry-pick，你可以：

提供-k 选项，或
提供-m 选项，或
提供-s <em>strategy</em> 选项，或
提供-X <em>extended-option</em> 选项，或
使用交互式变基（-i 或 --interactive），或者
使用--autosquash 选项，或
使用 -p 或 (Git 2.18+) -r 选项。

【讨论】：

我更想了解如何使我的一系列补丁表现得像一个变基。我想你已经给出了答案，但我需要对其进行编码和测试。如果我理解正确的话，每个“cherry-pick”都需要使用 format-patch 和 git am --3way。
那么我不确定你的问题是什么。如果您有一系列补丁，请使用git am --3way（或简称-3）获得与git rebase 使用git format-patch 和git am 时相同的效果。请注意，如果您不控制 git format-patch 操作，您将获得 abbreviated index 行，这可能没有用。您希望生成补丁的人使用--full-index。或者，如果您在自己的存储库中有一系列提交哈希 ID，请对它们使用 git cherry-pick，一次一个，将它们应用到当前的 HEAD。
使用cherry-pick 在某些方面更胜一筹，但速度也较慢（因为它会通过全树差异来查找重命名）。还要注意，变基通过强制分支标签移动到新构建的提交来结束；如果你自己调用 git cherry-pick 或 git am / git apply，你也必须自己做。
剩下要考虑的一件事是，当git rebase 枚举git cherry-pick 的提交（使用cherry-pick 代码路径）时，它会有意省略一些提交。具体来说，上游和当前分支中存在的提交，并且在两个“边”中具有相同的补丁 ID，将被省略；除非使用-p 或-r，否则所有合并都会被省略，在这种情况下，它们会被特别枚举以便重复。枚举使用git rev-list --left-right --cherry-mark <upstream>...HEAD 来确定哪些提交是哪些。
（上面的细节不是 100% 准确的，有时有--no-merges，有时你可以不用--right-only。在最近更改使git rebase 全部是C 代码之前，这更容易确定哪些变基做了哪些事情以及他们使用了什么git rev-list 命令，就像所有几个非常大的 shell 脚本一样。）