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

Question

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

1. 从 master（生产/稳定）创建一个主题分支
2. 根据需要创建任意数量的提交来实现功能。
3. 将该主题分支的 git merge --squash 到 qa 分支上。
4. QA 人员进行审查。
5. 如果好的话，代码会被合并到ua分支中。如果用户验收团队认可，它就会被合并到 master 并最终部署。
6. 如果审核不通过，开发商需要修复。本质上是在步骤 2 中重新启动该过程。

注意：从点代码合并到 qa 分支到 qa 拒绝/接受它的时间可能长达两周。

如果没有问题，那么代码最终将成为主控。但是，我正在寻找 QA 发现问题并且您必须修复它时的最佳实践。我想要的是最终让一个 qa 分支看起来尽可能“原始”。

在我看来，以下是选项：

1. 在 qa 分支中恢复原始压缩的提交，从 qa 重新调整主题分支，修复主题分支中的代码，再次将其合并到 qa 中。问题：留下令人讨厌的恢复提交。
2. 删除现有的主题分支，从 qa 分支重新创建它，创建一个简单的提交来修复问题，合并回 qa。问题：将功能的代码更改分散到时间和地点不同的提交中。
3. 取消对 qa 的压缩合并，将单个提交从 qa 重新调整到现有主题分支，用另一个提交修复，合并到 qa 中。问题：多次提交使得在移动到 ua 分支然后再到 master 时跟踪更改变得困难。

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

Answer 1

根据经验，保留一个分支来修复 qa 或 ua 或 master 中发现的内容的想法不太好，因为它人为地链接在一起（在同一分支内），最终导致完全不同的开发工作。
您在“qa”之后修复的错误通常比“ua”或“<代码>主控'。

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