> - 原文地址：[5 Git workflows you can use to deliver better code and improve your development process](https://zepel.io/blog/5-git-workflows-to-improve-development/) > - 原文作者：Vikash Koushik > - 譯者：陳元 > - 校對者：HelloGitHub-丫丫 我還沒有遇到過一個開發人員，在檢視 Git 分支合併的衝突資訊時不抓耳撓腮。 解決 Git 合併衝突是每個開發人員都討厭的事情之一，尤其是當你準備進行生產環境部署時！ 正確的設定 Git 工作流可以改善你的 [開發流程](https://zepel.io/blog/simple-software-development-workflow/) 。 當然，擁有正確的 Git 工作流並不能解決你的所有問題。但這是朝正確方向邁出的一步。畢竟，由於每個團隊都是遠端工作的，在不破壞程式碼庫的情況下共同開發產品功能是非常重要的。 如何設定 Git 工作流取決於你正在開發的專案、團隊的釋出計劃、團隊的規模等等！ 在本文中，我們將向你介紹 5 種不同的 Git 工作流，它們的優點，缺點以及使用它們的時機。讓我們開始吧！ ## 1\. 基本的 Git 工作流 最基本的 Git 工作流是隻有一個分支 - master 分支的模式。開發人員直接提交 master 分支並使用它來部署到預釋出和生產環境。  上圖為基本的 Git 工作流，所有提交都直接新增到 master 分支。 通常不建議使用此工作流，除非你正在開發一個 side 專案並且希望快速開始。 由於只有一個分支，因此這裡實際上沒有任何流程。這樣一來，你就可以輕鬆開始使用 Git。但是，使用此工作流時需要記住它的一些缺點： 1. 在程式碼上進行協作將導致多種衝突。 2. 生產環境出現 bug 的概率會大增。 3. 維護乾淨的程式碼將更加困難。 ## 2\. Git 功能分支工作流 當你有多個開發人員在同一個程式碼庫上工作時，Git 功能分支工作流將成為必選項。 假設你有一個正在開發一項新功能的開發人員。另一個開發人員正在開發第二個功能。現在，如果兩個開發人員都向同一個分支提交程式碼，這將使程式碼庫陷入混亂，併產生大量衝突。  上圖為具有功能分支的 Git 工作流模型。 為避免這種情況，兩個開發人員可以分別從 master 分支建立兩個單獨的分支，並分別開發其負責的功能。完成功能後，他們可以將各自的分支合併到 master 分支，然後進行部署，而不必等待對方的功能開發完成。 使用此工作流的優點是，Git 功能分支工作流使你可以在程式碼上進行協作，而不必擔心程式碼衝突。 ## 3\. 帶有 Develop 分支的 Git 功能分支工作流 此工作流是開發團隊中比較流行的工作流之一。它與 Git 功能分支工作流相似，但它的 develop 分支與 master 分支並行存在。 在此工作流中，master 分支始終代表生產環境的狀態。每當團隊想要部署程式碼到生產環境時，他們都會部署 master 分支。 Develop 分支代表針對下一版本的最新交付的程式碼。開發人員從 develop 分支建立新分支，並開發新功能。功能開發完畢後，將對其進行測試，與 develop 分支合併，在合併了其他功能分支的情況下使用 develop 分支的程式碼進行測試，然後與 master 分支合併。  上圖為具有 develop 分支的 Git 功能分支工作流模型。 此工作流的優點是，它使團隊能夠一致地合併所有新功能，在預釋出階段對其進行測試並部署到生產環境中。儘管這種工作流讓程式碼維護變得更加容易，但是對於某些團隊來說，這樣做可能會感到有些疲倦，因為頻繁的 Git 操作可能會讓你感到乏味。 ## 4\. Gitflow 工作流 Gitflow 工作流與我們之前討論的工作流非常相似，我們將它們與其他兩個分支（ release 分支和 hot-fix 分支）結合使用。 ### 4.1 Hot-Fix 分支 Hot-fix 分支是唯一一個從 master 分支建立的分支，並且直接合併到 master 分支而不是 develop 分支。僅在必須快速修復生產環境問題時使用。該分支的一個優點是，它使你可以快速修復並部署生產環境的問題，而無需中斷其他人的工作流，也不必等待下一個釋出週期。 將修復合併到 master 分支並進行部署後，應將其合併到 develop 和當前的 release 分支中。這樣做是為了確保任何從 develop 分支建立新功能分支的人都具有最新程式碼。 ### 4.2 Release 分支 在將所有準備釋出的功能的程式碼成功合併到 develop 分支之後，就可以從 develop 分支建立 release 分支了。 Release 分支不包含新功能相關的程式碼。僅將與釋出相關的程式碼新增到 release 分支。例如，與此版本相關的文件，錯誤修復和其他關聯任務才能新增到此分支。 一旦將此分支與 master 分支合併並部署到生產環境後，它也將被合併回 develop 分支中，以便之後從 develop 分支建立新功能分支時，新的分支能夠具有最新程式碼。  上圖為具有 hot-fix 和 release 分支的 Gitflow 工作流模型 此工作流由 [Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/) 首次釋出並廣受歡迎，已被具有預定釋出週期的組織廣泛使用。 由於 git-flow 是對 Git 的包裝，因此你可以為當前程式碼庫安裝 git-flow。git-flow 非常簡單，除了為你建立分支外，它不會更改程式碼庫中的任何內容。 要在 Mac 機器上安裝 ，請在終端中執行 `brew install git-flow` 。 要在 Windows 機器上安裝，你需要 [下載並安裝 git-flow](https://git-scm.com/download/win) 。安裝完成後，執行 `git flow init` 命令，就可以在專案中使用它了。 ## 5\. Git Fork 工作流 Fork 工作流在使用開源軟體的團隊中很流行。 該流程通常如下所示： 1. 開發人員 fork 開源軟體的官方程式碼庫。在他們的帳戶中建立此程式碼庫的副本。 2. 然後，開發人員將程式碼庫從其帳戶克隆到本地系統。 3. 官方程式碼庫的遠端源已新增到克隆到本地系統的程式碼庫中。 4. 開發人員建立一個新的功能分支，該分支將在其本地系統中建立，進行更改並提交。 5. 這些更改以及分支將被推送到其帳戶上開發人員的程式碼庫副本。 6. 從該新功能分支建立一個 pull request，提交到官方程式碼庫。 7. 官方程式碼庫的維護者檢查 pull request 中的修改並批准將這些修改合併到官方程式碼庫中。 ## 你自己的工作流！ 我在本文中描述的 Git 工作流是一些在開發團隊中非常流行和最佳的工作流的示例。也有一些團隊為預釋出建立分支，並且該分支非常適合他們。所以你可以參考這些工作流，然後建立自己的 Git 工作流。 --- 本文使用免費文件翻譯工具 **Breword** 進行翻譯，它支援：機器預翻譯、視覺化編輯器、協作翻譯、審校、一鍵生成文件網站、自動監測文件更新、匯出等。讓翻譯工作變得更加簡單、高效、可維護，快去試試吧！ > breword 官網：https://www.breword.com/ ---  翻譯開源專案文件、文章都是為開源社群做貢獻（題材：GitHub、程式設計、程式設計師）​，歡迎熱愛技術和開源的小夥伴加入 HG 推出的譯文亦舞系列的翻譯中來，可新增微訊號：HelloGitHub（備註：翻譯）。