在專案一開始的時候大家因該工作在一個branch上一般是master。因為剛開始很多基礎和框架程式碼都還沒有完成，這時候要是做feature brach的時候，會有很多的pull request 的衝突需要merge。在第一個release之後我們就會開始 feature branch開發模型了。一般git和jira會有緊密的結合使用。每個feature brach都會以jira number命名。

master: 主分支一般用於 release brach

feature：新功能的開發

bugfix：Bug修補

tag：每次release都用版本號打個tag來標記這次releae code，如果是生產環境的bug需要基於 tag建立bugfix分支。

Git 是目前最流行的原始碼管理工具。大量的軟體專案由 GitHub、Bitbucket 和 GitLab 這樣的雲服務平臺或是私有的 Git 倉庫來管理。在使用 Git 時通常會遇到的一個問題是採用何種分支管理實踐，即如何管理倉庫中作用不同的各類分支。和軟體開發中的其他實踐一樣，Git 分支管理並沒有普遍適用的最佳做法，而只有對每個團隊和專案而言最適合的做法。簡單來說，在專案開發中使用多個分支會帶來額外的管理和維護開銷，但是多個分支對於專案的團隊合作、新功能開發和釋出管理都是有一定好處的。不同的團隊可以根據團隊人員組成和意願、專案的釋出週期等因素選擇最適合的策略，找到最適合團隊的管理方式。這裡講一下三種常見的 Git 分支管理方式。

單主幹

單主幹的分支實踐（Trunk-based development，TBD）在 SVN 中比較流行。Google 和 Facebook 都使用這種方式。trunk 是 SVN 中主幹分支的名稱，對應到 Git 中則是 master 分支。TBD 的特點是所有團隊成員都在單個主幹分支上進行開發。當需要釋出時，先考慮使用標籤（tag），即 tag 某個 commit 來作為釋出的版本。如果僅靠 tag 不能滿足要求，則從主幹分支建立釋出分支。bug 修復在主幹分支中進行，再 cherry-pick 到釋出分支。圖 1 是 TBD 中分支流程的示意圖。

圖 1. TBD 中的分支流程的示意圖

由於所有開發人員都在同一個分支上工作，團隊需要合理的分工和充分的溝通來保證不同開發人員的程式碼儘可能少的發生衝突。持續整合和自動化測試是必要的，用來及時發現主幹分支中的 bug。因為主幹分支是所有開發人員公用的，一個開發人員引入的 bug 可能對其他很多人造成影響。不過好處是由於分支所帶來的額外開銷非常小。開發人員不需要頻繁在不同的分支之間切換。

GitHub flow

GitHub flow 是 GitHub 所使用的一種簡單的流程。該流程只使用兩類分支，並依託於 GitHub 的 pull request 功能。在 GitHub flow 中，master 分支中包含穩定的程式碼。該分支已經或即將被部署到生產環境。master 分支的作用是提供一個穩定可靠的程式碼基礎。任何開發人員都不允許把未測試或未審查的程式碼直接提交到 master 分支。

對程式碼的任何修改，包括 bug 修復、hotfix、新功能開發等都在單獨的分支中進行。不管是一行程式碼的小改動，還是需要幾個星期開發的新功能，都採用同樣的方式來管理。當需要進行修改時，從 master 分支建立一個新的分支。新分支的名稱應該簡單清晰地描述該分支的作用。所有相關的程式碼修改都在新分支中進行。開發人員可以自由地提交程式碼和 push 到遠端倉庫。

當新分支中的程式碼全部完成之後，透過 GitHub 提交一個新的 pull request。團隊中的其他人員會對程式碼進行審查，提出相關的修改意見。由持續整合伺服器（如 Jenkins）對新分支進行自動化測試。當代碼透過自動化測試和程式碼審查之後，該分支的程式碼被合併到 master 分支。再從 master 分支部署到生產環境。圖 2 是 GitHub flow 分支流程的示意圖。

圖 2. Github flow 中的分支流程的示意圖

GitHub flow 的好處在於非常簡單實用。開發人員需要注意的事項非常少，很容易形成習慣。當需要進行任何修改時，總是從 master 分支建立新分支。完成之後透過 pull request 和相關的程式碼審查來合併回 master 分支。GitHub flow 要求專案有完善的自動化測試、持續整合和部署等相關的基礎設施。每個新分支都需要測試和部署，如果這些不能自動化進行，會增加開發人員的工作量，導致無法有效地實施該流程。這種分支實踐也要求團隊有程式碼審查的相應流程。

git-flow

git-flow 應該是目前流傳最廣的 Git 分支管理實踐。git-flow 圍繞的核心概念是版本釋出（release）。因此 git-flow 適用於有較長版本釋出週期的專案。雖然目前推崇的做法是持續整合和隨時釋出。有的專案甚至可以一天釋出很多次。隨時釋出對於 SaaS 服務類的專案來說是很適合的。不過仍然有很大數量的專案的釋出週期是幾個星期甚至幾個月。較長的釋出週期可能是由於非技術相關的因素造成的，比如人員限制、管理層決策和市場營銷策略等。

git-flow 流程中包含 5 類分支，分別是 master、develop、新功能分支（feature）、釋出分支（release）和 hotfix。這些分支的作用和生命週期各不相同。master 分支中包含的是可以部署到生產環境中的程式碼，這一點和 GitHub flow 是相同的。develop 分支中包含的是下個版本需要釋出的內容。從某種意義上來說，develop 是一個進行程式碼整合的分支。當 develop 分支集成了足夠的新功能和 bug 修復程式碼之後，透過一個釋出流程來完成新版本的釋出。釋出完成之後，develop 分支的程式碼會被合併到 master 分支中。

其餘三類分支的描述如表 1所示。這三類分支只在需要時從 develop 或 master 分支建立。在完成之後合併到 develop 或 master 分支。合併完成之後該分支被刪除。這幾類分支的名稱應該遵循一定的命名規範，以方便開發人員識別。

表 1. git-flow 分支型別

對於開發過程中的不同任務，需要在對應的分支上進行工作並正確地進行合併。每個任務開始前需要按照指定的步驟完成分支的建立。例如當需要開發一個新的功能時，基本的流程如下：

從 develop 分支建立一個新的 feature 分支，如 feature/my-awesome-feature。在該 feature 分支上進行開發，提交程式碼，push 到遠端倉庫。當代碼完成之後，合併到 develop 分支並刪除當前 feature 分支。

在進行版本釋出和 hotfix 時也有類似的流程。當需要釋出新版本時，採用的是如下的流程：

從 develop 分支建立一個新的 release 分支，如 release/1.4。把 release 分支部署到持續整合伺服器上進行測試。測試包括自動化整合測試和手動的使用者接受測試。對於測試中發現的問題，直接在 release 分支上提交修改。完成修改之後再次部署和測試。當 release 分支中的程式碼透過測試之後，把 release 分支合併到 develop 和 master 分支，並在 master 分支上新增相應的 tag。

因為 git-flow 相關的流程比較繁瑣和難以記憶，在實踐中一般使用輔助指令碼來完成相關的工作。比如同樣的開發新功能的任務，可以使用 git flow feature start my-awesome-feature 來完成新分支的建立，使用 git flow feature finish my-awesome-feature 來結束 feature 分支。輔助指令碼會完成正確的分支建立、切換和合並等工作。

Dev和master是根基

Feature是每人的分支，新功能在此分支開發，自測之後合併到Dev分支做整體測試。

後merge到master生產部署

bugfix解決master的問題，解決完之後merge到master和dev