Git/SCM工作流程:在QA发现问题时处理更改

Question

我正试图将我们的组织从SVN切换到Git.现在我们的工作流程看起来像这样:

1. 开发人员进行更改,然后提交到Beta分支
2. 质量检查发现错误,然后告诉开发人员修复它们
3. GOTO 1.重复至少5次.(我们没有测试套件.另一个问题......)
4. 同行代码审查
5. 在sprint结束时,分支管理器将标记为就绪的所有代码合并到主分支中.

我认为Git可能对第4步和第5步有很大的帮助.具体来说,当有10次提交时,同行代码审查非常困难,可能会有大量的提交*.我知道使用Git很容易还原提交,可能会为每个功能/错误创建一个提交来审核.引导我提出我的问题:

对于涉及冗长QA来回的场景,最好的Git工作流程是什么？

请记住,我遇到了一些变化的阻力,因此工作流程越简单,就越有可能被采用.还要记住,这是一个Web开发项目,因此QA针对Beta服务器进行测试,而不是本地测试,因此QA交换分支并不是真正的选择.

*意思是,在此错误提交的提交之间可能存在来自同一文件上的其他错误票据的提交,与之前的状态进行简单比较,并且难以隔离此票证的代码更改.

Answer 1

如果您列出了更具体的工作流程目标，您的问题会更容易回答。让我感到奇怪的是，您在同行代码审查之前就参与了质量检查，而最佳实践却给出了相反的建议。

然而，从您对恢复提交的参考来看，听起来您的主要目标之一是避免肮脏的历史记录，其中充满了诸如“哎呀，QA 刚刚指出我搞砸了上一次提交，这个修复了它”之类的提交”。如果是这样，您应该熟悉 git 强大的历史重写功能 - 特别是通过 .gitignore 压缩、分割、重新排序、删除提交git rebase -i。这些可用于为每个新功能或错误修复生成一​​组干净、简洁的提交，从而使同行评审和所有未来对历史记录的重新阅读变得更加容易。我不会详细介绍如何执行此操作，因为无数 其他 地方对此进行了介绍。

您还应该强烈意识到何时可以安全地变基（通常仅在“私有”分支中）和不安全（“公共”）分支，以及打破该经验法则的影响。但是，在您描述的场景中，听起来 QA 不参与测试服务器使用的存储库的设置，在这种情况下它可能是安全的。

其次，您应该确保每个功能或错误修复始终有一个分支。这将大大减少您当前在同行评审和合并时面临的困难，因为每组逻辑相关的更改都将被完全隔离，而不是与不相关的更改混合在一起 - 后一种情况将混淆评审和 QA 流程并破坏其稳定性。有一些人喜欢的更复杂的 git 分支工作流程，但如果您担心吓到同事而放弃迁移到 git，那么听起来您现在应该避免使用这些工作流程。即使是像 github 这样庞大而复杂的组织也更喜欢更简单的工作流程。