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

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

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

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

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

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

代码库分类

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

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

人员角色分类

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

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

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

基本流程

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

• 开发人员从主仓库 fork 出自己的个人代码库。
• 开发人员将自己的个人代码库 clone 到本地，即个人工作库。
• 开发人员在开发了新代码后(包括新增和修改)，先将代码 commit 到自己的个人工作库，再由个人工作库 push 到个人代码库。
• 开发人员提交从个人工作库到主仓库的 PR，Committer 审核后，决定是否将 PR 合入主仓库。
• 每个开发人员从主仓库 pull 最新代码到个人工作库。

分支管理

• 主仓库缺省的 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 分支时就会产生冲突。

解决方法

1. 从个人代码库(服务端)clone 一个库到本地，即专门用于合并的个人工作库。(也可以用之前的个人工作库，但初学都容易混淆，建议单独 clone 一个。)
2. 从主仓库的活动分支上 pull 最新的代码到本地。
3. 从主仓库的 master 分支上 pull 最新的代码到本地。
4. 此时会产生冲突，手工修复冲突，然后先 commit 到本地的个人工作库，再 push 到个人代码库(服务端)。
5. 提交从个人工作库(服务端)到主仓库的 PR(此时不会再有冲突)，然后由 Committer 审核后将PR合入主仓库。

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