ChienI Kao

筆記網站

JHTNT

筆記網站

當大家一起開發專案時，專案撰寫的內容越來越多，Git Commit 內容增加，就很容易有 Git Graph 非常雜亂的問題，對某一個功能重複撰寫等等。
這個時候就非常需要工作流程 (Work Flow)，讓大家有規劃，更效率地開發。

# 常見 Work Flow

Git Flow
GitHub Flow
GitLab Flow

# 定義部署的環境

開發環境（工程師的電腦）
測試環境（讓審核人員測試使用，像是 QA 測試）
展示環境（讓早期用戶或是驗收使用）
產品環境（正式讓所有用戶使用）

# Git Flow

Git Flow 是上述三種 Work Flow 中最早出現的。

master
負責管理發布的狀態。當準備好發佈指定版本時，最後的提交會給予一個發布版本標籤。
develop
Develop 分支是針對日常開發的分支。所有新功能開發最終都會合併到這裡。
feature
這個分支是新功能的開發或修復錯誤的時候從 develop 分支分開出來的。
release
Release 分支是為了發布而準備的。通常這種分支的名稱最前面會加上 "release-"。
hotfit
Hot fix 分支是在發布的產品需要緊急修改時，從 master 分支建立的分支。
通常會在分支名稱的最前面會加上 "hotfix-"。

# 開發過程

從 master 分支拉出一條分支 develop 進行日常開發。
要開發新功能 / 修復錯誤時，從 develop 分支拉取一條 feature 分支。
開發完成後，將 feature 分支合入到 develop 分支，並進行開發環境的驗證。
確認完成後，從 develop 分支拉取一條 release 分支，到測試環境進行 SIT/UAT 測試。
測試完成後，可將 release 分支合入 master 分支並將現在內容給回 develop 分支。
版本部屬時，直接將 master 分支程式碼部署到最終環境。

優點:

每個分支都有明確的定義，嚴格按照 Git Flow 管理專案程式碼的話，很難出現程式碼混亂

缺點:

如果 feature 分支過多的話很容易造成程式碼衝突，從而提高了合入的成本
由於每次提交都涉及多個分支，所以 Git Flow 也太不適合提交頻率較高的項目

# GitHub Flow & GitLab Flow

By 因為我還沒研究過 GitHub Flow & GitLab Flow，所以這裡提供我覺得寫得很不錯的文章給大家參考

文章

medium.com/@trylovetom

讓我們來了解 GitHub Flow 吧！除了會 Git 你還需要 Work Flow

medium.com/i-think-so-i-live

Git上的三種工作流程