git branch工作流程政策

Question

我是git的新手，对Git有所了解。
我公司目前有1个程序，该程序分为5个产品。每个产品由不同的团队处理。

目前我公司的git有5个分支机构，例如：

• dev =此分支供开发人员构建程序（dev.program.com）
• test（alpha）=该分支供测试人员测试程序（test.program.com）
• staging（beta）=此分支供测试人员测试程序（错误的双重检查），并由客户端测试程序。 （stg.program.com）
• staging-trx =分段的副本，供开发人员确保在将其用于生产之前从分段中挑选樱桃时确保没有错误冲突。 （stg-trx.program.com）
• master =从staging-trx合并并准备投入生产（master.program.com）

这是我们的工作流程。

1. 开发人员完成程序的构建，开发人员将提交文件并将其推入测试分支，然后测试人员将对测试环境进行压力测试。
在测试人员完成压力测试之后，开发人员进行拉动，从测试分支中挑选已提交的文件，然后推入暂存分支。之后，测试人员将进行Flash测试。
2. 测试人员完成Flash测试后，开发人员进行拉动，从暂存分支中提取已提交的文件，然后推入staging-trx分支，然后开发人员将staging-trx合并到master分支中。

但是我有一些问题。

假设一个团队中有2个开发人员（Andy和Robert）并负责产品A。

• Robert正在处理新功能并修复了错误
• Andy正在修复错误

当前，Robert仍在构建一个新功能，该新功能将影响某些文件和代码的重大更改。因此Andy不能进行任何代码修订来修复该错误，因为几乎所有代码都已更改。

如果我为每个新功能都创建了新分支，则测试人员会发现很难进行测试，而且还会有更多的网站仅针对新功能创建。这意味着不仅对于产品A，还有其他产品也将面临相同的问题。

那么，这种情况有什么解决办法吗？

Answer 1

这通常是gitworkflow地址

仅合并feature个分支，而不是合并A到B，B到C，C到D等。

每个开发人员（或一组开发人员）都在feature分支上工作，并将其合并到dev进行集成测试。

但是要合并到其他开发生命周期步骤中（针对您的情况进行测试，然后进行分阶段测试，然后选择您想要的任何名称），则请勿将dev合并到test < / strong>

您将选定的feature分支（最初合并到dev）合并到所需的分支（测试，暂存等）

那样，您只选择您认为已准备好并且可以一起使用的功能子集，而不是尝试将dev的“未准备就绪”功能还原，然后将dev合并到{ {1}}。

我detail that model further here和illustrate it here

一个重要点：test分支（用于将dev分支集成在一起）是 transient ：它是为每个新发行版创建/销毁的（相对于一个固定的发行版）永恒的feature分支有时会合并到dev中。

您将重新创建需要一起测试功能（开发，测试，登台等）的许多集成分支。
然后，准备就绪后，只需将右侧的master分支合并到feature（或任何其他master分支），删除您的release分支，并为下一个版本重新创建

因此重复：

dev分支被多次合并：

• 一次feature进行初始集成测试，
• 然后将同一dev分支再次直接合并到feature中（可以进行第二次构建，而不必在test中进行重建），
• 然后直接在feature中再次合并（每次，因为认为staging分支已准备好进入下一个生命周期开发阶段）

您不是从feature到test采摘樱桃。
您合并了staging分支，该分支已将feature传递到集成生命周期的下一步（将test合并到feature分支）

---

  

当前Robert仍在构建新功能，该新功能将影响某些文件和代码的重大更改。
  因此Andy不能对代码进行任何修订以修复该错误，因为几乎所有代码都已更改。

是的，Andy可以在staging分支中致力于维护发布到生产环境中的最新代码。
Robert和Andy都可以参与该分支，如果在那里需要该修复程序，他们将负责将其修订提交应用于hotfix（由于代码已更改，也许该错误修复程序与{{ 1}}）

  

安迪会从热分支合并到测试吗？因为我们的最后一步是dev => dev => test => staging

此答案的全部目的是说明您不必从staging trx合并到master再合并到A。
对于B分支，您很少将其合并到其他任何地方，因为C或hotfix分支的代码自上一发行版以来已经有了很大的发展。您只需 cherry-pick ，即可将所需的修订提交回dev或test。

---

  

dev已经在test环境中之后，我将销毁该feature分支吗？

好吧...是的，“破坏” production分支将删除指向该分支的指针。
但是从feature完成的合并提交中仍然可以看到属于该分支的实际提交。没关系，这对于以后调试该功能很有用：代替大的最终合并提交，您以后可以检查来自所述合并提交的第二个父提交的提交：它们是来自旧功能分支的提交。

---

  

虽然新的feature分支已经在master分支中，并且测试人员仍在对新的feature A进行压力测试，但是生产中存在错误，Andy会修复{{ 1}} test分支中的错误。

     

问题是，在Andy修复了feature A分支中的错误之后，Andy应该在哪里合并当前的修补程序分支？
  因为如果存在错误，并且开发人员已修复了该错误，它将无法直接投入生产，因此测试人员将首先进行测试，以检查该错误是否已经真正修复。

您将需要专门用于测试修补程序的 second feature B分支（不过我会直接在hotfix上进行测试），然后合并回hotfix ，以更新产品。
关键是：当您确定并行开发工作时（例如在“测试功能分支”和“测试修补程序”中），需要单独的分支。

但是，对于错误修复，这又是典型的“紧急路径”，对于这种情况，您具有较短的分支工作流程和专用的test分支（根据需要命名）。 / p>

另一种方法是简单地{em>重置 hotfix分支，然后仅合并紧急需要的分支（在这种情况下为master）：测试，合并{ {1}}到暂存等...一直到test-hotfix。
最后，test准备就绪后，您可以使用同一测试分支重新添加（合并）feature B，并在B的环境中继续在master上进行测试已经被验证。

重置测试的缺点是尽管它会阻止所有其他开发集成。
这就是为什么最好使用专门的分支。