Git分支策略

時間 2021-08-15 標籤 python java 數據庫大數據人工智能

在此博客文章中，我們將討論在SDLC期間可以採用的各種分支策略。您的組織針對不同的情況存在不同的策略，應該根據可用的信息和團隊中的情況來做出有啓發性的決定。

主線分支策略

對於中小型團隊而言，幹線分支策略是最簡單但最有效的策略。團隊中的開發人員將他們的工作不斷提交到一箇中央分支中，該分支始終處於可部署狀態。換句話說，項目的主要分支應該只包含經過測試和質量的工作，並且絕不應該被破壞。

每個工作單元（或sprint ）都可能對分支機構的數量產生影響。最初，開發人員都在自己工作，分支的數量也在增加。然後，當每個開發人員完成他或她的工作並將其與其他開發人員集成在一起時，手風琴會再次向下壓縮。此策略有多種變體，可以用來滿足特定團隊的願望。

用Git來講，團隊中的每個開發人員都會有自己的本地分支。例如，如果團隊正在研究一項功能：實施環境服務，而任務之一是實施環境Serv API，則開發人員可以從主服務器創建本地分支（例如env-serv-api）。請記住，在Sprint /發佈計劃期間，將任務分解成一個工作單元變得很重要，因爲Scrum主/產品負責人要確保每個工作單元都是獨立的代碼。

因此，在下圖中，分支A，分支B和分支C對應於開發人員工作站上的Git本地分支。

保持簡單的分支策略可確保您不會花費不必要的時間進行手動合併。

大規模地，具有單個工作分支的這種方法被從事自動構建過程的團隊所採用。

優點

項目中沒有很多分支機構，這可以簡化團隊的工作流程，並減少對變更可能消失的地方的混淆。
提交到代碼庫中的提交相對較小且快速。如果有問題，應該儘快消除錯誤。
緊急修復程序較少，因爲任何保存到主分支中的代碼都可以部署。部署通常會對開發人員造成壓力，因爲開發人員在代碼投入生產時會屏住呼吸，並等待代碼用戶的迴音。只需進行很少的頻繁更新，就可以實踐此過程，並最終自動化到最終用戶幾乎看不見的程度。

缺點

假定main分支包含可部署的代碼。如果團隊沒有測試基礎架構，則冒着冒風險的風險，即假設新代碼不會破壞任何內容，尤其是隨着時間的推移，項目變得越來越複雜。
部署的概念更適合自動加載到用戶設備（例如網站）上的代碼。它不適用於必須下載和安裝的軟件。儘管可以解決問題的更新受到歡迎，但是頻繁進行更新會使所有希望與該應用程序一起使用的人感到煩惱。
開發人員可以在生產中驗證代碼的一種方法是將功能隱藏在標誌或腳蹼後面。有傳言稱Facebook，Flickr和Etsy都在使用這種技術。這裏的潛在風險是，代碼可能會被拋棄，從而導致代碼被隱藏的巨大技術負擔。

每個功能部署分支策略

在此策略中，每個功能都維護一個分支。一旦團隊/開發人員確信功能可以正常工作並經過測試，功能分支將合併到集成分支，這也是主分支的分支，其主要目的是不讓損壞的提交傳播到主部署。科。理想情況下，master分支中的任何內容都應處於可部署狀態。有了這種方法，可以靈活地選擇在主部署中應使用哪些功能。通常，這是一個手動步驟，因此會阻礙自動部署的總體目標。

使用此策略，在實際部署之前需要暫停一下。 Github Flow使用此策略。它依賴於請求請求的概念。一旦功能的團隊/開發人員認爲該功能已完成，便將拉取請求發送到Integration Branch。然後，此「拉取請求」將以手動方式進行調解，檢查並清除（如果已清除）則合併到主數據庫中。在此，主服務器始終處於可部署狀態。因此，一旦合併發生，就可以部署主服務器。

最初，GitHub Flow首先將Feature分支與母版合併，然後部署母版。現在，它首先部署功能分支，如果功能正常，則將其與母版合併。這意味着，如果功能分支存在問題，則可以立即重新部署母版，因爲事實證明它處於工作狀態。

優點

就像主線開發一樣，重點是代碼的快速部署。
與主線開發不同，有一個可選的構建步驟。使用構建步驟時，可以選擇將哪些功能合併到master分支中進行部署。

缺點

如果代碼保留在功能分支上，但沒有立即發佈到master上 ，則開發人員需要額外的維護要求，這些開發人員需要在等待將其功能發佈到部署的分支時保持其功能最新。
分支的語義命名可幫助熟悉系統的人員，但它也代表一種內部語言，如果有很多開放功能，則內部語言會使入職更加困難。
現在，對於開發人員，在將舊的分支滾動到主分支中時，它們有一個內部管理要求。這不是一個很大的負擔，但是它超出了從單個master分支中解決所需的負擔。

基於環境的分支策略

假設您有一個暫存環境，一個預生產環境和一個生產環境。在這種情況下，將在分支上部署master分支。當某人想要部署到預生產時，他們會創建一個從master分支到預生產分支的合併請求。通過將預生產分支合併到生產分支中，可以使代碼生效。此工作流僅在一個方向上進行提交，以確保在所有環境中都對所有內容進行了測試。

通過分支命名約定，以上策略可以清楚地說明在什麼環境中要使用什麼代碼，因此在合併提交之前可能需要滿足什麼條件。例如，您顯然不會將未經測試的代碼合併到名爲production的分支中。

Git使用的上述分支策略的變體

Git使用4個不同的分支機構，併爲它們的團隊適當命名，以瞭解每個分支機構的用途。另外，遵循約定，提交只能傳播到堆棧中的下一個分支。因此，T他分行的工作就像一個金字塔堆疊。每個「較低」分支都包含在「較高」分支中不存在的提交。如下圖所示，維護的提交次數最少， 建議的更新提交的次數最多。一旦代碼通過了審覈過程，它將被合併到下一個集成分支中，越來越接近被合併到正式版本中。

維護：此分支包含來自最新的Git穩定發行版的代碼，以及針對點發行版的其他提交（維護）。
master：此分支包含應提交到下一發行版的提交。
next：該分支旨在測試主分支中出於穩定性考慮的主題。
建議的更新： 建議的更新分支包含尚未準備好包含的提交。

發佈分支策略

僅在需要將軟件發佈到外界的情況下，才需要使用發佈分支。在這種情況下，每個分支都包含次要版本。穩定分支以master爲起點，並儘可能晚地創建。通過儘可能晚的分支，可以最大程度地減少將錯誤修復應用於多個分支的時間。宣佈發佈分支後，發佈分支僅包含嚴重的錯誤修復。如果可能，這些錯誤修復程序將首先合併到master中，然後精選到release分支中。這樣，您就不會忘記將它們精挑細選並在後續發行版中遇到相同的錯誤。這就是所謂的「上游優先」政策， Google和Red Hat也採用這種政策。每當發行分支中包含錯誤修復程序時，都會通過設置新標籤來提高補丁版本（以符合語義版本控制）。一些項目還具有一個穩定的分支，該分支指向與最新發布的分支相同的提交。在此流程中，通常不具有生產分支（或git flow master分支）。

資源資源

翻譯自: https://www.javacodegeeks.com/2015/11/git-branching-strategies.html