我想针对每个功能提出拉取请求。但是我在工作流程上遇到了问题。
例如，我在分支feature1中处理了一个功能，提出了拉取请求，而在等待该拉取请求获得批准的同时，我想开始使用另一个功能。
在feature2中，我想获得feature1中的代码，对此最好的方法是什么？
我曾经从feature1进行另一个分支，但是当我向feature2到master发出拉动请求时，我有了feature1和{{ 1}}。
人们如何做到这一点？
答案 0 :(得分：1)
实际上，从feature1分支到feature2开始可能是最好的主意。因此，理想情况下，您应该强制feature1先合并feature2。如果您绝对不能执行此命令，则可能意味着您应该在feature2之前开始在feature1上工作，也就是说，应该切换分支。
答案 1 :(得分：1)
只需在已经说过的内容上添加一些内容即可：feature2可以位于feature1之上，唯一的事情是，在移动分支时必须小心，因此 not 不能自动运行。包括来自feature1 .....的内容是这样，因为如果您不小心，可能会有不同的情况使它崩溃。例如：Feature1被合并.....但被压缩。然后，feature2所在的修订版本就不再有效....如果对feature1进行了基础改版.....或对其进行了完全改编...，在同一情况下，在所有这些情况下，您都必须注意 not < / em>左右移动feature2时，包括feature1的修订版本。
处理此问题的最简单方法是重新设定feature2的基础，但只有真正构成的基础：
git rebase --onto anywhere feature2~4 feature2
那是假设feature2由4个直接修订组成。所以，总而言之，没关系。...请小心。
答案 2 :(得分：1)
我认为最好的方法不是这样做。
只要还有其他featureX不需要来自feature1的代码，我将从featureX而不是feature2开始。
在代码审查期间，可能会有变更请求，这些变更请求会影响您feature2所需的代码。
如果等待合并feature1是不切实际的（审核将花费很长时间，并且没有其他功能可以开始），那么可以从{{1}分支出feature2 }。但是，如果将feature1压缩到feature1中，则需要进行一些基础调整，或者再次脱离母版，然后将特征2特定的工作从原始master分支中挑选出来。新的feature2分支。
答案 3 :(得分：0)
在
feature2中，我想获取feature1中的代码
不能。 “ feature1中的代码”就是您正在等待批准的代码！如果允许您将未经批准的更改合并到另一个新分支中，那么PR和整个批准过程的意义何在？您不妨一个人工作，而完全跳过PR。
在您的体系结构中，功能必须是独立的。相反，如果它们不是独立的，则您不应过早提交PR。这应该都是一个长分支。