我在 git 中有一些看起来像这样的分支：
master b1
↓ ↓
A -- B -- C -- D -- E
但是D ... E 竟然是一个出乎意料的不平凡的改变，所以我想看看这个：
master b3
↓ ↓
A -- B -- C b2
\ ↓
D -- E
...这样b2可以单独审核，合并到b3，然后合并到master。
我试过了：
git checkout b1
git checkout -b b2
git rebase C
但有合并冲突。这向我表明这是错误的做法，因为C ... D 都被相继应用于彼此并且永远不应该冲突。我需要什么咒语？
【问题讨论】：
标签： git git-branch git-rebase
b2 等价于 b1，因此您所要做的就是在提交时创建 b3 C。
git branch b3 C
如果你坚持b2 存在于提交E（除了b1），你也可以创建它：
git branch b2 E
第二个图表中的所有提交都与第一个图表相同，因此您无需执行任何其他操作。
【讨论】：
b2 到 b3 的 PR 显示了来自 A ... E 而不是 C ... E 的所有提交。预计。是否需要对存储库做一些额外的事情，或者我应该把它归结为 GH 中一个被忽视的 UX 角落案例？
b2作为不包括A、B或C的PR时，那么你不再有“两个连续的分支”，而是两个“平行”（可以这么说）分支。你需要哪一个？
b2 作为 PR 提交给 b3（还不是 master），所以增量变化不会那么大。不确定这是否有意义。
作为mkrieger1 said，您实际上只是想创建标签b3 指向提交C。
GitHub 和 GitHub 的“PR”（拉取请求）的诀窍在于，既然您在本地拥有这些名称，您需要在 GitHub 上创建相同的名称 —请记住，他们的存储库实际上是一个单独的、独立的存储库，具有自己独立的分支名称 — 指向相同的哈希 ID。这部分很简单：只需 git push origin b3 名称为 b3 在本地识别提交 C。由于提交C（具有相同的哈希ID）已经复制到GitHub，这只是创建名称b3on GitHub，指向提交C。而且，现在这意味着在 GitHub 上，您可以创建一个拉取请求，上面写着 让我们将提交 E 合并到提交 C，使用名称 b3 作为 PR，b2 作为“基础分支” . GitHub 只能在他们自己的仓库中看到他们自己的名字，但是现在你做了git push，他们的名字和你一样。
请注意，如果 PR 获得批准并且提交 E 被合并到 GitHub 上的提交 C 中，则可以：
但在任何情况下，GitHub 网页上的绿色“合并”大按钮都不会创建 快进 合并。这意味着您将获得：
master b3
↓ ↓
A -- B -- C ------ M
\ /
D -- E
↑
b2
如果您选择“真正的合并”选项，或者：
master b3
↓ ↓
A -- B -- C ---- D' -- E'
\
D -- E
↑
b2
如果您选择 rebase-and-merge 选项，或者：
master b3
↓ ↓
A -- B -- C ---- DE
\
D -- E
↑
b2
如果您选择“压缩和合并”选项。
如果这些选项都不可接受（无论出于何种原因——它们都是你的原因，因为至少其中一些应该在至少某些情况下起作用），不要使用 GitHub 网页上的绿色大 merge 按钮。
【讨论】：