我早就使用git并维护master，develop和features分支。 现在由于合并失败，我们的开发分支的代码有些错误。因此，我们将功能分支从master分支创建为特定功能。
实现功能后，我们已将此功能分支发布到prodoction，理想情况下我们不应该这样做。但是由于开发中的错误代码，我们已将功能分支发布到生产中。
现在，我正在开发一些新功能，并且希望为此新功能创建新功能分支。
我的问题是
是否有任何经验法则或最佳做法表明不从功能部件或母版创建功能分支？
我不想从其他功能分支或主分支创建功能分支，但是我不知道为什么应该避免这种情况的确切原因吗？
答案 0 :(得分：1)
考虑到您已经拥有location = location.strip().encode('latin1')
，master和develop分支，在我看来，您正在关注GitFlow Workflow。在这种情况下，如果您要对上一发行版进行一些修复或改进，则可以创建feature分支，这些分支是从hotfix分支派生的。引用上一个链接的修补程序分支主题：
维护或“修补程序”分支用于快速修补生产版本。修补程序分支与发行分支和功能分支很像，只是它们基于主版本而不是开发版本。这是唯一应直接从master分支的分支。修复程序完成后，应将其合并到master和developer（或当前发行版分支）中。
这只是对GitFlow类型的分支模型的建议，可在再次稳定master分支时使用。
我能想到的避免从另一个功能分支创建功能分支的唯一原因是试图避免从不稳定的分支中派生（这不是您的情况），并在跟踪过程中尽量保持历史记录的整洁GitFlow或类似的工作流程。但这是相对的，因为最终您在Git上拥有的是链接提交而不是清晰的分支。另外，没有真正的限制，可以使您远离仓库中任何分支/提交的develop分支。
关于您的develop分支，为了使其稳定，我建议revert all the commits直到对feature的最后一次已知的稳定提交，然后develop {{1}的头）如果您确定merge是稳定的，则将}插入master分支。在Git的历史上，它看起来可能并不漂亮，但是可以胜任。 请注意，在确定更改之前不要推送更改。
答案 1 :(得分：0)
功能分支还不错，这是您如何利用它们的地方。
在生产环境中，您最多需要一个分支用于可部署的代码，而另一个则用于测试。为了跟踪更改以及这些更改是否有效，您可以进一步将更改与DEV分支隔离开。如您所述，有人引入了错误的代码，因此您应该避免这种情况。
以下面的示例为例：
主分支-生产就绪代码 开发部门-测试部门
请注意，功能现在是代码的大类，而子分支是各个冲刺。内部冲刺完成后，我们可以在功能分支中将它们汇总在一起，证明其有效性，然后再合并到我们的Dev分支中，在该分支中我们可以在测试环境中进行部署。
因此功能很好，可以用来封装工作，同时也可以使工作集中。