Git 協做流程

時間 2019-11-06

標籤 git 流程欄目 Git 简体版

原文原文鏈接

Git 協做流程5html

Git 做爲一個源碼管理系統，不可避免涉及到多人協做。git

協做必須有一個規範的流程，讓你們有效地合做，使得項目層次分明地發展下去。"協做流程"在英語裏，叫作"workflow"或者"flow"，原意是水流，比喻項目像水流那樣，順暢、天然地向前流動，不會發生衝擊、對撞、甚至漩渦。github

本文介紹三種普遍使用的協做流程：ide

Git flow工具
Github flowgitlab
Gitlab flowpost

若是你對Git還不是很熟悉，能夠先閱讀下面的文章。網站

所有回覆

實驗樓管理員 L64

1、功能驅動

本文的三種協做流程，有一個共同點：都採用"功能驅動式開發"（Feature-driven development，簡稱FDD）。

它指的是，需求是開發的起點，先有需求再有功能分支（feature branch）或者補丁分支（hotfix branch）。完成開發後，該分支就合併到主分支，而後被刪除。

2、Git flow

最先誕生、並獲得普遍採用的一種協做流程，就是Git flow 。

2.1 特色

它最主要的特色有兩個。

首先，項目存在兩個長期分支。

主分支master
開發分支develop

前者用於存放對外發布的版本，任什麼時候候在這個分支拿到的，都是穩定的分佈版；後者用於平常開發，存放最新的開發版。

其次，項目存在三種短時間分支。

功能分支（feature branch）
補丁分支（hotfix branch）
預發分支（release branch）

一旦完成開發，它們就會被合併進develop或master，而後被刪除。

Git flow 的詳細介紹，請閱讀我翻譯的中文版《Git 分支管理策略》。

2.2 評價

Git flow的優勢是清晰可控，缺點是相對複雜，須要同時維護兩個長期分支。大多數工具都將master看成默認分支，但是開發是在develop分支進行的，這致使常常要切換分支，很是煩人。

更大問題在於，這個模式是基於"版本發佈"的，目標是一段時間之後產出一個新版本。可是，不少網站項目是"持續發佈"，代碼一有變更，就部署一次。這時，master分支和develop分支的差異不大，不必維護兩個長期分支。

2015-12-25 15:05

實驗樓管理員 L64

3、Github flow

Github flow 是Git flow的簡化版，專門配合"持續發佈"。它是 Github.com 使用的協做流程。

3.1 流程

它只有一個長期分支，就是master，所以用起來很是簡單。

官方推薦的流程以下。

第一步：根據需求，從master拉出新分支，不區分功能分支或補丁分支。

第二步：新分支開發完成後，或者須要討論的時候，就向master發起一個pull request（簡稱PR）。

第三步：Pull Request既是一個通知，讓別人注意到你的請求，又是一種對話機制，你們一塊兒評審和討論你的代碼。對話過程當中，你還能夠不斷提交代碼。

第四步：你的Pull Request被接受，合併進master，從新部署後，原來你拉出來的那個分支就被刪除。（先部署再合併也可。）

3.2 評價

Github flow 的最大優勢就是簡單，對於"持續發佈"的產品，能夠說是最合適的流程。

問題在於它的假設：master分支的更新與產品的發佈是一致的。也就是說，master分支的最新代碼，默認就是當前的線上代碼。

但是，有些時候並不是如此，代碼合併進入master分支，並不表明它就能馬上發佈。好比，蘋果商店的APP提交審覈之後，等一段時間才能上架。這時，若是還有新的代碼提交，master分支就會與剛發佈的版本不一致。另外一個例子是，有些公司有發佈窗口，只有指定時間才能發佈，這也會致使線上版本落後於master分支。

上面這種狀況，只有master一個主分支就不夠用了。一般，你不得不在master分支之外，另外新建一個production分支跟蹤線上版本。

2015-12-25 15:05

實驗樓管理員 L64

4、Gitlab flow

Gitlab flow 是 Git flow 與 Github flow 的綜合。它吸收了二者的優勢，既有適應不一樣開發環境的彈性，又有單一主分支的簡單和便利。它是 Gitlab.com 推薦的作法。

4.1 上游優先

Gitlab flow 的最大原則叫作"上游優先"（upsteam first），即只存在一個主分支master，它是全部其餘分支的"上游"。只有上游分支採納的代碼變化，才能應用到其餘分支。

Chromium項目就是一個例子，它明確規定，上游分支依次爲：

Linus Torvalds的分支
子系統（好比netdev）的分支
設備廠商（好比三星）的分支

4.2 持續發佈

Gitlab flow 分紅兩種狀況，適應不一樣的開發流程。

對於"持續發佈"的項目，它建議在master分支之外，再創建不一樣的環境分支。好比，"開發環境"的分支是master，"預發環境"的分支是pre-production，"生產環境"的分支是production。

開發分支是預發分支的"上游"，預發分支又是生產分支的"上游"。代碼的變化，必須由"上游"向"下游"發展。好比，生產環境出現了bug，這時就要新建一個功能分支，先把它合併到master，確認沒有問題，再cherry-pick到pre-production，這一步也沒有問題，才進入production。

只有緊急狀況，才容許跳過上游，直接合併到下游分支。