场景 - 使用 git-flow 或类似的：
在进行一系列工作时，我们意识到已经开发的功能之一（在功能分支中并已合并到开发分支中）需要紧急修复，然后开发中的其他工作才能准备好。
实现这一目标的最佳实践是什么？
在 git-flow 中，修补程序通常使用 master 的修补程序分支完成。为了遵循该模型，我想知道从开发分支到修补程序分支的樱桃采摘是最好的，还是在合并这些分支以开发并将这些分支合并到修补程序分支（或主）后保留功能分支？或者是其他东西？
问问题
1082 次
1 回答
0
首先，我想强调的是，一般不存在“好的工作流程”，“好的工作流程”是你觉得使用起来方便的工作流程。
也就是说，我个人考虑两种情况：
- 修补程序是微不足道的（例如在代码中用“版本 B”替换“版本 A”），然后我不会为此创建专用分支（或者至少，我会使用快进进行合并）
- 修补程序需要做很多工作，然后创建一个分支来容纳这些开发人员是一种简化审查和识别此错误修复所带来的所有工作的好方法。这可以帮助以后执行非回归测试。
如果您是 git 存储库的所有者，您还可以通过禁止合并“几乎很好”的功能来“重写历史记录”，并修复该功能以便稍后重新合并它。这通常不会被称赞为“改变历史”，但如果你只是代码上的几个开发人员并且每个人都很好，那是可能的。
于 2018-10-03T19:13:59.240 回答