git版本管理规范

　　1、基本开发流程：

2、分支命名

2.1主分支

　　① master ：随时可供在生产环境中部署的代码

　　② dev： 保存当前稳定而且最新的开发分支(多人开发同一分支)

2.2辅助分支

 

主要用于新功能的并行开发、对生产代码的缺陷进行紧急修复工做。合并 master后应该当即删除

　　①用于开发新功能时所使用的feature分支

　　② 用于修正生产代码中的缺陷的bug分支

2.3根据实际开发状况合理命名分支：分支类型_开发者_时间_开发内容  

①　feature分支:f_yourname_20170416_customLimit

②　bug分支：bug_yourname_20170416_customLimit

③　dev分支：dev_yourname_20170416_customLimit

3、git-commit 　

3.1何时commit？

　　commit在何时均可以，可是不建议为了保存代码而commit，每一次commit必定是表明代码开发进行到了某一个阶段，能够在后续开发或者合并代码出现错误的时候能够快速回到这个阶段。

3.2 commit注释

　　每次提交必需要有提交注释，注释根据本次提交状况，进行简洁描述

3.3 屡次提交合并为一次提交(rebase)

　　① git fetch

　　② git rebase

　　　　下面示范一下rebase的使用方法：

　　　　a. 更新本地仓库

　　　　

　　　　　　b.选择origin master

　　　　　　

　　　　　　c.commit 合并

　　　　　　

　　　　　　d.存在冲突时，必需要解决

　　　　　　e.继续 rebase

　　　　　　

4、 Git-push

4.1何时push？

　　　　① 代码须要提测，而且本身都测试OK了，若是一次性测试经过则能够把master合并到本身的分支，而后push本身的分支，进行提测

　　　　② 代码提测了，若是有问题，把问题修改好后，再push本身的分支。

4.2 push流程

• git fetch
• git checkout dev
• git branch -b copy_dev(copy新分支进行合并)
• git merge origin master (存在冲突必须解决)

　　　　解决冲突：

　　　　a) git reset --HARD HEAD^

　　　　b) git lg(查看你的全部提交的历史)　

• git checkout dev
• git merge copy_dev
• git branch -d copy_dev
• git push origin dev

5、Git-issue

5.1对需求彻底了解后，开发前先整理思路，在git上填写Issues

　　　　① 整理思路，快速开发代码

　　　　② 方便后续出现线上问题，快速定位

　　　　③ 有相似功能开发时，方便别人借鉴，和本身快速回忆

　　　　④ 相互学习

5.2 写完Issues后，找有相关开发经验同事评审

5.3 影响范围较大的Issues必须拉上你们一块儿评审

5.4 issues规范 (别人一看就懂)

　　　　① 需求概述

　　　　② 难点，解决方案

　　　　③ 概要设计

　　　　④ 详细设计

 

6、git-codeReview

6.1 代码开发完毕，自测经过后，提测以前，在git上提merge Requests

　　　　① WIP:分支标题

　　　　② Issues

　　　　　　

6.2 找有相关开发经验人员进行评审

6.3 按照评审人的建议进行修改，修改后自测

7、 Git-merge

7.1 merge流程

　　　　① merge以前保证本身的工做区是干净的

　　　　② fetch,更新本地仓库

　　　　③ 合并master，若是出现merge conflict，找到相关开发人员一块儿解 决，确保操做正确  

　　　　④ merge完成后，验证是否成功

7.2 合主干

　　　　① 多人在不一样分支上开发多个需求，须要同时上线，事先肯定各自上线时间

　　　　② 别人合主干后，须要再次拉取最新的master进行merge，进行回归测试

　　　　③ 上线的代码必定是提测的代码，是彻底如出一辙，中间若是有过合并代码就要从新提测，早合并代码比较合适

　　　　④ merge Request上，须要附带Issue，代码评审人，测试用例