• 原文地址：5 Git workflows you can use to deliver better code and improve your development process^[1]
• 原文作者：Vikash Koushik
• 譯者：陳元
• 校對者：HelloGitHub-丫丫

我還沒有遇到過一個開發(fā)人員，在查看 Git 分支合并的沖突信息時不抓耳撓腮。

解決 Git 合并沖突是每個開發(fā)人員都討厭的事情之一，尤其是當你準備進行生產(chǎn)環(huán)境部署時！

正確的設(shè)置 Git 工作流可以改善你的 開發(fā)流程^[2] 。

當然，擁有正確的 Git 工作流并不能解決你的所有問題。但這是朝正確方向邁出的一步。畢竟，由于每個團隊都是遠程工作的，在不破壞代碼庫的情況下共同開發(fā)產(chǎn)品功能是非常重要的。

如何設(shè)置 Git 工作流取決于你正在開發(fā)的項目、團隊的發(fā)布計劃、團隊的規(guī)模等等！

在本文中，我們將向你介紹 5 種不同的 Git 工作流，它們的優(yōu)點，缺點以及使用它們的時機。讓我們開始吧！

1. 基本的 Git 工作流

最基本的 Git 工作流是只有一個分支 - master 分支的模式。開發(fā)人員直接提交 master 分支并使用它來部署到預發(fā)布和生產(chǎn)環(huán)境。

上圖為基本的 Git 工作流，所有提交都直接添加到 master 分支。

通常不建議使用此工作流，除非你正在開發(fā)一個 side 項目并且希望快速開始。

由于只有一個分支，因此這里實際上沒有任何流程。這樣一來，你就可以輕松開始使用 Git。但是，使用此工作流時需要記住它的一些缺點：

1. 在代碼上進行協(xié)作將導致多種沖突。
2. 生產(chǎn)環(huán)境出現(xiàn) bug 的概率會大增。
3. 維護干凈的代碼將更加困難。

2. Git 功能分支工作流

當你有多個開發(fā)人員在同一個代碼庫上工作時，Git 功能分支工作流將成為必選項。

假設(shè)你有一個正在開發(fā)一項新功能的開發(fā)人員。另一個開發(fā)人員正在開發(fā)第二個功能?，F(xiàn)在，如果兩個開發(fā)人員都向同一個分支提交代碼，這將使代碼庫陷入混亂，并產(chǎn)生大量沖突。

上圖為具有功能分支的 Git 工作流模型。

為避免這種情況，兩個開發(fā)人員可以分別從 master 分支創(chuàng)建兩個單獨的分支，并分別開發(fā)其負責的功能。完成功能后，他們可以將各自的分支合并到 master 分支，然后進行部署，而不必等待對方的功能開發(fā)完成。

使用此工作流的優(yōu)點是，Git 功能分支工作流使你可以在代碼上進行協(xié)作，而不必擔心代碼沖突。

3. 帶有 Develop 分支的 Git 功能分支工作流

此工作流是開發(fā)團隊中比較流行的工作流之一。它與 Git 功能分支工作流相似，但它的 develop 分支與 master 分支并行存在。

在此工作流中，master 分支始終代表生產(chǎn)環(huán)境的狀態(tài)。每當團隊想要部署代碼到生產(chǎn)環(huán)境時，他們都會部署 master 分支。

Develop 分支代表針對下一版本的最新交付的代碼。開發(fā)人員從 develop 分支創(chuàng)建新分支，并開發(fā)新功能。功能開發(fā)完畢后，將對其進行測試，與 develop 分支合并，在合并了其他功能分支的情況下使用 develop 分支的代碼進行測試，然后與 master 分支合并。

上圖為具有 develop 分支的 Git 功能分支工作流模型。

此工作流的優(yōu)點是，它使團隊能夠一致地合并所有新功能，在預發(fā)布階段對其進行測試并部署到生產(chǎn)環(huán)境中。盡管這種工作流讓代碼維護變得更加容易，但是對于某些團隊來說，這樣做可能會感到有些疲倦，因為頻繁的 Git 操作可能會讓你感到乏味。

4. Gitflow 工作流

Gitflow 工作流與我們之前討論的工作流非常相似，我們將它們與其他兩個分支（ release 分支和 hot-fix 分支）結(jié)合使用。

4.1 Hot-Fix 分支

Hot-fix 分支是唯一一個從 master 分支創(chuàng)建的分支，并且直接合并到 master 分支而不是 develop 分支。僅在必須快速修復生產(chǎn)環(huán)境問題時使用。該分支的一個優(yōu)點是，它使你可以快速修復并部署生產(chǎn)環(huán)境的問題，而無需中斷其他人的工作流，也不必等待下一個發(fā)布周期。

將修復合并到 master 分支并進行部署后，應(yīng)將其合并到 develop 和當前的 release 分支中。這樣做是為了確保任何從 develop 分支創(chuàng)建新功能分支的人都具有最新代碼。

4.2 Release 分支

在將所有準備發(fā)布的功能的代碼成功合并到 develop 分支之后，就可以從 develop 分支創(chuàng)建 release 分支了。

Release 分支不包含新功能相關(guān)的代碼。僅將與發(fā)布相關(guān)的代碼添加到 release 分支。例如，與此版本相關(guān)的文檔，錯誤修復和其他關(guān)聯(lián)任務(wù)才能添加到此分支。

一旦將此分支與 master 分支合并并部署到生產(chǎn)環(huán)境后，它也將被合并回 develop 分支中，以便之后從 develop 分支創(chuàng)建新功能分支時，新的分支能夠具有最新代碼。

上圖為具有 hot-fix 和 release 分支的 Gitflow 工作流模型

此工作流由 Vincent Driessen^[3] 首次發(fā)布并廣受歡迎，已被具有預定發(fā)布周期的組織廣泛使用。

由于 git-flow 是對 Git 的包裝，因此你可以為當前代碼庫安裝 git-flow。git-flow 非常簡單，除了為你創(chuàng)建分支外，它不會更改代碼庫中的任何內(nèi)容。

要在 Mac 機器上安裝 ，請在終端中執(zhí)行 brew install git-flow 。

要在 Windows 機器上安裝，你需要 下載并安裝 git-flow^[4] 。安裝完成后，運行 git flow init 命令，就可以在項目中使用它了。

5. Git Fork 工作流

Fork 工作流在使用開源軟件的團隊中很流行。

該流程通常如下所示：

1. 開發(fā)人員 fork 開源軟件的官方代碼庫。在他們的帳戶中創(chuàng)建此代碼庫的副本。
2. 然后，開發(fā)人員將代碼庫從其帳戶克隆到本地系統(tǒng)。
3. 官方代碼庫的遠端源已添加到克隆到本地系統(tǒng)的代碼庫中。
4. 開發(fā)人員創(chuàng)建一個新的功能分支，該分支將在其本地系統(tǒng)中創(chuàng)建，進行更改并提交。
5. 這些更改以及分支將被推送到其帳戶上開發(fā)人員的代碼庫副本。
6. 從該新功能分支創(chuàng)建一個 pull request，提交到官方代碼庫。
7. 官方代碼庫的維護者檢查 pull request 中的修改并批準將這些修改合并到官方代碼庫中。

你自己的工作流！

我在本文中描述的 Git 工作流是一些在開發(fā)團隊中非常流行和最佳的工作流的示例。也有一些團隊為預發(fā)布創(chuàng)建分支，并且該分支非常適合他們。所以你可以參考這些工作流，然后創(chuàng)建自己的 Git 工作流。

本文使用免費文檔翻譯工具 Breword 進行翻譯，它支持：機器預翻譯、可視化編輯器、協(xié)作翻譯、審校、一鍵生成文檔網(wǎng)站、自動監(jiān)測文檔更新、導出等。讓翻譯工作變得更加簡單、高效、可維護，快去試試吧！

breword 官網(wǎng)：https://www.breword.com/

參考資料