基于git的代码版本管理规范及流程-简版

基于git的简单实用的版本管理规范及流程，包括：代码库的分布、人员角色的划分、代码提交合并流程、代码冲突处理、分支管理。

代码库分类

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

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

人员角色分类

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

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

基本流程

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

1. 开发人员从主库fork出自己的个人代码库。
2. 开发人员将自己的个人代码库clone到本地，即个人工作库。
3. 开发人员在开发了新代码后（包括新增和修改），先将代码commit到自己的个人工作库，再由个人工作库push到个人代码库。
4. 开发人员提交从个人工作库到主库的MR，Committer审核后，决定是否将MR合入主库。
5. 每个开发人员从主库pull最新代码到个人工作库。

分支管理

• 主库缺省的master分支，是用来向生产环境发布的，所有合入的代码，原则上都必须是稳定的。
• 主库除了master分支外，至少还要有一个活动分支，命名建议为：br_工程名_active，平时日常的开发都基于活动分支开发。即从个人工作库提交MR到主库时，指向的是主库的活动分支。活动分支测试稳定后，将主库的活动分支通过MR的形式，合并到主库的master分支，同时打上tag。
• 如果软件运行过程中发现必须立即修改的bug，则从主库的master分支中，拉出一个bugfix分支。为修复这个bug的所有开发，都基于bugfix分支。待bugfix分支开发完成，并测试稳定后，将bugfix分支以MR的方合入主库的master分支。然后删除bugfix分支，视情况决定是否打tag。

常见问题

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

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

产生原因

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

解决方法

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