为什么我不应该从GIT中的其他特性分支创建特性分支？

很久以前我就在使用git，并维护master、develop和feature分支。 现在由于一些糟糕的合并，我们的开发部门有一些糟糕的代码。所以，我们将特性分支从主分支装箱，以用于特定特性

在功能实现之后，我们将此功能分支发布到prodoction，理想情况下我们不应该这样做。但由于开发过程中的错误代码，我们已经将特性分支发布到生产环境中

现在，我正在开发一些新功能，我希望这个新功能有一个新的功能分支

我的问题是,

是否有任何经验法则或最佳实践表明不从功能或主功能创建功能分支？

---

我不想从其他功能分支或主分支创建功能分支，但我不知道应该避免这样做的确切原因是什么？

考虑到您已经有了

master

、

develope

和

feature

分支，我觉得您在遵循以下原则。在这种情况下，如果您正在对上一版本进行某些修复或改进，则可以创建

hotfix

分支，这些分支来自

master

分支。引用上一链接上的热修复分支主题：

维护或“修补程序”分支用于快速修补生产版本。热修复分支与发布分支和功能分支非常相似，只是它们基于master而不是develope。这是唯一一个应该直接从主分支分叉的分支。一旦修复完成，它应该合并到master和developer（或当前版本分支）中

这只是对GitFlow类型的分支模型的一个建议，您可以在再次稳定

开发
分支时使用它

我能想到的避免从另一个功能分支创建功能分支的唯一原因是，试图避免从不稳定的分支分叉（这不是您的情况），并且在遵循GitFlow或类似工作流时，尽量保持历史记录的整洁。但这是相对的，因为一天结束时Git上的内容是链接提交，而不是清除分支。此外，没有真正的限制来阻止您从回购协议中的任何分支/提交中分叉
功能
分支

关于开发分支，为了稳定它，我建议在
develope
上进行最后一次已知的稳定提交，然后
将
master
的头合并到
develope
分支中，如果您确定
master
是稳定的。在Git历史上，它可能看起来并不漂亮，但可能会起到作用小心，在确定更改之前不要推送更改。
功能分支不错，关键是如何利用它们

在生产环境中，您最多需要一个分支用于可部署代码，另一个分支用于测试。为了跟踪更改以及这些更改是否有效，您可以进一步将更改与开发分支隔离开来。正如您所指出的，有人引入了错误的代码，所以您应该防止这种情况发生

以以下为例：

主分支-生产就绪代码
开发分支-测试分支

功能监测

增强SQLAlerts
臭虫

特性兼容性patch

错误版本软件

请注意，这些特性现在是广泛的代码类别，分支是单独的sprint。一旦内部sprint完成，我们可以在功能分支中将它们合并在一起，证明它们的有效性，然后再合并到我们的开发分支中，我们可以在测试环境中部署它们

所以特性很好，可以用来封装工作，同时保持工作的重点
 嗯，从技术上讲，你可以，有时你应该。主要的经验法则是，如果功能B依赖于为功能A所做的一些工作，那么应该在
feature/A
的适当点创建
feature/B
分支。但也有明显的警告：回购管理员的分支方式本质上使
feature/B
依赖于
feature/a
的命运。因此，如果
功能/A
出现问题，同样的问题也会影响
功能/B
。为了避免连锁问题，您应该清楚地了解这两个功能的发布计划。有时，建议将
feature/a
的当前状态合并回发布分支（如果足够稳定），然后继续独立处理这两个功能。谢谢！这是一个非常有意义的评论