Git 工作流程

作者：阮一峰
原文出處：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

Git 作為一個(gè)源碼管理系統(tǒng)，不可避免涉及到多人協(xié)作。

協(xié)作必須有一個(gè)規(guī)范的工作流程，讓大家有效地合作，使得項(xiàng)目井井有條地發(fā)展下去。"工作流程"在英語(yǔ)里，叫做"workflow"或者"flow"，原意是水流，比喻項(xiàng)目像水流那樣，順暢、自然地向前流動(dòng)，不會(huì)發(fā)生沖擊、對(duì)撞、甚至漩渦。

本文介紹三種廣泛使用的工作流程：

  • Git flow
  • Github flow
  • Gitlab flow

如果你對(duì)Git還不是很熟悉，可以先閱讀下面的文章。

一、功能驅(qū)動(dòng)

本文的三種工作流程，有一個(gè)共同點(diǎn)：都采用"功能驅(qū)動(dòng)式開(kāi)發(fā)"（Feature-driven development，簡(jiǎn)稱(chēng)FDD）。

它指的是，需求是開(kāi)發(fā)的起點(diǎn)，先有需求再有功能分支（feature branch）或者補(bǔ)丁分支（hotfix branch）。完成開(kāi)發(fā)后，該分支就合并到主分支，然后被刪除。

二、Git flow

最早誕生、并得到廣泛采用的一種工作流程，就是Git flow 。

2.1 特點(diǎn)

它最主要的特點(diǎn)有兩個(gè)。

首先，項(xiàng)目存在兩個(gè)長(zhǎng)期分支。

  • 主分支master
  • 開(kāi)發(fā)分支develop

前者用于存放對(duì)外發(fā)布的版本，任何時(shí)候在這個(gè)分支拿到的，都是穩(wěn)定的分布版；后者用于日常開(kāi)發(fā)，存放最新的開(kāi)發(fā)版。

其次，項(xiàng)目存在三種短期分支。

  • 功能分支（feature branch）
  • 補(bǔ)丁分支（hotfix branch）
  • 預(yù)發(fā)分支（release branch）

一旦完成開(kāi)發(fā)，它們就會(huì)被合并進(jìn)develop或master，然后被刪除。

Git flow 的詳細(xì)介紹，請(qǐng)閱讀我翻譯的中文版《Git 分支管理策略》。

2.2 評(píng)價(jià)

Git flow的優(yōu)點(diǎn)是清晰可控，缺點(diǎn)是相對(duì)復(fù)雜，需要同時(shí)維護(hù)兩個(gè)長(zhǎng)期分支。大多數(shù)工具都將master當(dāng)作默認(rèn)分支，可是開(kāi)發(fā)是在develop分支進(jìn)行的，這導(dǎo)致經(jīng)常要切換分支，非常煩人。

更大問(wèn)題在于，這個(gè)模式是基于"版本發(fā)布"的，目標(biāo)是一段時(shí)間以后產(chǎn)出一個(gè)新版本。但是，很多網(wǎng)站項(xiàng)目是"持續(xù)發(fā)布"，代碼一有變動(dòng)，就部署一次。這時(shí)，master分支和develop分支的差別不大，沒(méi)必要維護(hù)兩個(gè)長(zhǎng)期分支。

三、Github flow

Github flow 是Git flow的簡(jiǎn)化版，專(zhuān)門(mén)配合"持續(xù)發(fā)布"。它是 Github.com 使用的工作流程。

3.1 流程

它只有一個(gè)長(zhǎng)期分支，就是master，因此用起來(lái)非常簡(jiǎn)單。

官方推薦的流程如下。

第一步：根據(jù)需求，從master拉出新分支，不區(qū)分功能分支或補(bǔ)丁分支。

第二步：新分支開(kāi)發(fā)完成后，或者需要討論的時(shí)候，就向master發(fā)起一個(gè)pull request（簡(jiǎn)稱(chēng)PR）。

第三步：Pull Request既是一個(gè)通知，讓別人注意到你的請(qǐng)求，又是一種對(duì)話機(jī)制，大家一起評(píng)審和討論你的代碼。對(duì)話過(guò)程中，你還可以不斷提交代碼。

第四步：你的Pull Request被接受，合并進(jìn)master，重新部署后，原來(lái)你拉出來(lái)的那個(gè)分支就被刪除。（先部署再合并也可。）

3.2 評(píng)價(jià)

Github flow 的最大優(yōu)點(diǎn)就是簡(jiǎn)單，對(duì)于"持續(xù)發(fā)布"的產(chǎn)品，可以說(shuō)是最合適的流程。

問(wèn)題在于它的假設(shè)：master分支的更新與產(chǎn)品的發(fā)布是一致的。也就是說(shuō)，master分支的最新代碼，默認(rèn)就是當(dāng)前的線上代碼。

可是，有些時(shí)候并非如此，代碼合并進(jìn)入master分支，并不代表它就能立刻發(fā)布。比如，蘋(píng)果商店的APP提交審核以后，等一段時(shí)間才能上架。這時(shí)，如果還有新的代碼提交，master分支就會(huì)與剛發(fā)布的版本不一致。另一個(gè)例子是，有些公司有發(fā)布窗口，只有指定時(shí)間才能發(fā)布，這也會(huì)導(dǎo)致線上版本落后于master分支。

上面這種情況，只有master一個(gè)主分支就不夠用了。通常，你不得不在master分支以外，另外新建一個(gè)production分支跟蹤線上版本。

四、Gitlab flow

Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸取了兩者的優(yōu)點(diǎn)，既有適應(yīng)不同開(kāi)發(fā)環(huán)境的彈性，又有單一主分支的簡(jiǎn)單和便利。它是 Gitlab.com 推薦的做法。

4.1 上游優(yōu)先

Gitlab flow 的最大原則叫做"上游優(yōu)先"（upsteam first），即只存在一個(gè)主分支master，它是所有其他分支的"上游"。只有上游分支采納的代碼變化，才能應(yīng)用到其他分支。

Chromium項(xiàng)目就是一個(gè)例子，它明確規(guī)定，上游分支依次為：

  1. Linus Torvalds的分支
  2. 子系統(tǒng)（比如netdev）的分支
  3. 設(shè)備廠商（比如三星）的分支

4.2 持續(xù)發(fā)布

Gitlab flow 分成兩種情況，適應(yīng)不同的開(kāi)發(fā)流程。

對(duì)于"持續(xù)發(fā)布"的項(xiàng)目，它建議在master分支以外，再建立不同的環(huán)境分支。比如，"開(kāi)發(fā)環(huán)境"的分支是master，"預(yù)發(fā)環(huán)境"的分支是pre-production，"生產(chǎn)環(huán)境"的分支是production。

開(kāi)發(fā)分支是預(yù)發(fā)分支的"上游"，預(yù)發(fā)分支又是生產(chǎn)分支的"上游"。代碼的變化，必須由"上游"向"下游"發(fā)展。比如，生產(chǎn)環(huán)境出現(xiàn)了bug，這時(shí)就要新建一個(gè)功能分支，先把它合并到master，確認(rèn)沒(méi)有問(wèn)題，再cherry-pick到pre-production，這一步也沒(méi)有問(wèn)題，才進(jìn)入production。

只有緊急情況，才允許跳過(guò)上游，直接合并到下游分支。

4.3 版本發(fā)布

對(duì)于"版本發(fā)布"的項(xiàng)目，建議的做法是每一個(gè)穩(wěn)定版本，都要從master分支拉出一個(gè)分支，比如2-3-stable、2-4-stable等等。

以后，只有修補(bǔ)bug，才允許將代碼合并到這些分支，并且此時(shí)要更新小版本號(hào)。

五、一些小技巧

5.1 Pull Request

功能分支合并進(jìn)master分支，必須通過(guò)Pull Request（Gitlab里面叫做 Merge Request）。

前面說(shuō)過(guò)，Pull Request本質(zhì)是一種對(duì)話機(jī)制，你可以在提交的時(shí)候，@相關(guān)人員或團(tuán)隊(duì)，引起他們的注意。

5.2 Protected branch

master分支應(yīng)該受到保護(hù)，不是每個(gè)人都可以修改這個(gè)分支，以及擁有審批 Pull Request 的權(quán)力。

Github 和 Gitlab 都提供"保護(hù)分支"（Protected branch）這個(gè)功能。

5.3 Issue

Issue 用于 Bug追蹤和需求管理。建議先新建 Issue，再新建對(duì)應(yīng)的功能分支。功能分支總是為了解決一個(gè)或多個(gè) Issue。

功能分支的名稱(chēng)，可以與issue的名字保持一致，并且以issue的編號(hào)起首，比如"15-require-a-password-to-change-it"。

開(kāi)發(fā)完成后，在提交說(shuō)明里面，可以寫(xiě)上"fixes #14"或者"closes #67"。Github規(guī)定，只要commit message里面有下面這些動(dòng)詞 + 編號(hào)，就會(huì)關(guān)閉對(duì)應(yīng)的issue。

  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

這種方式還可以一次關(guān)閉多個(gè)issue，或者關(guān)閉其他代碼庫(kù)的issue，格式是username/repository#issue_number。

Pull Request被接受以后，issue關(guān)閉，原始分支就應(yīng)該刪除。如果以后該issue重新打開(kāi)，新分支可以復(fù)用原來(lái)的名字。

5.4 Merge節(jié)點(diǎn)

Git有兩種合并：一種是"直進(jìn)式合并"（fast forward），不生成單獨(dú)的合并節(jié)點(diǎn)；另一種是"非直進(jìn)式合并"（none fast-forword），會(huì)生成單獨(dú)節(jié)點(diǎn)。

前者不利于保持commit信息的清晰，也不利于以后的回滾，建議總是采用后者（即使用--no-ff參數(shù)）。只要發(fā)生合并，就要有一個(gè)單獨(dú)的合并節(jié)點(diǎn)。

5.5 Squash 多個(gè)commit

為了便于他人閱讀你的提交，也便于cherry-pick或撤銷(xiāo)代碼變化，在發(fā)起Pull Request之前，應(yīng)該把多個(gè)commit合并成一個(gè)。（前提是，該分支只有你一個(gè)人開(kāi)發(fā)，且沒(méi)有跟master合并過(guò)。）

這可以采用rebase命令附帶的squash操作，具體方法請(qǐng)參考我寫(xiě)的《Git 使用規(guī)范流程》。

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容