專業的 Git 工作流程：一個好的 Git 指南

Git 不僅可以通過版本控制來支持您的項目，還可以通過協作和發布管理來支持您的項目。 了解 Git 工作流模式如何幫助或阻礙項目將為您提供有效評估和調整項目 Git 流程的知識。

在本指南中，我將隔離常見 Git 工作流程中的軟件開發流程模式。 了解這些知識將幫助您在加入、創建或發展開發團隊時找到方向。 某些類型的項目或團隊的優缺點將在我們探索的工作流示例中突出顯示，以便您可以挑選適合您的場景的方法。

這不是使用 Git 的介紹。 那裡已經有很棒的指南和文檔。 如果您已經在應用程序開發團隊中擁有經驗並且遇到過工作流障礙、集成內爆或 git-tastrophes，那麼您將從這個 Git 工作流指南中受益——這些模式可能會為將來如何避免這些情況提供一些啟示。

合作

就 Git 流程而言，協作通常是關於分支工作流。 提前考慮如何將提交樹交織在一起將幫助您最大限度地減少集成錯誤並支持您的發布管理策略。

集成分公司

與軟件開發團隊一起使用集成分支，這些團隊致力於將一系列貢獻部署到生產中作為單個實體。 這與專注於單獨部署功能的團隊相反。 通常團隊可能希望做後者，但實際限制強加了一個將他們的努力分組的過程，團隊最終會做前者，所以一定要檢查你的實際 Git 使用情況，看看你是否會從使用這種類型的協作中受益圖案。

當集成多個分支的風險高到足以保證測試整體的組合貢獻時，此工作流模式是一個有用的過渡點。

一個集成分支通常由一個主要特性和幾個要一起部署的較小貢獻組成。 在您的開發團隊的流程中放置一個集成分支（例如問答和驗收測試）。 將次要提交推送到它以使其接近生產就緒狀態，然後使用環境分支或發布分支（如下所述）為部署做好準備。

請注意，集成分支上的貢獻需要合併到下一個發布階段，然後才能將另一個主要功能合併到集成分支中 - 否則您將在完成的不同階段混合功能。 這會抑制你釋放準備好的東西的能力。

主題分支

如果將提交樹保持在易於閱讀或恢復單個功能的狀態很重要，團隊將希望使用主題分支。 主題分支表示提交可能會被覆蓋（使用強制推送）以清理其結構並縮小為功能提交。

主題分支通常由個人貢獻者擁有，但也可以是團隊開發功能的指定空間。 其他貢獻者知道這種類型的分支可以隨時重寫其提交樹，並且不應嘗試使其本地分支與其同步。

如果在 Git 工作流程中不使用主題分支，您將受限於推送到遠程分支的提交。 強制將新的提交樹推送到遠程分支可能會激怒其他依賴與他們同步的分支的維護完整性的貢獻者。

您可能已經在沒有意識到的情況下使用此工作流模式，但值得在團隊之間共享一組定義以加強他們背後的實踐。 例如，您可能會發現在分支名稱前加上分支創建者的首字母的約定有助於表明哪些是主題分支。 無論哪種方式，都由您的團隊決定內部約定。

不要在公共存儲庫上使用主題分支，對於將本地分支與已重寫提交樹的主題分支同步的任何人，您都會導致無數衝突。

叉

使用這個源自 Github 的功能，開源項目蓬勃發展。 分叉為存儲庫維護者提供了一個強製網關，而不是直接推送到原始存儲庫分支，但更重要的是它促進了協作。 哇！

您可能會發現自己在創建私有存儲庫的分支也適合您的需求的情況下。 將 fork 存儲庫的貢獻者的原始存儲庫設置為只讀並使用拉取請求為您提供與開源社區體驗相同的好處。 來自不同組織的團隊可以使用分叉有效地工作，該分叉可以作為溝通和項目政策遵守的平台。

分叉工作流模式為團隊提供了自己的空間，可以以他們習慣的任何方式工作，兩個存儲庫之間有一個集成點——拉取請求。 在拉取請求描述中，過度溝通是必不可少的。 在發布拉取請求之前，團隊有單獨的溝通流，突出顯示已經做出的決定將加快審查過程。

當然，fork 工作流程的一個好處是您可以將評論直接發送給原始存儲庫的貢獻者，因為權限會向下級聯。 從源存儲庫的角度來看，您可以控制在不再需要分叉時刪除它們。

確保您使用的工具有助於分叉和拉取請求以利用此模式。 這些工具不僅限於 Github：其他流行的選擇還有 Bitbucket 和 GitlLab。 但是還有相當多的其他 Git 工作流託管服務將具有這些功能（或類似功能）。 選擇最適合您的服務。

不要為團隊的每個成員使用私有存儲庫的分支。 眾多的分叉存儲庫可能使多個成員難以在同一個功能分支上進行協作，並且由於移動部件的數量龐大，使所有這些存儲庫保持同步可能會變得容易出錯。 開源項目的核心團隊成員具有對原始存儲庫的推送訪問權限，從而減少了這種開銷。

克隆

一個常見的外包策略是在一個項目中擁有可以由多個軟件開發人員擔任的貢獻“席位”。 由外包公司管理他們的資源管道以交付合同工時，他們面臨的問題是如何為每個客戶的項目加入、培訓和維護他們的開發人員庫。

使用項目存儲庫的克隆為外包團隊提供了一個孤立的培訓和交流平台，以管理他們的貢獻、執行政策和利用知識共享——所有這些都在客戶開發團隊的監視下進行。 一旦認為貢獻符合標準並準備好用於主存儲庫，就可以將其推送到源存儲庫遠程分支之一併照常集成。

一些項目對遵循其編碼約定和定義的 Git 工作流標準以貢獻其存儲庫有很高的期望。 在您掌握訣竅之前，在這種環境中工作可能會讓人望而生畏，因此請作為一個團隊一起工作以優化雙方的時間。

不要在未經客戶許可的情況下創建客戶存儲庫的託管副本，您可能會違反合同協議，請預先確認這種做法將有利於客戶的項目。

發布管理

從協作到發布之間的步驟將從每個團隊的開發過程中的不同點開始。 通常，您不希望使用多個版本管理 Git 模式。 您希望擁有最簡單的工作流程，使您的團隊能夠有效地交付。

環境分支

您的軟件開發過程可能會受到多個環境的支持，以幫助在部署到生產之前進行質量保證。 環境分支模擬了這個過程的各個階段：每個階段對應一個分支，貢獻在管道中流經這些階段。

使用這些流程運行的團隊通常會為管道中的每個階段設置應用程序環境，例如“QA”、“Staging”和“Production”。 在這些情況下，基礎設施已經到位，以支持負責簽署功能或貢獻的人員，他們對生產就緒的意義（例如，探索性測試、質量保證、驗收測試）進行了驗證，然後再將其轉移到下一個人的階段。 這為他們提供了根據自己的要求進行部署、測試和評估的地方，並使用 Git 工作流來記錄其通過簽核隧道的旅程。

對於可以將發布作為一個單元工作的小型團隊來說，在流程的每個階段都有一個分支是可以的。 不幸的是，這樣的管道很容易成為瓶頸或聚集並留下空隙。 它將您的 Git 進程與您的基礎設施耦合在一起，當功能需求增加並且兩個進程都需要擴展時，這可能會導致問題。

不要在不首先考慮其他模式的長期利益的情況下使用此模式。

發布分支

在連續衝刺中將一系列貢獻作為一個單元推送到其生產應用程序的團隊可以找到發布分支的合適選擇。

在發布分支上對一系列接近“生產就緒”的提交進行了小錯誤修復。 在將其提交樹移動到發布分支之前，使用集成分支來組合和測試功能。 將發布分支的職責限制為在部署到生產應用程序之前作為最終檢查。

發布分支與環境分支的不同之處在於它們的生命週期很短。 發布分支僅在需要時創建，並在其提交樹部署到生產環境後銷毀。

盡量防止將發布分支與您的軟件開發路線圖耦合。 限制自己遵循預先確定的計劃會延遲發布版本，直到所有計劃的功能都準備好生產。 在創建發布分支之前不為路線圖分配版本號可以緩解這些類型的延遲，方法是允許將生產準備就緒的功能放入發布分支並進行部署。

請使用版本號命名約定作為發布分支名稱，以明確已將哪個版本的存儲庫部署到生產環境中。

部署主分支而不是發布分支。 為了鼓勵在與主分支合併之前對發布分支進行小修復，請在主分支上使用 Git 掛鉤在發生合併後觸發以自動將更新的提交樹部署到生產中。

在給定的時間只允許一個發布分支存在確保您將避免保持多個發布分支彼此同步的開銷。

不要使用多個團隊在同一個存儲庫上工作的發布分支。 儘管發布分支是短暫的，但如果最終檢查它花費的時間太長，那麼它會阻止其他團隊發布。 一個團隊捎帶另一個團隊的發布分支很可能會引入錯誤並導致兩個團隊的延遲。 看看下面的帶時間戳的發布模式，它對更多和更多的貢獻者來說效果更好。

時間戳發布

具有基礎設施限制的應用程序通常在低流量期間安排其部署。 如果您的項目面臨準備部署的常規功能隊列，那麼您可能會從使用時間戳發布中受益。

帶時間戳的發布依賴於部署過程來自動將時間戳標記添加到部署到生產中的主分支上的最後一次提交。 主題分支用於在合併到主分支以等待部署之前將功能通過開發過程。

時間戳標籤應該包含一個實際的時間戳和一個標籤，以表明它代表一個部署，例如： deployed-201402121345 。

在主分支的提交樹中以時間戳標記的形式包括部署元數據，將幫助您調試發佈到生產應用程序中的回歸。 負責追查問題原因的人員不太可能對部署到生產應用程序中的每一行都非常了解。 在最後兩個標籤上運行git diff命令可以快速給出最後部署的提交以及可以幫助解決問題的提交作者的快照。

帶時間戳的分支比表面上出現的要多。 記錄排隊功能部署的簡單機制需要大量的良好流程來驅動它。 這個過程是一個可以擴展的過程，也可以與一小部分貢獻者一起很好地工作。

為了讓這個 Git 工作流模式真正有效，它需要 master 分支始終是可部署的。 這對您的團隊可能意味著不同的事情，但基本上所有提交都必須經過您的項目開發過程，然後才能進入主分支。

登陸主分支的新提交每天會發生多次。 這是已經通過開發過程並且在此期間沒有與主分支同步的主題分支的問題。 不幸的是，當錯誤處理合併衝突時，這種情況可能會在主分支中引入回歸。

如果主題分支和主分支之間確實出現合併衝突，那麼在更新遠程主分支之前，應該與您的團隊討論引入新錯誤的風險。 如果對可能發生回歸有任何疑問，則可以通過質量保證過程放回主題分支，並解決合併衝突。

為了減少集成錯誤，在存儲庫的相關部分工作的開發人員可以協作確定何時最好地將他們的主題分支與主分支合併和同步。 集成分支也可以很好地解決來自相關主題分支的衝突——這些應該在被合併到主分支待部署的隊列中之前通過測試過程。

有許多貢獻者的軟件開發項目必須以實用和有效的方法處理協作和發布管理過程。 我們從使用時間戳發布獲得的提交樹上的額外元數據是指向準備響應生產問題的團隊的遠見的指針。

版本分支

如果您的存儲庫不僅在生產中運行，而且其他人用於他們自己的託管應用程序，那麼使用版本分支可以為您的團隊提供平台來支持那些不或不能保持在應用程序開發前沿的用戶.

使用版本分支的存儲庫將有一個應用程序的每個次要版本的分支。 主要、次要和補丁版本在語義版本控製文檔中進行了說明。 版本分支通常遵循包含“穩定”一詞的命名約定，並從應用程序版本中刪除補丁號：例如2-3-stable以使其目的和可靠性對最終用戶顯而易見。

Git 標籤可能會應用到應用程序的補丁版本號，但版本分支並不是那麼精細。 版本分支將始終指向受支持的次要版本的最穩定提交。

當出現安全補丁或需要向後移植功能時，將適用於您支持的舊應用程序版本所需的提交放在一起，並將它們分別推送到您的版本分支。

除非您支持多個版本的存儲庫，否則不要使用版本分支。

概括

當您的團隊規模發生變化，或者您的項目通過持續評估開發其流程時，不要忘記評估您的 Git 流程。 使用本教程中的模式作為起點，幫助您走上 Git 工作流程正義的道路。

本指南中的模式可以幫助您在調整分佈式版本控制系統以適應您的工作方面具有一定的遠見。 如果您想了解 Git 工作流程，請務必查看 Gitflow、Github Flow，以及最重要的是令人驚嘆的 git-scm 文檔！