【项目管理】：过度的“自由”，“无序”的Git是灾难的开始

2022-07-18 本文已影响0人程序老秃子

前言

仓库的分支(Branch)规范，影响到每个团队的工作流的一致性与工作效率； 我们在实际工作中使用Git做代码管理工具时，经常会遇到这种情况： 项目需要稳步迭代升级的同时，定制化的需求与项目便接憧而至； 合理的使用Git不仅可以简化繁杂的研发工作，同时也可以提升QA，PM，OP等团队之间的协同效率。而过度的“自由”， “无序”则是一切灾难的开始......

1、Git代码库分类

根据代码库分布的位置及作用，可分为以下三类：

主库：位于服务端（如github、gitee等），所有开发的代码最终都要合到主库
个人代码库：位于服务端（如github、gitee等），从主库fork出来。每位研发人员自已负责自己的代码，由本地的git库push到个人代码库，再由个人代码库合入主库
个人工作库：位于每个研发人员的本地开发机器上，代码从个人代码库clone到本地。每位研发人员开发的代码，先commit到个人工作库，再由个人工作库push到个人代码库

2、Git人员角色分类

该小节中提及的角色，都是作用于主库上的。基于简化的原则，人员分为三类：

Owner：拥有主库的所有权限
Committer：具有将开发人员的合并请求MR合入主库的权限。（ps：通常基于安全考虑，我们设置为只能通过MR的方式将代码合入主库，而不能直接push到主库）
Developer：只能从自己的个人代码库提交合并代码请求MR，是否能够合入则由Committer进行确认

Committer在进行MR之前，可以对Developer提供的代码进行review

3、Git分支管理

master/main：与生产环境保持同步，该分支代码都必须是稳定的，禁止直接向该分支提交代码
develop ：持续开发的分支，每个开发人员都应该在这个分支上保持线性的小步迭代。通常CodeReview 与开发级的自动CI也在该分支进行。当完成一个迭代(Sprint)的开发工作，并通过了自测、单元测试后，需要将该分支代码合并到release分支，并要求打一个alpha级的Tag(如5.2.0-alpha)
hotfix（hotfix-前缀）：如果软件运行过程中发现必须立即修改的bug，则从主库的master/main分支中，拉出一个hotfix分支并指定bug修复版本。待hotfix分支的开发，验收工作完成后，需要以mr的方式合入master/main分支。并将该hotfix分支上的更新合并到dev分支（hotfix分支完成使命后，可以选择删除或保留）
release（release-前缀）：顾名思义即用于发布过程的分支，包括集成测试，修复bug，回归测试以及发布上线的过程。当发布版本时要打一个发布beta级的Tag(如5.2.1-beta)，并将代码合并到 master/main分支。在测试过程中发现的问题需要在release分支上进行修改，并且将修改后的更新合并到dev分支
feature（feat-）：添加一个新功能时，通常我们不希望因为一些实验性质的代码将当前的协同研发分支搞乱，因此每添加一个新功能时，可以在dev分支上拉取一个新的feature分支。当新功能研发完毕后（完成了主体功能和大部分测试与bug修复工作），将该分支上的更新合并到dev分支上，并可选性的删除该分支