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

Question

我正试图将我们的组织从SVN转换为Git。现在我们的工作流程基本上是这样的：

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

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

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

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

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

Answer 1

如果您列出了工作流程的更具体目标，那么您的问题将更容易回答。在best practices advise the opposite {<3}} 同行代码审核之前，您参与QA 这一点很奇怪。

然而，从你提到的恢复提交，听起来你的主要目标之一就是避免一个脏的历史，这个历史充满了像“oops，QA刚刚指出我搞砸了最后一次提交的事情的提交，这个一个修复它“。如果是这样，你应该熟悉git强大的历史重写功能 - 特别是压缩，拆分，重新排序，通过git rebase -i删除提交。这些可以用于为每个新功能或错误修复生成一​​个干净，简洁的提交集，使同行评审和所有将来重新读取历史记录更加容易。我不会详细介绍如何执行此操作，因为它已涵盖在countless other places中。

您还应该强烈了解何时可以安全地（通常只在“私人”分支机构）和不安全（“公共”）分支机构进行变革，以及违反经验法则的含义。但是，在您描述的场景中，听起来像QA没有参与beta服务器使用的存储库的设置，在这种情况下，它可能是安全的。

其次，您应该确保每个功能或错误修复总是一个分支。这将大大减少您在同行评审和合并时遇到的困难，因为每组逻辑相关的更改将被完全隔离，而不是与无关的更改混合 - 后一种情况会混淆和破坏稳定审查和质量保证流程。那里有much more sophisticated git branching workflows some people love，但如果您担心会让您的同事远离迁移到git，那么您现在应该避免使用这些内容。即使是像github prefers a simpler workflow那样又大又精致的组织。

Answer 2

每当我看到有关Git工作流程的帖子时，我都会情不自禁地将它们推荐给Vincent Driessen的优秀写作 A successful Git branching model 。我第一次看到它时，灯泡响了，我意识到这种方法几乎可以作为任何项目的基础。

由于您的是一个Web开发项目，只需让您的QA服务器拉出develop分支（或者如果您的开发服务器与QA分开，则从qa分支拉出{{1} }}）。因此，您修改的工作流程将是：

1. 开发人员对其develop或feature-X分支进行更改和提交。
2. 开发人员将功能或错误修正合并到bugfix-Y并推送到服务器。
3. QA发现错误，提交错误报告。
4. GOTO 1.重复X次。
5. 同行评审可以自动审查涉及特定功能的更改并批准/修改/拒绝它，因为每个功能的合并提交都指定了该功能的所有更改。
6. 在sprint结束时，分支经理将所有代码从develop合并到develop以进行QA以进行任何最终验证，或者直接进入release-candidate，如果不需要特殊的发布分支。

如您所见，可以调整方法以满足您的特定需求。工作流程相对简单，尽管您的开发人员需要习惯在feature / bugfix分支中工作并在完成时合并。

Answer 3

我将公司从SVN转移到Git，在此过程中学习了很多关于Git的知识。自那一步以来，我看到我们的工作流程在大约3年内发展和变化......基于此，并且基于在我自己的个人共享项目中使用Git：

nvie模型很棒。我将它用于我自己的项目，那里只有2-3个人并且喜欢它。但是，除非每个人提交代码都是高级Git用户，否则我无法为更大的团队提出建议。对于从正确的地方切割树枝，合并到正确的地方并且通常“做正确的事情”的人来说，它承担了很多责任。实际上，有一个庞大的团队会有几个人不会理解Git，记住一些命令，最后在整个计划中抛出一把扳手。如果你现在遇到变化的阻力，这只会在它爆炸时变得更糟（它会）。

从您的描述（当前或缺乏软件实践），Git将使您的生活更轻松的一种方式是将您的Beta分支与其他开发分支隔离开来。所以，你会：

• 从主
中剪切Beta分支
• 做好工作。 Git不会让你免于开发人员的邋and和推送未经测试/未经审查的代码。但是，允许开发人员有机会纠正他们所犯的任何错误，并注意之前他们推送了他们的代码（重新定位或修改提交）
• 假设你有一个dev分支......其他开发人员可以在那里推动开发代码
• 当Beta做得好时，请将其合并到master和dev。
• 在下一个版本中，从Beta分支剪切新的dev分支并重复。

所以，你没有减慢任何人的速度，因为人们总是可以提交dev。您还有一个候选发布版（Beta），它只能修复错误。

Git也可以在这里提供帮助，因为在进行代码审查之前，您不一定需要推送代码。我们使用Review Board及其工作方式，您在本地提交代码并发布评论。获得反馈后，您只需更新代码git commit --amend并更新您的评论即可。完成所有操作后，我们推送一个提交，而不是n。

从您的描述中听起来像是单元测试，对开发人员的质量代码的更多责任是现在更好的投资。就其本身而言，Git不会解决您的问题，但它至少可以提供帮助。关于如何使用像Git这样的DVCS设置开发过程，您将有更多选项。让我们面对现实...... Git比Subversion更有趣。产品：＆gt;）