原文：Git Workflows

原作同意翻譯的連結

Google翻譯 + Yahoo字典 + 自己順

幾乎所有程式專案都使用某種版本控制。當我開始使用Git時，我也將它直接用於我的私人專案，但特別在開始時我發現很難以實用的方式構建我的提交和分支。出於這個原因，我想向您展示一些當前的常見策略，即所謂的Git Workflows。

Simple Workflow

簡單的工作流程包含一個主分支，只有這一個分支的修改被推送。此工作流程僅適用於非常小的專案，例如：私人的、只有你自己一個人的工作。隨著團隊的發展，這個工作流變得非常混亂，你將不得不處理很多合併衝突。

特徵分支（新功能分支、Feature Branches）

第二級將功能分支加到簡單工作流程中。這些分支用於開發與專案其他部分分離的新功能，功能完成後，分支將合併。與主分支不同，特徵分支是短暫的，僅在它們合併之前存在。根據其複雜性，通常可以進一步細分特徵分支，因為會再次影響整體結構，所以要確定不要誇張。

開發者分支（Developer Branch）

開發者分支，在主分支旁建立的第二個長壽的分支。這是開發過程中提交的唯一位置，因此主分之始終處於預備發布（release-ready）的狀態。然而，這裡出現了與簡單工作流程類似的問題，這就是為什麼它只應該用於非常小的團隊。

Developer and Feature Branches

前兩種策略可以很好地結合起來。同樣，主分支必須始終準備好發布，功能分支只能與開發人員分支合併。在成功測試開發人員分支上的功能之後，該分支將合併到主分支，然後可以發布。

發布分支（Release Branches）

開發者和特徵分支工作流的延伸通常用於計劃頻繁發布的大型項目。對於新版本，從開發者分支創建新的發布分支，這僅用於最終的錯誤修復，沒有開發新功能。一旦發布版本，分支將合併到主分支和開發者分支。發布分支中的修補程式允許其他團隊在不影響發布工作的情況下處理新功能。

該模型通常由另一個分支補充：修補程式分支(hotfix branch)允許從主分支直接修復錯誤。

哪個概念適合我?

基本上，專案越複雜，工作流程就越複雜。但對於單人專案而言，通常不使用簡單工作流程並使用已經存在的分支策略。例如，我自己的專案目前使用Developer Branch概念。但無論你決定做什麼：確保你有一個一致的分支命名策略（當然還有提交）。

最初發表於blog.mjurtz.com。