当我的新功能取决于之前的更改时，我应该从分支分支还是创建标记？

Question

我正在GitHub上开发一个OpenSource项目，我们已就一些规则达成一致（列出相关规则）：

• 合并到主人将由Pull Requests完成。
• 每次合并至主人必须至少由两个人“触动”。
• 每个新功能都将在适当命名的分支上实现。

我所遇到的一个真实案例如下：

1. 出现了对功能A的需求。
2. 我创建了一个分支a并在那里实现了它。
3. 我已经提出了从分支a到master的拉取请求，但现在没有人可以审核它。

我遇到的问题是我想要处理的另一个功能B.但是，功能B需要存在功能A更改。我该如何继续存储功能B的源代码？

我的想法是：

• 在分支a处创建标记，以标记A实现的结束。
• 来自b的分支a并在那里进行进一步更改。
• 直接从b分支master并在其上结帐a。

我对Git不是很有经验，我认为上面所有我都不知道的问题，也许还有其他方法可以很好地管理它。对于我遇到的问题，最好的解决办法是什么？

注意：在完成实施B之前，a很可能会合并为主。

Answer 1

我想这个：

  

分支b来自a并在那里进行进一步的更改。

是合理的。你仍然可以自己合并一个。 之后，当将b合并到master（合并之后）时，应该没有不必要的冲突，如果你决定要b而不是a（或来自另一个分支的替代实现）你可以修复它“足够好” “通过改变。

Answer 2

最自然的方法是从A分支并从这里开始工作：

• 如果拉取请求按原样接受，您可以继续使用工作流程，就好像从master分支;
• 如果分支A已被修改，您可以在提交审核之前在新版A上修改您的工作;
• 如果分支A被删除，您可以在新的B准备就绪后，对A所需的功能进行新的实施。

Answer 3

如果我忽略了你使用Git的事实，我会说这类似于Bazaar管道的含义。因此，鉴于相似性，我只需将另一个分支分支出特征A分支。

<强>更新

Bazaar管道基本上是捆绑在一起的分支。管道中的管道顺序很重要。关键在于能够将单个特征作为多个补丁并行处理主线，并且能够传播管线方向的变化。在您的情况下，管道将是主 - 特征-A - 特征-B。之后，即使管道（要素分支）本身包含许多更改集，您也可以将每个要素折叠为单个更改集。

它与你的情况不同，但它足够类似，特别是因为B依赖于A，我说从A分支实现B。