工作中使用git的规范流程
本文介绍企业Git版本控制的逻辑，提高程序代码管理的效率
问题：1. 开发管理乱 2. 代码冲突过多 3. 代码质量过低 4. 代码管理效率不高..只会用不会管理
参考
企业Git 规范的必要性
Git企业级使用规范 - 操作流程
Git企业级使用规范 - 实际操作
1.git 管理流程参考
2.1 分支命名及其作用
**master分支**: 主分支，代码可随时上线，属于重要分支。
**develop分支**: 代码最新分支，基于master创建，属于重要分支。
**feature分支**: 开发人员实际业务开发分支，即开发人员自己的分支，基于develop创建，属于子分支次要分支，编码完成后可通过pull request审计合并，审计通过后将合并至develop分支。
在合并之前要变基到develop分支上
release分支: 预发布分支，基于develop 分支，属于重要分支。当develop分支修改完成后，develop分支将封存不再改动，然后通过基于develop 分支新建release 分支。release分支修改bug。
重要分支与develop进行合并用merge
fix分支
修复bug分支
重要分支合并用merge，次要分支合并用rebace
3.具体操作方法
3.1 分支介绍
master分支 基于origin创建的
develop分支 基于master创建的
feature/zhangsan 分支 基于develop创建的
feature/lisi 分支 基于develop创建的
3.2 张三的操作
3.2.1 普通修改代码
修改代码
提交代码修改commit and message
推送至自己的远程仓库feature/zhangsan
3.2.2 与develop合并
切换至develop分支，pull拉取最新代码
切换回自己的分支feature/zhangsan
rebace变基至最新的develop分支
在平台上(即网页端)提交一个pull request
选择源分支feature/zhangsan 目标分支 develop 分支
3.3 李四的操作
3.3.1 普通修改代码
修改代码
将自己的代码存储变更
3.3.2 与develop合并
切换回develop分支，pull拉取最新代码
切换回自己的分支feature/lisi
回复存储代码（恢复储藏变更）
rebace变基至最新的develop分支
解决冲突
提交commit 代码
push推送至自己的远程仓库feature/lisi
在平台上(即网页端)提交一个pull request
选择源分支feature/lisi 目标分支 develop 分支
审核并合并
3.4 prerelease预发布操作
基于develop 分支新建release/1.0.1 分支
修改bug并commit 提交变更
push 推送至 release/1.0.1 远程仓库
切换至master分支
pull拉取更新本地master分支
切换回release/1.0.1分支
与master进行合并（merge）
push 推送至 release/1.0.1 远程仓库
假设已经可以上线了，在平台上提交一个pull request
选择源分支release/1.0.1 目标分支 master 分支
审核并合并
3.5 release发布上线
在平台上(即网页端)，选择统计->发行版->创建发行版