Question

我遇到了从 feat-a 分支出一个功能 (develop) 的情况。做了一些工作，然后将 PR 发送回 develop。

在那之后，等待 PR 获得批准，我再次从 develop 分支到 feat-b。我进行了一次提交，然后意识到需要我在 feat-a 中完成的修复才能让 feat-b 继续前进。

那么，此时的情况是这样的：

develop  A → B       
             |\
feat-a       | C → D
              \  
feat-b         E → F

现在，我想到将 feat-b 重新定位到 feat-a 以从 feat-a 获得我的修复。然后我将 feat-b 的第二个 PR 提交到 develop。

现在的情况是这样的：

develop  A → B       
              \
feat-a         C → D
                    \
feat-b               E → F

因此，我的 feat-b PR 包括提交 C 和 D。我假设，在这一点上，我无法避免它。在这种情况下，最佳做法是什么？写一个关于 feat-b 依赖于 feat-a 的 PR 的注释？

然而，还有一些我不明白的：一旦 feat-a PR 获得批准，现在 C 和 D 是 develop 的一部分，为什么我的 { {1}} PR 是否仍将 feat-b 和 C 显示为 PR 的一部分（如果它们获得批准）？我能做些什么吗？

Answer 1

<块引用>

现在，我想把 feat-b 改成 feat-a

是的，好吧，那是个错误。一个功能分支不应该从另一个分支中衍生出来。他们需要独立。否则如果 featA 被拒绝怎么办？无论如何，您的 featB 基本上是偷偷摸摸的。另外，正如您所见，它弄乱了历史。

既然您已经这样做了，您需要在提交 PR 之前将 featB E 和 F 重新设置为 develop。这会移动合并基础，以便仅从 E 和 F 正确构造 PR。

git rebase --onto develop featA featB

Answer 2

这是一个旁注，逻辑上应该是注释，但需要格式化。

您以正确的方式绘制了分支，这意味着您以错误的方式绘制了它们。那是因为 Git 向后工作，而不是向前工作。因此，您需要以错误的方式绘制分支，以便它们以正确的方式绘制。 ?

也就是说，而不是：

develop  A → B       
             |\
feat-a       | C → D
              \  
feat-b         E → F

你应该使用：

A <-B   <-- develop
    |\
    | C <-D   <-- feat-a
     \
      E <-F   <-- feat-b

名称 feat-b 选择提交 F。提交 F 点向后，到较早的提交 E。提交 E 不会也不能指向提交 F，因为在创建提交的那一刻，任何提交的所有部分都被冻结。

提交 A-B 在所有三个分支上，因为提交 E 和 C 都向后指向提交 B。 “在”分支上的提交是那些可从到达的提交，Git 称之为提示提交。分支名称会在您进行新提交时自动更新，因此名称始终选择（指向）提示提交。像 git reset 这样的命令可以强制分支名称指向任何现有的任意提交，不会影响存储库中的实际提交集，但会影响通过哪个分支名称可以找到哪些提交。

请记住，Git 是逆向工作的，许多其他事情将开始变得有意义，而这在以前是没有的。

基于显示所有提交的其他功能分支的功能分支的 Git 拉取请求

2 个答案: