我们在编写新故事时使用以下Git工作流：
创建主（生产/稳定）的主题分支
创建尽可能多的提交以实现功能。
执行git合并——将主题分支压缩到qa分支上。
质量保证人员审查。
如果良好，代码将合并到UA分支中。如果用户接受团队祝福它，它将被合并为master并最终部署。
如果审查失败，开发人员需要修复。基本上在步骤2重新启动进程。
注意：从点代码合并到qa分支和qa拒绝/接受它的时间开始，它可能长达两周。
如果没有问题，那么代码最终会成为master。但是，我正在寻找当qa发现问题并且您必须修复它时的最佳实践。我想要的是一个尽可能看起来“原始”的qa分支。
在我看来，有以下几种选择：
在qa分支中还原原始的挤压提交，将主题分支从qa中移除，修复主题分支中的代码，将其再次合并到qa中。问题：将icky revert commit留在周围。
删除现有的主题分支，从QA分支重新创建它，创建一个简单的提交来修复问题，合并到QA中。问题：在不同的时间和地点将特性的代码更改分散到提交中。
取消与QA的压缩合并，重新将个别提交从QA提交到现有主题分支，修复另一个提交，合并到QA中。问题：多个提交使跟踪更改变得很困难，因为它们会移动到UA分支，然后再移动到主分支。
问题：当合并的代码可能需要修复时，是否存在通过多个长寿命分支（master->topic->qa->ua->master）移动单个功能的多个提交的最佳实践？
最佳答案
根据经验，保留一个分支来修复qa、ua或master中发现的问题的想法并不太好，因为它是人为地将（在同一个分支内）最终成为不同的开发工作联系在一起的。
在“qa”之后修复的bug通常比在“ua”或“master”中发现的更简单（因为在开发生命周期中发现得更快）。
因此，我将使用2.，但是没有“删除主题分支”部分，只使用“创建新主题分支”来完成开发周期中需要执行的特定修复/演进。