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

如果您列出了工作流程的更具体目标，那么您的问题将更容易回答。当best practices advise the opposite在同行代码审查之前你参与质量保证时，这也让我感到奇怪。

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

您还应该强烈了解何时可以安全地进行rebase（通常只在“私有”分支中）和不安全（“公共”）分支，以及违反经验法则的含义。但是，在您描述的场景中，听起来像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的develop分支）。因此，您修改的工作流程将是：

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

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

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），它只能修复bug。

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

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