Git与项目管理

仓库的分支(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分支上，并可选性的删除该分支。

各个分支关系与运行方式如下图所示：

3.1 注意事项

• 通常我们团队习惯于将Tag打在release分支上的，master上不需要打Tag。当然这不是必须准寻的原则，可以根据实际情况自行选择。
• develop分支上的内容是通过release分支合并到master/main分支上的，要避免develop上的内容直接合并到master/main分支。

4、Git fork过程

（1） 开发人员从主库fork出自己的个人代码库。
（2） 开发人员将位于自己的个人代码库上fork的代码clone到本地，即个人工作库。
（3） 开发人员在完成代码的调整后（包括新增，修改，删除），先将代码commit到个人工作库，再由个人工作库push到个人代码库。
（4） 开发人员提交从个人代码库到主库的mr，Committer审核后，决定是否将mr合入主库。

fork流程示意图

4.1 注意事项

• 使用Git fork管理项目时，原则上fork的项目只接受来自主库上的更新合并请求，不接受将fork项目上的更新合并到主库的过程。（社区开源项目的pr方式则正好相反）

5. Git项目管理规范

Git使用的标准与否将直接影响到项目管理、CI/CD等工作的效率。一个较为完善的Git项目管理规范可参考下图：