多个团队共同维护同一个微服务模块时，经常出现A团队已发布的功能，B团队提交测发布出现冲突或缺失，如何有效解决多团队共同维护的问题呢？

常用的版本管理工具有GIT、SVN，这两种版本管理工具，各有千秋；虽然有这些优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大的挑战，在同一个仓库上，彼此的代码协作必然带来很多问题和挑战。推荐使用Gitlab搭建自己GIT服务。

团队使用GIT作为版本管理工具，在日常协同开发过程中要共同遵守一定的工作流程，常见的工作流有：集中式工作流、功能分支工作流、Forking工作流、Gitflow工作流（推荐）等，根据团队规模、实际研发场景制定合理的工作流，能有效提高项目管理水平和团队协同开发能力。

下面结合实际实践重点介绍两种工作流程，最后介绍如何有效解决多团队共同维护同一模块时的版本冲突。

Forking工作流

Forking工作流最大特点是每个开发人员都有一个从公共仓库fork出来的属于自己的公共仓。Forking工作流适合外包、众包以及众创和开源场景。接包方的开发人员从项目公共仓fork自己的公共仓库进行操作，并不需要被项目公共仓直接授权，Forking工作流如下图所示。

Gitflow工程流

Gitflow一般用于管理大型项目，它为不同的分支分配一个很明确的工作角色，并定义分支之间什么时候进行交互，如Gitflow工作流如下图所示

按功能特性、进度时间节点对版本划分为:主分支(master/main)、开发分支(develop)、功能分支(feature)、发布版本(release)、修复分支(hotfix)

master/main分支

生产分支，最稳定的版本，一直是ready to deploy状态。受保护，只允许合并，不接受开发人员直接commit，只接受从其他分支merge操作。该分支只有维护者可以操作。

分支命名建议：master 或 main Gitlab默认使用main分支

develop分支

从master分支拉取的开发分支，用于功能集成。包含所有要发布到下一个Release的代码用于开发集成、系统测试。该分支是功能最新最全的分支，多团队维护时只允许合并。

分支命名建议：develop 或 develop-产品名称

feature分支

开发者使用的特性分支，父分支是develop分支，当新功能完成时，合入develop分支。新功能提交从不直接与master分支交互。不保留该分支

分支命名建议：feature-产品名称 或 feature-产品名-v产品版本号

release分支

临近既定的发布日，就从develop分支上拉取一个release分支，任何不在当前分支中的新功能都推到下个发布中。release分支用于发布，所以从当前时间点之后新的功能不能再加到这个分支上，这个分支只做Bug修复、文档生成和其它面向发布的任务。当对外发布的工作都完成了，release分支合并到master分支并分配一个版本号打好Tag；另外，这些从release分支新做的修改要反向合并回develop分支。不保留该分支

分支命名建议：release-产品名称 或 release-产品名-v产品版本号

hotfix分支

从master分支拉取的临时修复分支，用于解决一线紧急bug。bug解决后需要合入master分支并打上新的版本号，这个修改也需要同时合入develop分支。不保留该分支

分支命名建议：hotfix-* 例如：hotfix-v2.3.1.220110

Gitflow扩展工作流

针对多团队共同维护且功能差异较大的项目采用Forking工作流+Gitflow工作流相结合，例如多团队共同维护同一个前端项目(前端未做微前端），各团队需要各自维护自己的开发分支，Gitflow工作流进一步扩展，流程如下图所示

工作流程要点

A、每个团队各自维护自己的开发分支(develop)

B、每次版本提交前需要从master/main分支合并到当前开发的分支，而后创建release测试分支。

C、版本测试验证成功后，及时把可发布的release分支合并回master/main分支以及自己团队的开发分支(develop)

通过这种工作方式，多团队共同维护同一模块时，提测时能合并其它团队已发布的功能，保证测试版本功能的齐全，且能测试验证合并后的功能点。

结束

多团队协作，需要制定共同的遵守准则规范，并结合培训强化团队成员的流程意识。另可以通过Gitlab结合Jenkins、k8s实现持续集成、持续交付和快速迭代的目标。

如果在日常工作过程中遇到相似的问题，关注我，一起沟通探讨；