Terry Yao's Blog

GitHub Flow：簡單高效的分支管理模型

閱讀時間約 9 分鐘

cover

GitHub Flow：簡單高效的分支管理模型

看完 Git Flow 之後，你可能會想：「也太複雜了吧！有沒有更簡單的方法？」答案是：有的！GitHub Flow 就是為了解決這個問題而生的。

前言

GitHub Flow 是一種輕量級、基於分支的工作流程，適用於需要快速集成和持續發佈的專案。它由 GitHub 的工程師 Scott Chacon 提出，核心理念就是「簡單」。與 Git Flow 相比，GitHub Flow 只使用 master 和 feature 分支，適合小型專案和快速迭代的開發環境。

說白了，GitHub Flow 就是：開分支、寫 code、開 PR、review、合併、部署。就這麼簡單。

GitHub Flow 的基本概念

GitHub Flow 的核心思想是：

  1. 一切都在 master 分支上進行。
  2. 創建一個新的分支來開發新功能或修復 bug。
  3. 當開發完成時，發起一個 Pull Request 請求合併。
  4. 在 Pull Request 中進行代碼審查和測試。
  5. 如果代碼審查通過，就可以合併到 master 分支。
  6. 合併後，master 分支上的代碼就可以部署到生產環境了。

GitHub Flow 流程圖

flowchart TD
    A[main 分支] -->|1. 建立分支| B[feature/xxx]
    B -->|2. 開發 & 提交| C[推送到遠端]
    C -->|3. 開 Pull Request| D[Code Review]
    D -->|4. 審查通過| E{合併到 main}
    D -->|需要修改| B
    E -->|5. 自動部署| F[Production]
    
    style A fill:#4CAF50,color:#fff
    style F fill:#2196F3,color:#fff

跟 Git Flow 比起來，是不是簡單多了？沒有 develop、release、hotfix 那些有的沒的，就是一條主線加上功能分支。

如何使用 GitHub Flow

  1. 從 master 分支創建一個新的分支：

    git checkout -b feature/new-feature

  2. 在新分支上進行開發和提交：

    git add .
git commit -m "Add new feature"
git push origin feature/new-feature

  3. 在 GitHub 上發起一個 Pull Request：

    • 在 GitHub 頁面上，點擊 Compare & pull request 按鈕。
    • 填寫 PR 標題和描述，描述本次 PR 的內容。

  4. 在 PR 頁面進行代碼審查和測試：

    • 其他開發者可以查看變更內容並進行代碼審查。
    • 可以運行自動化測試來確保新功能的正確性。

  5. 合併 PR 到 master 分支：

    • 如果代碼審查通過，就可以點擊 Merge pull request 按鈕將分支合併到 master。
    • 合併後，master 分支上的代碼就是最新的版本。

  6. 部署到生產環境：

    • 合併到 master 後，可以自動部署到生產環境。
    • 可以結合 CI/CD 工具來自動化部署流程。

優點和缺點

優點

  • 簡單易用：只使用 master 和 feature 分支，流程簡單明了。
  • 靈活性高：適合快速迭代和持續發佈的開發環境。
  • 適合小型專案：對於小型專案或單人開發，GitHub Flow 更加輕量。
  • 促進代碼審查：Pull Request 強化了團隊內部的代碼審查機制，提高代碼質量。

缺點

  • 不適合大型專案：對於需要明確版本發佈和多個穩定分支的大型專案，GitHub Flow 可能不太適合。
  • 缺乏版本控制：沒有 Git Flow 中的 develop 和 release 分支，可能會影響版本管理。
  • 依賴持續部署：需要穩定的部署環境和自動化工具支持，否則部署流程可能會混亂。

實際案例

案例一：快速迭代的 Web 應用開發

在一個需要頻繁發布新功能的 Web 應用專案中，團隊採用 GitHub Flow 來管理分支和發佈流程。每個新功能都在獨立的 Feature 分支上開發，完成後通過 Pull Request 合併到 master 分支，並立即部署到生產環境。這種方式使得團隊能夠快速迭代，迅速響應市場需求。

案例二：協作開發中的代碼審查

在一個多開發者協作的專案中，團隊使用 GitHub Flow 來管理分支。每個開發者在自己的 Feature 分支上工作，完成後通過 Pull Request 提交代碼，其他團隊成員進行審查和測試。這不僅提升了代碼質量，還促進了團隊內部的知識共享和協作。

實作示例

以下是使用 GitHub Flow 的具體步驟：

步驟 1：從 master 創建新分支

git checkout -b feature/signup-system

步驟 2：在新分支上開發和提交

git add .
git commit -m "Add signup feature"
git push origin feature/signup-system

步驟 3：發起 Pull Request

  • 在 GitHub 上，點擊 Compare & pull request 按鈕。
  • 填寫 PR 標題和詳細描述。

步驟 4：代碼審查和測試

  • 其他團隊成員審查代碼。
  • 運行自動化測試，確保功能正常。

步驟 5：合併 Pull Request

  • 點擊 Merge pull request，將 feature/signup-system 合併到 master。

步驟 6：部署到生產環境

  • 合併後，自動部署到生產環境，使用戶可以立即使用新功能。

工具和插件推薦

為了更好地實現 GitHub Flow，以下是一些推薦的工具：

  • GitHub Actions：自動化工作流程工具，支援自動測試和部署。
  • Travis CI：持續整合工具，與 GitHub 無縫集成。
  • Jenkins：靈活的自動化服務器，適合複雜的 CI/CD 流程。
  • Pull Request Template：使用模板來標準化 PR 描述，提升審查效率。

最佳實踐提示

  • 保持 master 分支穩定：確保 master 分支始終處於可部署狀態，所有合併的變更都經過充分測試。
  • 小步快跑：將變更拆分為小的、可管理的 Feature 分支，便於審查和測試。
  • 自動化測試與部署：結合 CI/CD 工具，自動化代碼測試和部署流程，提升效率和可靠性。
  • 代碼審查：通過 Pull Request 進行代碼審查，確保代碼質量和一致性。
  • 清晰的 PR 描述：在 Pull Request 中詳細描述變更內容和原因，幫助審查者更好地理解變更。

常見問題解答

問：GitHub Flow 適用於哪些專案？

答：GitHub Flow 適用於需要快速迭代和持續部署的小型至中型專案，特別是 Web 應用和 SaaS 產品。

問：如果需要明確的版本發佈，是否應該使用 GitHub Flow？

答：如果專案需要明確的版本發佈和多個穩定分支，建議使用 Git Flow 或 GitLab Flow，而非 GitHub Flow。

問：如何在 GitHub Flow 中處理熱修復？

答：在 GitHub Flow 中，熱修復可以通過直接在 master 分支上創建一個臨時的 Hotfix 分支來進行，完成後立即合併回 master 分支並部署。

總結

GitHub Flow 是一種簡單高效的分支管理模型，適合小型專案和快速迭代的開發環境。它強調簡單性和靈活性，只使用 master 和 feature 分支，通過 Pull Request 進行代碼審查和合併。如果你的團隊追求「快速交付」和「持續部署」，GitHub Flow 絕對是個好選擇。

參考資源

延伸閱讀

關係圖譜

反向連結