工作流秦士，講的是對(duì)項(xiàng)目版本管理的一套操作流程規(guī)范缺厉。
在SVN時(shí)代，大家別無(wú)選擇隧土，都是從同一個(gè)分支上開(kāi)發(fā)提针，提交，解決沖突曹傀。
用Git做版本管理后辐脖，得益于其分布式能力，大家就可以不依賴中央版本庫(kù)皆愉，各自獨(dú)立開(kāi)發(fā)嗜价，提交，再在適當(dāng)時(shí)候合并幕庐。因其靈活性而產(chǎn)生了多種多樣的工作流久锥。

集中式工作流

當(dāng)然，你也可以忽略Git的分布式能力异剥，忽略方便快捷的分支控制能力瑟由，在Git上用出Svn的感覺(jué)，反正你開(kāi)心就好啦冤寿。這種在一個(gè)分支上進(jìn)行協(xié)作的方式错妖，我們也給它起個(gè)名，就叫集中式工作流疚沐。
所有人都在一個(gè)分支上開(kāi)發(fā)暂氯，優(yōu)點(diǎn)還是有的：

1. 簡(jiǎn)單粗暴易操作，適合不太復(fù)雜的小項(xiàng)目
2. 每一次提交亮蛔，都解決一次沖突痴施，化大沖突為小沖突。
3. 當(dāng)需要依賴他人的工作輸出時(shí)，或者說(shuō)與他人工作的耦合度高時(shí)辣吃，能方便工作快速推進(jìn)动遭。
   但是缺點(diǎn)也非常明顯：
4. 提交歷史混亂，從提交歷史上難以追蹤一個(gè)完整功能的提交情況神得。
5. 每次提交都有沖突的可能厘惦，假如沖突不好解決，或者合并了他人有問(wèn)題的代碼哩簿，就會(huì)打斷自己的工作節(jié)奏宵蕉。
6. 不利于code review，不利于代碼質(zhì)量管理

Git Flow

我們應(yīng)該在一個(gè)功能节榜，或者叫特性羡玛，開(kāi)發(fā)完成后，才與他人代碼進(jìn)行合并宗苍。
這時(shí)需要為一個(gè)個(gè)特性的開(kāi)發(fā)創(chuàng)建專門分支稼稿。
在特性分支合并進(jìn)master后，并不意味著代碼就能進(jìn)行發(fā)布讳窟，可能需要經(jīng)過(guò)各種測(cè)試修改让歼，這時(shí)需要再創(chuàng)建一個(gè)分支來(lái)完成這個(gè)步驟，它應(yīng)介于master與特性分支之間丽啡，我們可以把它叫做開(kāi)發(fā)分支develop谋右。
另外，對(duì)于線上發(fā)行版碌上，如果出現(xiàn)了緊急需要修復(fù)的bug，還需要一個(gè)分支hotfix來(lái)完成bug修復(fù)浦徊。
基于這些想法馏予，Vincent Driessen同學(xué)在多年前提出了一個(gè)分支模型A successful Git branching model，詳細(xì)描述了此種工作流盔性，后人大多把它叫做Git Flow霞丧。

A successful Git branching model

• 主要分支
  • master: 永遠(yuǎn)處在production-ready狀態(tài)
  • develop: 最新的下次發(fā)布開(kāi)發(fā)狀態(tài)
• 支援性分支
  • feature branches: 開(kāi)發(fā)新功能都從develop分支出來(lái)，完成后merge回develop
  • release branches: 準(zhǔn)備要release的版本冕香，只修bugs蛹尝。從develop分支出來(lái)，完成后merge回master和develop
  • hotfix branches: 等不及release版本必須馬上修復(fù)線上的問(wèn)題悉尾。從master分支出來(lái)突那，完成后merge回master和develop

概略來(lái)講，就是開(kāi)發(fā)工作在develop分支進(jìn)行构眯，然后提交到release分支愕难，最后合并到master分支。
git工作流很標(biāo)準(zhǔn)但是使用很復(fù)雜。

Github Flow

GitHub Flow是github.com提出的方案猫缭，簡(jiǎn)化成只有一個(gè)feature分支和一個(gè)master分支葱弟。
github有一個(gè)pull request功能，多人協(xié)作時(shí)猜丹，在feature分支開(kāi)發(fā)完成后芝加，可以向項(xiàng)目負(fù)責(zé)人發(fā)起pull request，請(qǐng)求項(xiàng)目負(fù)責(zé)人拉取代碼射窒，檢閱并合并pull request指定的分支藏杖。

Gitlab Flow

Gitlab Flow是gitlab.com提出的方案，覺(jué)得git flow太復(fù)雜轮洋，而github flow又過(guò)于簡(jiǎn)化而不能滿足項(xiàng)目開(kāi)發(fā)需求制市。
它的feature分支可以直接合入master分支，而master就變成了開(kāi)發(fā)主分支弊予。對(duì)于持續(xù)集成需求祥楣，提出從master開(kāi)出pre-production分支和production分支，pre-production作為一個(gè)發(fā)布前的緩存汉柒，而production就代表了線上運(yùn)行的版本误褪。

Gitlab Flow 環(huán)境分支

同樣gitlab也有像github一樣的pull request讼育，不過(guò)在gitlab中，這個(gè)功能叫做merge request稠集，也是請(qǐng)求別人來(lái)拉取我的分支代碼奶段，code review，然后合并剥纷。

一些小Tips

• 空目錄在Git中是個(gè)無(wú)關(guān)對(duì)象痹籍，它不能通過(guò)add命令被添加到提交中。如果需要把空目錄提交并push到遠(yuǎn)程倉(cāng)庫(kù)晦鞋，可以在目錄下建一個(gè)無(wú)關(guān)文件.gitkeep词裤。
• 特性分支上的提交如果是比較隨意的話刺洒，它在合入主開(kāi)發(fā)分支時(shí)應(yīng)壓縮一下提交歷史，再比較正式地的提交一次吼砂。這時(shí)可用到squash命令逆航，同時(shí)它可以作為merge的選項(xiàng)git merge --squash branch，這樣的合并不會(huì)產(chǎn)生新提交渔肩，需要你在解決完沖突后因俐，自己提交一次。

參考閱讀

• Git flow 開(kāi)發(fā)流程
• Git 工作流程