企业Git规范

本文介绍企业Git版本控制的逻辑，提高程序代码管理的效率
问题：1. 开发管理乱 2. 代码冲突过多 3. 代码质量过低 4. 代码管理效率不高..只会用不会管理

参考

企业Git 规范的必要性
Git企业级使用规范 - 操作流程
Git企业级使用规范 - 实际操作

1. git 管理流程参考

2.1 分支命名及其作用

1. master分支
   主分支，代码可随时上线，属于重要分支。

2. develop分支
   代码最新分支，基于master创建，属于重要分支。

3. feature分支
   开发人员实际业务开发分支，即开发人员自己的分支，基于develop创建，属于子分支次要分支，编码完成后可通过pull request审计合并，审计通过后将合并至develop分支。
   在合并之前要变基到develop分支上

4. release分支
   预发布分支，基于develop 分支，属于重要分支。当develop分支修改完成后，develop分支将封存不再改动，然后通过基于develop 分支新建release 分支。release分支修改bug。
   重要分支与develop进行合并用merge

5. fix分支
   修复bug分支

重要分支合并用merge，次要分支合并用rebace

3. 具体操作方法

3.1 分支介绍

master 分支 基于origin创建的
develop 分支 基于master创建的
feature/zhangsan 分支 基于develop创建的
feature/lisi 分支 基于develop创建的

3.2 张三的操作

3.2.1 普通修改代码

1. 修改代码
2. 提交代码修改commit and message
3. 推送至自己的远程仓库feature/zhangsan

3.2.2 与develop合并

1. 切换至develop分支，pull拉取最新代码
2. 切换回自己的分支feature/zhangsan
3. rebace变基至最新的develop分支
4. 在平台上(即网页端)提交一个pull request
   选择源分支feature/zhangsan 目标分支 develop 分支

3.3 李四的操作

3.3.1 普通修改代码

1. 修改代码
2. 将自己的代码存储变更

3.3.2 与develop合并

3. 切换回develop分支，pull拉取最新代码
4. 切换回自己的分支feature/lisi
5. 回复存储代码（恢复储藏变更）
6. rebace变基至最新的develop分支
   解决冲突
7. 提交commit 代码
8. push推送至自己的远程仓库feature/lisi
9. 在平台上(即网页端)提交一个pull request
   选择源分支feature/lisi 目标分支 develop 分支
10. 审核并合并

3.4 prerelease预发布操作

1. 基于develop 分支新建release/1.0.1 分支
2. 修改bug并commit 提交变更
3. push 推送至 release/1.0.1 远程仓库
4. 切换至master分支
5. pull拉取更新本地master分支
6. 切换回release/1.0.1分支
7. 与master进行合并（merge）
8. push 推送至 release/1.0.1 远程仓库
9. 假设已经可以上线了，在平台上提交一个pull request
   选择源分支release/1.0.1 目标分支 master 分支
10. 审核并合并

3.5 release发布上线

1. 在平台上(即网页端)，选择统计->发行版->创建发行版