修改已合并的git主题分支的最佳实践

Question

我们在编写新故事时使用我公司的以下git工作流程：

1. 从主人（生产/稳定）
创建主题分支
2. 根据需要创建尽可能多的提交以实现功能。
3. 执行git merge - 将该主题分支定格到 qa 分支。
4. QA人员评论。
5. 如果好，代码将合并到ua分支中。如果用户接受团队对其进行祝福，则会将其合并为主人并最终部署。
6. 如果审核失败，开发人员需要修复。基本上在步骤2重新启动该过程。

注意：从点代码合并到qa分支可以最多两周，qa拒绝/接受它。

如果没有问题，那么代码最终会成为主人。但是，我正在寻找QA发现问题并且您必须解决问题的最佳实践。我想要的是最终得到一个看起来像“原始”的qa分支。

我认为，以下是选项：

1. 在qa分支中恢复原始压缩的提交，从qa的rebase主题分支，修复主题分支中的代码，再次将其合并到qa中。问题：叶子icky还原提交。
2. 删除现有的主题分支，从qa分支重新创建它，创建一个简单的提交来修复问题，合并回qa。问题：在时间和地点不同的提交中传播功能的代码更改。
3. 废除对qa的压缩合并，将个人提交从qa转换为现有主题分支，修复另一个提​​交，合并到qa。问题：多次提交使得很难跟踪变化，因为它们会转移到ua分支然后再转移到master。

问题：当合并代码可能需要时，是否有通过多个长期分支（master - ＆gt; topic - ＆gt; qa - ＆gt; ua - ＆gt; master）移动单个功能的多个提交的最佳实践固定？

Answer 1

根据经验，保持一个分支来修复qa或ua或master中发现的内容的想法并不顺利，因为它人为地连接在一起（在同一分支内）最终完全是不同的开发工作。
您在“qa”之后修复的错误通常比在“ua”或“master”中找到的错误（因为在开发生命周期中发现的更快）。

所以我会选择2.但没有'删除主题分支'部分，只需要为开发周期中需要执行的特定修复/演变创建“创建新主题分支”。