5

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

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

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

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

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

*意思是，在此错误票的提交之间，可能有来自同一文件上的其他错误票的提交，这使得与之前的状态进行简单比较并隔离此票的代码更改变得困难。

4

3 回答 3

3

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

但是，从您对恢复提交的引用来看，听起来您的主要目标之一是避免肮脏的历史，其中充满了标题为“哎呀，QA 刚刚指出我搞砸了最后一次提交，这个修复了它”之类的提交”。如果是这样，您应该熟悉 git 强大的历史重写功能 - 特别是通过git rebase -i. 这些可用于为每个新功能或错误修复生成一​​组干净、简洁的提交，从而使同行评审和所有未来的历史重读变得更加容易。我不会详细介绍如何做到这一点，因为它在无数 其他 地方都有介绍。

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

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

于 2012-08-09T22:24:44.050 回答
2

每次我看到一篇关于 Git 工作流的帖子，我都会忍不住将它们推荐给 Vincent Driessen 的优秀文章 A successful Git branching model。我第一次读到这篇文章时，一个灯泡亮了，我意识到这种方法几乎可以成为任何项目的基础。

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

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

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

于 2012-08-09T22:41:04.147 回答
1

我把我的公司从 SVN 搬到了 Git，在这个过程中学到了很多关于 Git 的知识。自从那次搬迁以来，我已经看到我们的工作流程在大约 3 年的时间里不断发展和变化……基于此，也基于在我自己的个人共享项目中使用 Git：

nvie模型很棒。我将它用于我自己的项目，那里只有 2-3 个人并且喜欢它。但是，除非每个提交代码的人都是高级 Git 用户，否则我不会建议更大的团队使用它。它将很多责任放在人们从正确的地方切割分支，合并到正确的地方并且通常“做正确的事情”。实际上，在一个庞大的团队中，会有几个人不会理解 Git，记住一些命令，最终会影响整个计划。如果你现在对改变有抵抗力，这只会在它爆发时变得更糟（而且它会）。

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

  • Beta从主人那里剪下一个分支
  • 做工作。Git 不会让您免于开发人员草率并推送未经测试/未经审查的代码。但是，这将使开发人员有机会在他们推送代码之前纠正他们所犯和注意到的任何错误（变基或修改提交）
  • 假设您有一个dev分支......其他开发人员可以在那里推送开发代码
  • 什么时候Beta好做，把它合并到masteranddev中。
  • 对于下一个版本，Beta从您的分支中剪切一个新dev分支并重复。

所以，你并没有放慢任何人的速度，因为人们总是可以提交dev. 您还有一个发布候选 ( Beta) 分支，它只修复错误。

Git 在这里也可以提供帮助，因为您不一定需要在进行代码审查之前推送您的代码。我们使用审查委员会和工作方式，您在本地提交代码并发布审查。当您收到反馈时，您可以简单地更新您的代码git commit --amend并更新您的评论。完成后，我们推送一个提交而不是n.

从您的描述看来，单元测试和开发人员对质量代码的更多责任现在是一项更好的投资。Git 本身并不能解决您的问题，但它至少可以提供帮助。关于如何使用 Git 之类的 DVCS 设置开发过程，您将有更多选择。让我们面对现实吧……Git 比 Subversion 更有趣。:>)

于 2012-08-10T03:34:24.650 回答