基於主幹的開發與 Git 流程

為了開發高質量的軟件，我們需要能夠跟踪所有更改並在必要時將其撤消。 版本控制系統通過跟踪項目歷史並幫助合併多人所做的更改來填補這一角色。 它們極大地加快了工作速度，使我們能夠更輕鬆地發現錯誤。

此外，主要得益於這些工具，可以在分佈式團隊中工作。 它們使幾個人能夠同時處理項目的不同部分，然後將他們的結果合併到一個產品中。 讓我們仔細看看版本控制系統，並解釋基於主幹的開發和 Git 流是如何形成的。

版本控制系統如何改變世界

在創建版本控制系統之前，人們依靠手動備份項目的早期版本。 他們手動複製修改後的文件，以便將多個開發人員的工作整合到同一個項目中。

它花費了大量的時間、硬盤空間和金錢。

當我們回顧歷史時，我們可以大致區分三代版本控制軟件。

讓我們來看看它們：

我們注意到隨著版本控制系統的成熟，有一種趨勢是增加並行處理項目的能力。

最具突破性的變化之一是從鎖定文件轉變為合併更改。 它使程序員能夠更有效地工作。

另一個相當大的改進是引入了分佈式系統。 Git 是最早融入這一理念的工具之一。 它確實使開源世界蓬勃發展。 Git 允許開發人員在稱為分叉的操作中復制整個存儲庫，並引入所需的更改，而無需擔心合併衝突。

稍後，他們可以啟動拉取請求，以便將他們的更改合併到原始項目中。 如果最初的開發人員對合併來自其他存儲庫的這些更改不感興趣，那麼他們可以自己將它們變成單獨的項目。 由於沒有中央存儲的概念，這一切皆有可能。

發展方式

如今，最流行的版本控制系統當屬 Git，2016 年市場份額約為 70%。

Git 隨著 Linux 的興起和一般的開源場景而普及。 GitHub 是目前最流行的公共項目在線存儲，也是其流行的重要因素。 我們將易於管理的拉取請求的引入歸功於 Git。

簡而言之，拉取請求是軟件開發人員創建的將他們創建的更改與主項目相結合的請求。 它包括審查這些更改的過程。 審閱者可以在他們認為可以改進或認為不必要的每一個地方插入評論。

收到反饋後，創建者可以對其做出回應、創建討論，或者只是跟隨它並相應地更改他們的代碼。

Git 只是一個工具。 您可以通過許多不同的方式使用它。 目前，您可以遇到的兩種最流行的開發風格是 Git 流和基於主幹的開發。 很多時候，人們熟悉其中一種風格，而他們可能會忽略另一種風格。

讓我們仔細看看它們，並了解我們應該如何以及何時使用它們。

Git 流程

在 Git 流開發模型中，您有一個可以嚴格訪問它的主要開發分支。 它通常被稱為develop分支。

開發人員從這個主分支創建功能分支並對其進行處理。 完成後，他們會創建拉取請求。 在拉取請求中，其他開發人員對更改發表評論並可能進行討論，通常是很長的討論。

就變更的最終版本達成一致需要一些時間。 一旦達成一致，拉取請求就會被接受並合併到主分支。 一旦確定主分支已經達到足夠成熟可以發布，就會創建一個單獨的分支來準備最終版本。 來自該分支的應用程序經過測試，並在準備發布給最終用戶之前應用錯誤修復。 完成後，我們將最終產品合併到master分支並使用發布版本對其進行標記。 同時，可以在develop分支上開發新功能。

下面，你可以看到 Git 流程圖，描繪了一個一般的工作流程：

Git 流的優點之一是嚴格控制。 只有經過授權的開發人員才能在仔細查看更改後批准更改。 它確保了代碼質量並有助於及早消除錯誤。

但是，您需要記住，這也可能是一個巨大的劣勢。 它創建了一個減緩軟件開發的漏斗。 如果速度是您最關心的問題，那麼它可能是一個嚴重的問題。 單獨開發的功能可以創建可能難以與主項目結合的長期分支。

更重要的是，拉取請求僅將代碼審查重點放在新代碼上。 他們沒有將代碼視為一個整體並努力改進它，而是只檢查新引入的更改。 在某些情況下，它們可能會導致過早的優化，因為總是可以實現一些更快的執行。

此外，拉取請求可能會導致廣泛的微觀管理，其中首席開發人員實際上管理每一行代碼。 如果您有經驗豐富的開發人員您可以信任，他們可以處理它，但您可能會浪費他們的時間和技能。 它還可能嚴重削弱開發人員的積極性。

在大型組織中，拉取請求期間的辦公室政治是另一個問題。 可以想像，批准拉取請求的人可能會利用他們的職位故意阻止某些開發人員對代碼庫進行任何更改。 由於缺乏信心，他們可以這樣做，而有些人可能會濫用職權來解決個人問題。

Git Flow 的優缺點

如您所見，執行拉取請求可能並不總是最佳選擇。 它們應僅在適當的情況下使用。

Git Flow 什麼時候工作得最好？

• 當你運行一個開源項目時。
  這種風格來自開源世界，在那裡效果最好。 由於每個人都可以做出貢獻，因此您希望非常嚴格地訪問所有更改。 您希望能夠檢查每一行代碼，因為坦率地說，您不能相信做出貢獻的人。 通常，這些不是商業項目，因此開發速度不是問題。

• 當你有很多初級開發人員時。
  如果您主要與初級開發人員一起工作，那麼您希望有一種方法可以密切檢查他們的工作。 您可以向他們提供有關如何更有效地做事的多種提示，並幫助他們更快地提高技能。 接受拉取請求的人可以嚴格控制重複性更改，以防止代碼質量下降。

  

• 當您擁有成熟的產品時。
  當你已經有一個成功的產品時，這種風格似乎也能很好地發揮作用。 在這種情況下，重點通常是應用程序性能和負載能力。 這種優化需要非常精確的更改。 通常，時間不是約束，所以這種風格在這裡很有效。 更何況大型企業非常適合這種風格。 他們需要密切控制每一個變化，因為他們不想破壞他們數百萬美元的投資。

Git Flow 何時會導致問題？

• 當你剛剛開始。
  如果您剛剛開始，那麼 Git 流程不適合您。 您可能想快速創建一個最小的可行產品。 執行拉取請求會造成巨大的瓶頸，從而大大減慢整個團隊的速度。 你根本買不起。 Git 流程的問題在於拉取請求可能需要大量時間。 以這種方式提供快速開發是不可能的。

• 當您需要快速迭代時。
  達到產品的第一個版本後，您很可能需要對其進行幾次調整以滿足客戶的需求。 同樣，多個分支和拉取請求會顯著降低開發速度，在這種情況下不建議這樣做。

• 當您主要與高級開發人員一起工作時。
  如果你的團隊主要由長期合作的高級開發人員組成，那麼你真的不需要前面提到的 pull request 微管理。 您信任您的開發人員並且知道他們是專業人士。 讓他們做他們的工作，不要因為所有的 Git 流程官僚主義而拖慢他們的速度。

基於主幹的開發工作流程

在基於主幹的開發模型中，所有開發人員都在一個可以開放訪問的分支上工作。 通常它只是master分支。 他們向它提交代碼並運行它。 超級簡單。

在某些情況下，它們會創建短暫的功能分支。 一旦他們分支上的代碼編譯並通​​過了所有測試，他們就會直接將其合併到master 。 它確保開發是真正連續的，並防止開發人員創建難以解決的合併衝突。

讓我們看一下基於主幹的開發工作流程。

以這種方式審查代碼的唯一方法是進行完整的源代碼審查。 通常，冗長的討論是有限的。 沒有人可以嚴格控制源代碼庫中的修改內容——這就是為什麼擁有可執行的代碼風格很重要的原因。 以這種風格工作的開發人員應該有經驗，這樣您就知道他們不會降低源代碼質量。

當您與經驗豐富的軟件開發人員團隊合作時，這種工作方式會非常棒。 它使他們能夠快速引入新的改進，而沒有不必要的官僚作風。 它還向他們表明您信任他們，因為他們可以將代碼直接引入master分支。 此工作流程中的開發人員非常自主——他們直接交付並檢查工作產品中的最終結果。 在這種方法中，辦公室政治的微觀管理和可能性肯定要小得多。

另一方面，如果您沒有經驗豐富的團隊，或者由於某種原因您不信任他們，那麼您不應該使用這種方法——您應該選擇 Git 流。 它將為您省去不必要的後顧之憂。

基於主幹的開發的優缺點

讓我們仔細看看成本的兩個方面——最好的和最壞的情況。

基於主幹的開發什麼時候效果最好？

• 當你剛剛開始。
  如果您正在開發最小可行產品，那麼這種風格非常適合您。 它以最少的形式提供最大的開發速度。 由於沒有拉取請求，開發人員可以以光速交付新功能。 一定要聘請有經驗的程序員。

• 當您需要快速迭代時。
  一旦你到達你的產品的第一個版本並且你注意到你的客戶想要一些不同的東西，那麼不要三思而後行，並使用這種風格轉向一個新的方向。 您仍處於探索階段，您需要能夠盡快更改您的產品。

• 當您主要與高級開發人員一起工作時。
  如果您的團隊主要由高級開發人員組成，那麼您應該信任他們並讓他們完成他們的工作。 此工作流程為他們提供了所需的自主權，並使他們能夠掌握自己的專業知識。 只需給他們目標（要完成的任務）並觀察您的產品如何發展。

基於主幹的開發何時會導致問題？

• 當你運行一個開源項目時。
  如果您正在運行一個開源項目，那麼 Git 流是更好的選擇。 您需要對更改進行非常嚴格的控制，並且您不能信任貢獻者。 畢竟，任何人都可以做出貢獻。 包括在線巨魔。

• 當你有很多初級開發人員時。
  如果您主要雇用初級開發人員，那麼最好嚴格控制他們的工作。 嚴格的拉取請求將幫助他們提高技能，並更快地發現潛在的錯誤。

• 當您建立產品或管理大型團隊時。
  如果您已經擁有一個繁榮的產品或在大型企業管理大型團隊，那麼 Git 流可能是一個更好的主意。 您希望對價值數百萬美元的成熟產品進行嚴格控制。 可能，應用程序性能和負載能力是最重要的事情。 這種優化需要非常精確的更改。

為正確的工作使用正確的工具

正如我之前所說，Git 只是一個工具。 像所有其他工具一樣，它需要適當地使用。

Git 流程通過拉取請求管理所有更改。 它為所有更改提供嚴格的訪問控制。 它非常適合開源項目、大型企業、擁有成熟產品的公司或缺乏經驗的初級開發人員團隊。 您可以安全地檢查源代碼中引入的內容。 另一方面，它可能導致廣泛的微觀管理，涉及辦公室政治的糾紛，以及發展顯著放緩。

基於主幹的開發給予程序員充分的自主權，並對他們和他們的判斷表達出更多的信心。 訪問源代碼是免費的，因此您確實需要能夠信任您的團隊。 它提供了出色的軟件開發速度並減少了流程。 這些因素使其在創建新產品或將現有應用程序轉向全新方向時變得完美。 如果您主要與經驗豐富的開發人員一起工作，它會產生奇蹟。

儘管如此，如果您與初級程序員或您不完全信任的人一起工作，Git flow 是一個更好的選擇。

有了這些知識，我希望您能夠選擇與您的項目完美匹配的工作流程。