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，代碼評審人，測試用例