git分支工作流策略

我是git新手，对git有一点了解。
我公司目前有1个项目，项目分为5个产品。每个产品由不同的团队处理

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

• dev=此分支用于开发人员构建程序（dev.program.com）
• test（alpha）=此分支用于测试人员测试程序（test.program.com）
• staging（beta）=此分支用于测试人员测试程序（双重检查错误）和客户端测试程序。（stg.program.com）
• staging trx=staging的副本，用于开发人员确保在将staging服务于生产之前从staging中选择时没有错误冲突。（stg trx.program.com）
• master=从暂存trx合并并准备生产（master.program.com）

这是我们的工作流程。

开发人员完成了一个程序的构建，开发人员将提交并将文件推送到测试分支，然后测试人员将在测试环境中进行压力测试

测试人员完成压力测试后，开发人员从测试分支中提取提交的文件，并将其推送到临时分支中。之后，测试人员将进行闪光测试

在测试人员完成flash测试后，开发人员从staging分支中提取提交的文件并推入staging trx分支，然后开发人员将staging trx合并到master分支中

但是我有一些问题

假设在一个团队中有两名开发人员（Andy和Robert）负责产品A

• Robert正在处理新功能和错误修复
• 安迪正在处理修复的bug

目前，Robert仍在构建一个新功能，该新功能将影响一些文件和代码的主要更改。所以Andy不能修改代码来修复bug，因为几乎所有的代码都已更改

如果我为每个新特性创建新的分支，测试人员会发现很难测试，而且会有更多的网站只为新特性创建。这意味着，不仅是产品A，还有其他产品将面临同样的问题

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

这通常是什么地址

您只合并

功能

分支，而不是将A合并到B、B合并到C、C合并到D等等

每个开发人员（或开发组）处理一个

功能

分支，并将其合并到

dev

进行集成测试

但是，当涉及到合并到其他开发生命周期步骤时（在您的情况下进行测试，然后是登台、qa、任何您想要的名称），您不会将

dev

合并到

test

将选定的

功能

分支（最初合并到

dev

）合并到所需的分支（测试、暂存等）

这样，您只需选择您认为已准备好并协同工作的功能子集，而不是尝试从

dev

还原“未准备好”的功能，然后将

dev

合并到

test

我和

重要的一点是：

dev

分支（用于将

功能

分支集成在一起）是暂时的：它是为每个新版本创建/销毁的（而不是一个固定的

dev

分支不时合并到

master

）

您可以根据需要重新创建多个集成分支来共同测试功能（开发、测试、登台等）。
然后，准备就绪后，您只需将右侧的

功能

分支合并到

主版

（或任何其他

发行版

分支），删除

开发版

分支，然后为下一个发行版重新创建它

因此，请重复：

功能

分支被合并多次：

• 一次到

  dev

  进行初始集成测试
• 然后，相同的

  功能

  分支再次直接合并到

  测试

  中（如果可能发生第二次生成，则不必在

  功能

  中重新生成）
• 然后在

  staging

  中再次直接合并（每次都是因为

  功能

  分支被认为已准备好进入下一个生命周期开发阶段）

您不需要从（例如）

test

到

staging

将通过

测试的
功能
分支合并到集成生命周期的下一步（将
功能
合并到
暂存
分支）


目前，Robert仍在构建一个新功能，该新功能将影响一些文件和代码的主要更改。

所以Andy不能修改代码来修复bug，因为几乎所有的代码都已更改

是的，Andy可以在一个
热修复
分支中，专门维护发布到生产中的最新代码。

Robert和Andy都可以参与该分支，如果需要所述修复，他们将负责将其修复提交应用到
dev
（由于代码已更改，可能该错误修复在
dev
中不再相关）

Andy是否将从热分支合并到测试？因为我们的最后一步是
test
=>
staging
=>
staging trx
=>
master

这个答案的全部要点是说明您不必从
A
合并到
B
到
C


对于
hotfix
分支，您很少将其合并到其他任何地方，因为
dev
或
test
分支的代码自上次发布以来已经有了很大的发展。您只需修复程序将您需要的提交回
dev
或
test


在
功能
已经进入
生产环境
后，我将销毁该
功能
分支，对吗

好的