1.分支管理
1.1 總覽
從上圖可以看到主要包含下面幾個(gè)分支：
-
master: 主分支氧敢，主要用來版本發(fā)布植康。 -
develop：日常開發(fā)分支效扫，該分支正常保存了開發(fā)的最新代碼。 -
feature：從develop分支fork席覆，合并回develop刹孔。具體的功能開發(fā)分支。 -
release：從develop分支fork娜睛，合并回develop和master。一般用于發(fā)布正式版本之前（即合并到 master 分支之前）卦睹，需要有的預(yù)發(fā)布的版本進(jìn)行測(cè)試畦戒。 -
hotfix：從master分支fork，合并回develop和master结序。線上 bug 修復(fù)分支障斋。
1.2 主分支(master, develop)
主分支包括 master 分支和 develop 分支。master 分支用來發(fā)布，HEAD 就是當(dāng)前線上的運(yùn)行代碼垃环。develop 分支就是我們的日常開發(fā)邀层。使用這兩個(gè)分支就具有了最簡(jiǎn)單的開發(fā)模式：develop 分支用來開發(fā)功能，開發(fā)完成并且測(cè)試沒有問題則將 develop 分支的代碼合并到 master 分支并發(fā)布遂庄。
1.3 輔助分支(feature , release, hotfix)
??? feature 分支用來開發(fā)具體的功能寥院，一般 fork 自 develop 分支，最終可能會(huì)合并到 develop 分支涛目。一般feature分支都存在于開發(fā)者本地秸谢，開發(fā)期間使用git rebase來保證和develop分支的代碼同步并解決沖突。功能開發(fā)完畢后push到遠(yuǎn)程倉庫霹肝，然后提交pull request估蹄，合并到develop分支。
??? release 分支在我看來是 pre-master沫换。release 分支從 develop 分支 fork 出來臭蚁，最終會(huì)合并到 develop 分支和 master 分支。合并到 master 分支上就是可以發(fā)布的代碼了讯赏。有人可能會(huì)問那為什么合并回 develop 分支呢垮兑？很簡(jiǎn)單，有了 release 分支待逞，那么相關(guān)的代碼修復(fù)就只會(huì)在 release 分支上改動(dòng)了甥角，最后必然要合并到 develop 分支。比如识樱，當(dāng)開發(fā)一個(gè)較長(zhǎng)期的feature不著急上線但又需要部署測(cè)試時(shí)嗤无，可以從develop分出一個(gè)release分支，feature提交pull request到這個(gè)release分支怜庸，然后部署這個(gè)release分支到測(cè)試服当犯。
??? hotfix 分支用來修復(fù)線上 bug。當(dāng)線上代碼出現(xiàn) bug 時(shí)割疾，我們基于 master 分支開一個(gè) hotfix 分支嚎卫，修復(fù) bug 之后再將 hotfix 分支合并到 master 分支并進(jìn)行發(fā)布，同時(shí) develop 分支作為最新最全的代碼分支宏榕，hotfix 分支也需要合并到 develop 分支上去拓诸。
1.4 分支命名
除了主要分支的名字是固定的之外，派生分支是需要自己命名的麻昼，這里就要有個(gè)命名規(guī)范了奠支。強(qiáng)烈推薦用如下形式：
- master 主分支，發(fā)布分支
- dev 主分支抚芦，開發(fā)分支
- feat_xxx——按照功能點(diǎn)（而不是需求）命名倍谜；
- release_xxx——用發(fā)布時(shí)間命名迈螟，可以加上適當(dāng)?shù)那熬Y；
- hotfix_xxx——GitLab 的 issue 編號(hào)或 bug 性質(zhì)等尔崔。
小寫字母下劃線形式
1.5 版本號(hào)命名
格式為：x.y.z答毫，其中，x 用于有重大重構(gòu)時(shí)才會(huì)升級(jí)季春，y 用于有新的特性發(fā)布時(shí)才會(huì)升級(jí)洗搂，z 用于修改了某個(gè) bug 后才會(huì)升級(jí)。
v1.1.1：第一位大版本號(hào)鹤盒，大功能發(fā)布時(shí)增加蚕脏，技術(shù)負(fù)責(zé)人審核；第二位小版本號(hào)侦锯，增加小特性時(shí)增加驼鞭，主開發(fā)審核；第三位BUG修復(fù)號(hào)尺碰，修復(fù)BUG用挣棕，修復(fù)人員負(fù)責(zé)。
- 每次發(fā)布生產(chǎn)(master)亲桥，需要為master打一個(gè)tag洛心，方便線上回滾
- 提交時(shí)的粒度是一個(gè)小功能點(diǎn)或者一個(gè) bug fix，這樣進(jìn)行恢復(fù)等的操作時(shí)能夠?qū)ⅰ刚`傷」減到最低题篷；
- 用一句簡(jiǎn)練的話寫在第一行词身，然后空一行稍微詳細(xì)闡述該提交所增加或修改的地方；
- 不要每提交一次就推送一次番枚，多積攢幾個(gè)提交后一次性推送法严，這樣可以避免在進(jìn)行一次提交后發(fā)現(xiàn)代碼中還有小錯(cuò)誤。
1.6 Commit Message 格式
<type>(<scope>): <subject> （不超過50個(gè)字）
<空行>
<body> （每行不超過72個(gè)字）
<空行>
<footer>
type
feat：新功能（feature）
fix：修補(bǔ)bug
mod：修改（即不是新增功能葫笼，也不是修改bug的代碼變動(dòng)）
refactor：重構(gòu)
docs：文檔（documentation）
style： 格式（不影響代碼運(yùn)行的變動(dòng)）
test：增加測(cè)試
chore：構(gòu)建過程或輔助工具的變動(dòng)Scope
用來說明本次Commit影響的范圍深啤，即簡(jiǎn)要說明修改會(huì)涉及的部分。這個(gè)本來是選填項(xiàng)路星，但從AngularJS實(shí)際項(xiàng)目中可以看出基本上也成了必填項(xiàng)了溯街。Subject
用來簡(jiǎn)要描述本次改動(dòng)，概述就好了洋丐，因?yàn)楹竺孢€會(huì)在Body里給出具體信息呈昔。并且最好遵循下面三條:
1、 以動(dòng)詞開頭友绝，使用第一人稱現(xiàn)在時(shí)堤尾，比如change，而不是changed或changes
2九榔、首字母不要大寫
2、結(jié)尾不用句號(hào)(.)Body
里的內(nèi)容是對(duì)上面subject里內(nèi)容的展開，在此做更加詳盡的描述哲泊，內(nèi)容里應(yīng)該包含修改動(dòng)機(jī)和修改前后的對(duì)比剩蟀。Footer
footer里的主要放置不兼容變更和Issue關(guān)閉的信息Revert
此外如果需要撤銷之前的Commit，那么本次Commit Message中必須以revert：開頭切威，后面緊跟前面描述的Header部分育特，格式不變。并且先朦，Body部分的格式也是固定的缰冤，必須要記錄撤銷前Commit的SHA值。
示例
feat: 增加港股經(jīng)紀(jì)商隊(duì)列
增加港股經(jīng)紀(jì)商隊(duì)列接口和后臺(tái)名稱編輯接口
增加同時(shí)獲取買賣盤和經(jīng)紀(jì)商的接口
BREAKING CHANGE: 刪除了舊版十檔買賣盤接口
