工作中使用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发布上线
在平台上(即网页端)，选择统计->发行版->创建发行版