超实用的代码版本管理规范流程-代码版本管理规范

版本管理(Revision control)是一种软件工程方法，在开发的过程中，确保由不同开发人员编辑的同一档案都得到更新。代码版本管理其实就是我们在日常的开发过程中，将每天、每个阶段、每个功能等要求完成之后，将我们的代码再提供给他人的一种行为。

这个行为的目的就是，让每一个人的开发过程都有据可查，最后实现多人合作开发的目的。

目前市面上比较流行的是通过 Git 进行代码版本管理，因为它易于学习，占用内存小，具有闪电般快速的性能，

规范且流程化的版本管理，不仅能有效的提升代码质量，而且还能帮助项目团队有序协同，轻松提升研发效能，那么Git 代码版本管理的规范化流程有哪些呢?

基于 Git 的代码版本管理主要包括：代码库的分布、人员角色的划分、代码提交合并流程、代码冲突处理、分支管理。

代码库分类

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

主仓库：位于服务端，所有开发的代码最终都要合到主仓库。
个人代码库(服务端)：从主仓库 fork 出来，位于服务端。每个人自已开发的代码，由本地的 Git 库 push 到每个人自己的个人代码库(服务端)，再由个人代码库(服务端)合入主仓库。
个人工作库：位于每个开发人员的开发机器，从个人代码库(服务端)clone 到本地。每个开发人员开发的代码，先 commit 到个人工作库，再由个人工作库 push 到个人代码库(服务端)。

人员角色分类

这里说的角色，都是人员在主仓库上的角色。基于简化的原则，人员分为三类：

Owner：拥有主仓库的所有权限。
Committer：具有将开发人员的合并需求(PR)合入主仓库的权限。基于安全考虑，我们设置为只能通过 PR 的方式将代码合入主仓库，而不能直接 push 到主仓库。
Developer：只能从自己的个人代码库(服务端)提交合并代码的请求(PR)，是否能够合入，由 Committer 进行审核。

以 Gitee 企业版为例，Developer 进行 PR 后有权限的 Committer 需要对代码进行审查，审查通过后方可进行合并。

基本流程

在主仓库已经存在的情况下，日常操作流程如下：

分支管理

主仓库缺省的 master 分支，是用来向生产环境发布的，所有合入的代码，原则上都必须是稳定的。
主仓库除了 master 分支外，至少还要有一个活动分支，命名建议为：br_工程名_active，平时日常的开发都基于活动分支开发。即从个人工作库提交 PR 到主仓库时，指向的是主仓库的活动分支。活动分支测试稳定后，将主仓库的活动分支通过 PR 的形式，合并到主仓库的 master 分支，同时打上 tag。
如果软件运行过程中发现必须立即修改的 Bug，则从主仓库的 master 分支中，拉出一个 bugfix 分支。为修复这个 Bug 的所有开发，都基于 bugfix 分支。待 bugfix 分支开发完成，并测试稳定后，将 bugfix 分支以 PR 的方合入主仓库的 master 分支。然后删除 bugfix 分支，视情况决定是否打 tag。
在生产开发协作的实际过程中，出于内部控制的考量，往往需要自定义拥有某些关键分支推送(push)和合并(merge)权限的人群。

以 Gitee企业版为例，可以采用「分支状态」中的「保护分支」功能。被设为保护分支之后，该分支只允许对应的「保护分支规则」内选中的仓库成员对此分支进行合并/推送操作。

常见问题

此部分内容会根据情况进行相应的增加。

活动分支合入主分支时发生冲突

产生原因

平时基于活动分支开发，如果这个过程中为了修复 Bug 而拉了一个 bugfix 分支，当 bugfix 分支开发完成并合入 master 分支后，如果 bugfix 分支和活动分支修改了相同的文件，则在活动分支合入 master 分支时就会产生冲突。

解决方法

不单是在研发团队的工作中，在开源项目中也同样需要规范的版本管理。而对初学者而言，我们建议在开始进行实践小项目的阶段即进行规范的版本管理，因为在以后的工作中代码版本管理将会是一项非常重要的技能。