场景 - 使用 git-flow 或类似：
在进行工作流时，我们意识到已经开发的功能之一(在功能分支中并已合并到开发分支中(需要紧急热修复，然后才能准备好其他正在开发的工作。
实现这一目标的最佳实践是什么？
在 git-flow 中，修补程序通常使用主节点的修补程序分支来完成。为了遵循该模型，我想知道从开发到修补程序分支的挑选是最好的，还是在合并功能分支以开发并将这些分支合并到修补程序分支(或主分支(后保留功能分支？还是别的什么？
首先，我想强调的是，"好的工作流程"一般不存在，"好的工作流程"是你觉得方便使用的工作流程。
也就是说，我个人认为有两种情况：
- 该修补程序是微不足道的(例如在代码中将"版本 A"替换为"版本 B"(，然后我不会为此创建专用分支(或者至少，我会使用快进进行合并(
- 此修补程序需要相当多的工作，然后创建一个分支来保存这些开发人员是简化审查和识别此 bug 修复所拉动的所有工作的好方法。这可能有助于以后执行非回归测试。
如果您是 git 存储库的所有者，您还可以通过禁止合并"几乎良好"功能来"重写历史记录"，并修复该功能以稍后重新合并它。这通常不会被称赞为"改变历史"，但如果你只是代码的几个开发人员，并且每个人都很好，这是一种可能性。