Git的工作流程是怎樣的

這篇文章將為大家詳細(xì)講解有關(guān)Git的工作流程是怎樣的，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

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

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

這里介紹三種廣泛使用的工作流程：

• Git flow

• Github flow

• Gitlab flow

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

• 《Git 使用規(guī)范流程》

• 《常用 Git 命令清單》

• 《Git 遠(yuǎn)程操作詳解》

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

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

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

二、Git flow

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

2.1 特點(diǎn)

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

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

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

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

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

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

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

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

可是，有些時(shí)候并非如此，代碼合并進(jìn)入master分支，并不代表它就能立刻發(fā)布。比如，蘋果商店的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)不同開發(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)不同的開發(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

前面說過，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。

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

這可以采用rebase命令附帶的squash操作。

關(guān)于Git的工作流程是怎樣的就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。