根據專案型別、公司規模、團隊偏好和許多其他因素，每個團隊都有自己的工作流程。 團隊越大，管理就越困難：問題相沖突變得更加普遍，推遲釋出日期，工作任務優先權不斷變化，專案工作列表無窮無盡。

第一步就是使用Git，它能解決這些一直困擾著我們的問題。以下是您可以在業務中使用的5種最流行的Git工作流程：

一、基本流程

執行方法很簡單：設一個儲存倉。 每個程式設計師都可以從程式碼儲存倉下載原始碼，然後在本地處理開發程式碼，建立帶有更改的提交資訊，並將其推送到這個中心儲存倉，以供其他程式設計師在參與、提取、開發和使用。

二、功能分支

基本工作流程非常適合開發簡單的網站。 但是，一旦兩個程式設計師開始在一個專案中開發兩個不同的功能，問題就會慢慢顯露出來。

假設其中一位程式設計師完成了他們的功能並想要釋出。 由於第二個功能還沒有完成，那這個時候只能等另一個。 此時釋出可能會導致混亂。

這就是分支Git的核心特性派上用場的地方。 分支是專案開發的獨立“軌道”。 對於每個新功能，都應該建立一個新分支，在此開發和測試新功能。 功能準備就緒後，可以將分支合併到主分支

(Master/Main)

，以便將其釋出到正式運營的伺服器。

功能分支與合併請求

功能分支工作流程預設團隊中的所有開發人員都具有相同的技術水平與職位。 然而，在更大的團隊中，公司中總是存在某種形式的等級制度。

在這種情況下，您可以使用合併請求和推送許可權，允許您限制推送到儲存庫中的選定分支並保持對程式碼的完全控制管理。

在將分支合併到主分支之前，需要對其進行驗證和檢查是否出錯。 初級程式設計師可以建立合併請求並將其分配給其中一位高階程式設計師，這樣他們就可以檢視程式碼並發表評論。 如果一切正常，則接受請求合併分支。

三、Gitflow

專案越大您就越需要控制釋出的內容與時間。 專案需要更多的單元與整合測試，這樣執行一次至少幾小時。 但您沒必要在開發功能的分支上執行此類測試。

因此，可以透過Gitflow解決，這是由Vincent Driessen於2010年提出且闡述的Git開發工作流程。

此工作流使用兩個並行長時間執行的分支：

主分支

僅用於專案釋出

開發分支

建立自主分支，為下一個版本準備的已全部完成開發且功能穩定的分支所在位置

當您開始開發新功能時，從開發分支中建立一個新功能分支。根據需要同時建立多個功能分支。 完成開發並測試功能後，將程式碼合併回開發分支。然後，當釋出專案時，將新功能與新發布分支上的開發分支隔離開來。 確保該版本經過良好的、穩定的測試。

此時根據專案的特點，向公眾釋出軟體的RC版本也許是一個不錯的主意。當版本穩定並且所有問題都解決後，將您的釋出分支合併回主分支並部署到正式運營中！

四、分叉流程

就像在公海上一樣，在開源中一切都取決於船長。在軟體方面，儲存倉所有者決定誰可以推送到儲存倉。儘管開源的理念是每個人都可以為專案做出貢獻，但我們想一想，要是老萊（Linus Torvalds）允許任何人無限許可權地修改Linux專案儲存倉的程式碼，會不會很好玩？

這個問題由分叉解決：任何時候開發人員想要更改開源專案中的某些內容，他們都不會直接在專案的儲存倉上工作。相反，直接透過分叉並有效地建立整個儲存倉副本。然後，程式設計師可以自由地以他們的喜好開發新功能。值得一提的是，分叉也為建立針對特定應用程式調整的某些元件自定義版本提供了無限可能性。程式設計師或公司可以分叉一個儲存倉並將程式碼帶到一個全新的方向，當然，專案創始人可能會有異議。

然而，在大多數情況下，當工作完成時，會建立一個拉取請求，將程式設計師引入其分支的更改與分支儲存倉狀態進行比較。在那裡，社群和專案所有者可以審查、討論和測試更改。最後的決定權仍掌握在該專案的船長及其副手之中。

五、您自己定義的Git流程

在本文描述的Git工作流程只是一些示例。 Git最大的特點是您可以選擇現有的工作流程並輕鬆地使其達到您的需求。 例如，我在Buddy（一個DevOps自動化平臺）中使用經過修改的Gitflow和額外的暫存分支為我帶來了更高效的開發效率。

最後，我求求那些企業所有者，技術出身也好、暴發戶也罷(當然土豪自便)，從今天開始用Git開發您的專案吧！別到了被刪庫跑路才來哭鼻子！