本文內(nèi)容全原創(chuàng)手打橘忱，希望大家可以喜歡赴魁，文末附上個人覺得有價值的參考。
為了能夠科學(xué)有序钝诚、簡單可靠地維護(hù)項目的代碼倉庫和歷史版本尚粘，基于目前主流、成熟的Git工作流形式敲长，考慮項目和團(tuán)隊的實際情況，編寫此規(guī)范秉继；
希望同時可以提升開發(fā)團(tuán)隊日常工作的效率和質(zhì)量祈噪，使每個人能夠熟悉標(biāo)準(zhǔn)化的合作方式，增強(qiáng)團(tuán)隊的凝聚力和面對復(fù)雜場景的處理能力尚辑；
分支類型的約定
master
命名：master
永久分支辑鲤；
用于記錄已上線的穩(wěn)定代碼 ；
通過合并release分支獲取提交杠茬，通過tag等方式記錄版本信息月褥；
當(dāng)master有了新的提交時將提交合并到所有develop分支；
release
命名：release
永久分支瓢喉；
用于待上線版本代碼的合并宁赤、測試和修復(fù)；
接受兩種代碼提交：合并次級開發(fā)分支develop上已通過測試并確認(rèn)即將發(fā)版的提交栓票、臨時修復(fù)已上線版本bug的提交决左；
代碼上線發(fā)版后，將代碼合并到master分支走贪；
develop
命名：dev_branch_name
長期分支佛猛；
用于項目主要業(yè)務(wù)需求的開發(fā)、測試和bug修改坠狡；
根據(jù)業(yè)務(wù)需求任務(wù)線的劃分決定此類分支的數(shù)量继找，如跑團(tuán)、直播逃沿、保險婴渡、公共幻锁；
根據(jù)上線時間等因素決定分支建立時的父節(jié)點(diǎn)來自master還是已經(jīng)存在的develop分支；
在通過測試并確認(rèn)將要上線后缩搅，將代碼合并到release分支越败，任務(wù)線結(jié)束后刪除此分支；
feature
命名：feat_branch_name
臨時分支硼瓣；
用于開發(fā)實驗性或小任務(wù)量的業(yè)務(wù)模塊究飞，根據(jù)需要基于master或相關(guān)develop分支創(chuàng)建；
開發(fā)完成后合并到release或?qū)?yīng)的develop分支堂鲤，并刪除此feature分支亿傅；
fixbug
命名：fix_branch_name
臨時分支;
用于線上版本bug的修復(fù)，基于master創(chuàng)建瘟栖；
修復(fù)結(jié)束后合并到release分支葵擎，然后刪除此分支；
分支合作的流程
直線段表示從父節(jié)點(diǎn)新建分支半哟，曲線段表示合并操作酬滤；
上線版本的維護(hù)流程
日常開發(fā)測試的流程
提交信息的格式
type ：[scope：] subject [#bugIndex]
// 空行
[description]
type
說明本次代碼提交的類型，使用以下幾種前綴表示：
merge 合并其他分支的代碼寓涨；
**dev **業(yè)務(wù)或功能模塊的階段性提交盯串；
**fix **修復(fù)測試流程中發(fā)現(xiàn)的bug，或開發(fā)過程中發(fā)現(xiàn)的過去的bug（測試中的bug使用dev前綴）戒良；
refactor 對代碼進(jìn)行重構(gòu)優(yōu)化体捏，沒有增加新功能或者修復(fù)bug；
**build **改變build.gradle等構(gòu)建系統(tǒng)的文件內(nèi)容糯崎，改變項目的依賴庫几缭、調(diào)試工具等；
**test_on **為了測試而改變了某些代碼邏輯或環(huán)境配置沃呢；
**test_off **還原為了測試而改變的代碼邏輯或環(huán)境配置年栓；
scope
本次提交涉及的代碼或業(yè)務(wù)功能的范圍，與后面內(nèi)容用冒號隔開;
subject
本次提交的概要說明薄霜；
除了fix類型的提交以外應(yīng)該使用祈使句韵洋，簡要明確地表達(dá)清楚提交的內(nèi)容，結(jié)尾無需添加標(biāo)點(diǎn)黄锤；
bugIndex
JIRA上的bug編號搪缨，當(dāng)此提交是用來解決某個JIRA上的bug時，必須在提交標(biāo)題中標(biāo)明鸵熟，如 “ #1600”副编；
空行
用于分隔提交的標(biāo)題和詳細(xì)內(nèi)容；
description
用于記錄一些細(xì)節(jié)流强，例如標(biāo)題中沒能說清楚的任務(wù)細(xì)節(jié)痹届，需要記錄的重難點(diǎn)邏輯或更新呻待；
示例
dev：設(shè)計改版：更新首頁文案
dev：微服務(wù)-自助理賠：界面開發(fā)，邏輯優(yōu)化
1队腐，修正未勾選協(xié)議的彈窗時機(jī)
2蚕捉，完成待上傳資料的設(shè)計改版
dev：消息中心-保單簽收：數(shù)據(jù)加載失敗，未顯示“點(diǎn)擊加載”（娟）#1781
dev：泰愛牙：我的預(yù)約列表 #1622 #1633 #1721 #1722
fix：首頁：banner加載延遲
merge：微服務(wù)一期優(yōu)化
merge：release-v2.0.13
//注：此格式用于master合并release分支
build：更新gradle版本為3.4.1柴淘，修復(fù)產(chǎn)生的問題
build：更新依賴庫：butternife迫淹，rxandroid
release：v2.0.13 優(yōu)化運(yùn)營體驗
//注：此格式用于release
release：v2.0.11 跑團(tuán)內(nèi)容更新
1，修復(fù)多臺機(jī)器間數(shù)據(jù)同步的問題
2为严，新增歷史數(shù)據(jù)多天上傳功能
3敛熬，支持界面外部打開，去賬號小改
refactor：優(yōu)化安裝包大小
1第股，刪除重復(fù)或無用的圖片資源
2应民，移除不再使用的running_group模塊
test_on：關(guān)閉人臉識別校驗
test_off：打開人臉識別校驗
版本倉庫的維護(hù)
分支操作權(quán)限
release、master分支相關(guān)的操作由版本庫的維護(hù)人員執(zhí)行夕吻；
develop诲锹、fixbug分支的建立和刪除由開發(fā)者與版本庫的維護(hù)人員溝通后執(zhí)行；
feature分支的操作由開發(fā)者與同一任務(wù)線的組員溝通后執(zhí)行涉馅；
本地分支根據(jù)個人需要建立辕狰，不做限制；
推送到服務(wù)器的分支必須符合命名規(guī)范控漠，在分支任務(wù)結(jié)束后及時刪除；
新建分支場景
- 開始新業(yè)務(wù)模塊的開發(fā)任務(wù)悬钳；
- 同一任務(wù)線中的內(nèi)容計劃為分批次發(fā)布到生產(chǎn)環(huán)境盐捷；
例如任務(wù)分為一期和二期上線，一期開發(fā)完成并開始測試默勾，為了不影響進(jìn)度碉渡，在一期測試過程中同時需要進(jìn)行二期的開發(fā)。由于二期的開發(fā)需要基于一期母剥，并且需要保證一期可以脫離二期進(jìn)行測試和上線滞诺，所以需要以一期為基礎(chǔ)新建二期的分支。
版本發(fā)布后在release分支上打標(biāo)簽环疼，在master分支合并release
- 標(biāo)簽打在release分支用于打包發(fā)版的提交上习霹，格式示例如下：
1 標(biāo)簽名：
v2.0.11
2 標(biāo)簽信息：
v2.0.11 跑團(tuán)內(nèi)容更新
1，修復(fù)多臺機(jī)器間數(shù)據(jù)同步的問題
2炫隶，新增歷史數(shù)據(jù)多天上傳功能
3淋叶，支持界面外部打開，去賬號
- master合并release伪阶，禁用快速前進(jìn)煞檩，產(chǎn)生的新提交格式如下：
merge：release-v2.0.11 跑團(tuán)內(nèi)容更新
1处嫌，修復(fù)多臺機(jī)器間數(shù)據(jù)同步的問題
2，新增歷史數(shù)據(jù)多天上傳功能
3斟湃，支持界面外部打開
維護(hù)人員的維護(hù)內(nèi)容
檢查各分支的建立是否符合規(guī)范熏迹，能否合理地滿足業(yè)務(wù)需要；
檢查服務(wù)器上的分支是否都在使用凝赛，清理沒有價值的分支注暗；
當(dāng)develop分支開發(fā)任務(wù)結(jié)束后，將分支內(nèi)容合并到release分支哄酝，對于不容易理解友存、處理的沖突必須與開發(fā)人員進(jìn)行溝通后操作；
記錄release分支對其他分支的每次合并陶衅，在合并的提交信息中說明合并的內(nèi)容屡立、遇到的問題等信息；
在新版本發(fā)布后將release合并到master搀军；
在運(yùn)營人員發(fā)布新版本后膨俐，通過tag等方式記錄release分支發(fā)版的更新內(nèi)容、版本號罩句、待處理的bug焚刺、臨時性的發(fā)布原因等信息，更新versionName和versionCode门烂；
在每次master分支完成合并后乳愉，將合并內(nèi)容更新到所有develop分支；
與產(chǎn)品運(yùn)營人員交流合適的發(fā)版時機(jī)和可能存在的問題屯远；
檢查提交信息是否符合規(guī)范蔓姚，與不符合規(guī)范的提交的所有者進(jìn)行溝通；
根據(jù)日常應(yīng)用情況不斷完善此規(guī)范慨丐，補(bǔ)充一些常見問題的解決方法和Git使用技巧坡脐，如有必要還應(yīng)補(bǔ)充一些概念或技術(shù)說明，供新手查閱學(xué)習(xí)房揭；
需要注意的事項
每次新版本發(fā)布备闲，在各開發(fā)分支合并主分支的代碼（重要）
適度提交頻率
將太多代碼改動放到單獨(dú)一個提交中，可能會使提交中包含多個業(yè)務(wù)或功能模塊捅暴，過于耦合恬砂，從而增加了回顧歷史的復(fù)雜度，增加了對提交進(jìn)行合并蓬痒、摘取觉既、撤銷等操作的難度；
提交過于頻繁內(nèi)容太少，例如在修改一個bug或完成一個小功能點(diǎn)時進(jìn)行了多次提交瞪讼，就是不必要的冗余提交钧椰；
應(yīng)該盡量做到，小任務(wù)量的bug修復(fù)或功能點(diǎn)作為一個提交符欠，大任務(wù)量的bug修復(fù)或功能點(diǎn)分階段進(jìn)行多次提交嫡霞，爭取保證每個提交的內(nèi)容從業(yè)務(wù)角度或時間角度來說是獨(dú)立的；
合并分支不采用快速前進(jìn)
- 命令行：
git merge --no-ff
避免冗余提交 Merge remote-tracking branch ...A... into ...B...
- 命令行：
git pull --rebase
- AndroidStudio：
在pull時選擇updateType為rebase：
