在GitHub流中，可以将功能分支基于另一个功能分支吗？

我们在项目中使用GitHub Flow，大多数时候，我们从master开一个新的功能分支，在那做一些工作，打开PR，查看代码，然后合并回master。

但是，我目前的工作取决于中正在处理的另一个问题feature-branch-A。从另一个分支创建我的分支是否符合犹太规范，还是违背GitHub Flow的精神？

另一种选择是将我的分支基于master并合并feature-branch-A（经常）进行的更改。

GitHub流中首选哪个选项？

这是我从功能分支分支时遵循的工作流程：

1. feature-branch-B从创建feature-branch-A
2. 从事于 feature-branch-B
3. 如果feature-branch-A分支后添加了更多提交，请重新定位feature-branch-B到feature-branch-A
4. 完成工作feature-branch-B并等待feature-branch-A合并到中master。
5. 后feature-branch-A合并到master，底垫feature-branch-B到master
6. 合并feature-branch-B成master

通过遵循上述工作流程，您似乎会master在feature-branch-A合并后从中分支。您不必等到feature-branch-A合并后就可以开始工作了feature-branch-B。但是，您将获得干净的历史记录，而无需任何复杂的树木。

我认为如果您在其他功能上创建功能完全可以。

但是不要经常这样做。我看到有一位开发人员做到了这一点，而一两个星期他就把10个PR合并了。这对于其他成员进行审核完全是累死的，也很难合并。尝试不要在git中创建树。这有助于bisect查找错误。

git-flow旨在解决的关键问题是能够推理给定分支的角色以及它从何分支并合并到其中的能力。

理想情况下，所有分支都合并回到合并的代码行。这通常是来自主线的合并（在git-flow中是dev）。Feature分支从dev分支并合并，release分支从dev分支并合并（还有到的额外合并master）。修补程序从master分支并合并（并将其他合并回dev）。

每个代码行都从其分支分支并合并回到其父级。如果需要，一条代码行可以随时从其他代码行中提取代码。

如果来自功能分支的分支是“我想探索在该功能分支中解决问题的这种方式”-很好。它从功能分支分支，提交一些代码，然后合并回到功能分支（或被丢弃）。

1. 从功能分支
2. 探索想法
3. 合并为特征

但是，您要避免的情况如下所示：

1. 从所需功能分支
2. 处理代码
3. 完成所需功能后，从开发人员合并
4. 验证功能分支中的功能（和其他提交）
5. 合并到开发人员

原因是开头和结尾不匹配-这使得理解这是什么和过去变得有点困难。并非没有，但是这会使某人花更多的时间来了解其角色。

但是，如果这是依赖于dev中尚未找到的代码的新功能，则流程应为：

1. 开发人员的分支
2. 从所需功能合并
3. 处理代码
4. 完成所需功能后，从开发人员合并
5. 验证功能分支中的功能（和其他提交）
6. 合并到开发人员

请注意，这从dev的分支开始，以合并到dev结束。

综上所述，最好的办法是避免将一个功能合并到另一个功能。分支功能，进行任何必要的准备...然后等待。

1. 开发人员的分支
2. 处理代码
3. 完成所需功能后，从开发人员合并
4. 验证功能分支中的功能（和其他提交）
5. 合并到开发人员

这提供了最稳定的分支和代码集。

将来的工作需要考虑的一个功能是发布必要的接口，以便与其他功能进行互操作-即使实​​现代码不完整。这将被合并到开发人员中，然后所需功能可以像将来功能一样在这些接口上工作。与将来必须等待功能合并到开发环境相比，这可能会使将来的功能进一步发展（针对接口进行编码，针对实现接口的存根进行测试）。

功能分支通常被认为不如主干（开发/母版）稳定，因此如果您的工作基于一个分支，则您可能会遭受比常规更多的基础更改。

此外，虽然通常不赞成分支是否被推送，但将要素分支重新建立到其父分支上以获得更好的历史记录并不少见，但是如果悬挂了其他分支，那将变得更加复杂，因此您实质上是在为母公司的分支机构所有者设立新的限制，并给自己带来潜在的麻烦。

就是说，对此没有严格的规定。毕竟，这些只是模式和最佳实践。

编辑：错过了您的问题的一部分。将功能分支合并到您自己的（基于master的分支）中并不能真正避免上面提到的任何问题，并且实际上可能会创建更复杂的历史记录。

因此，如果我不愿做任何事情，并且可以将工作推迟到完成功能a之前，或者先做其他事情，我会做的。