git工作流程：如何在沒有持續交付的情況下集成和測試功能分支？

Question

我喜歡斯科特·查孔非常多所描述的「GitHub的流動」的工作流程：http://scottchacon.com/2011/08/31/github-flow.html

他介紹爲什麼github上不使用由文森特了Driessen（http://nvie.com/posts/a-successful-git-branching-model/）中描述的混帳流工作流程，我們不使用它的同樣的原因，其中最重要的原因是，它不適合拉取請求，它不適合網站開發，你沒有「正式發佈的軟件產品版本」，但不斷改進網站。

我們正在一個小團隊中開發一個大型在線社區，其中有很多舊的遺留代碼（有些代碼已超過10年），測試覆蓋率較差。我們正在使用與github相似的工作流，目前我們使用功能分支進行開發，並使用pull請求將它們集成到master分支中，進行同行評審，徵求反饋等。當功能完成並獲得其他人的批准後，合併成主人。每週我們都會把主人推到一個由我們的測試人員和測試用戶使用的臨時環境。我們試圖每兩週向公衆發佈一次主分支，因此合併後的每個功能分支都必須進行足夠的測試，並且在最後幾天內不會合並「更具風險的功能分支」，直到完成公開發布爲止。

這不是一個完美的工作流程，因爲當再次合併「風險功能」給主控人員時，我們無法使用主控人員將修補程序部署到公共場所。 Github使用持續交付進行部署，這不是我們的選擇，我們確實需要人們在功能發佈之前對其進行測試，然後才能將其發佈給公衆。

拉取請求只能合併到一個分支中。所以這是一個簡單的github工作流程，只有一個長期運行的分支是主分支。也許我們不應該每隔兩週發佈一次，但是當它們合併爲主時發佈拉取請求？但這樣很難測試，我們可以在合併之前運行我們在特性分支上的單元測試，並且我們可以將分支部署到beta測試者的階段，但這並不總是那麼容易，有時您必須做數據庫手動更改（我們無法自動執行，因爲我們的beta測試人員的臨時服務器使用生產數據庫，所以風險太大），因此您必須等待管理員完成此操作。而更大的問題是，如果您只向Beta版用戶發佈功能分支，則它們不會集成，它們會看到新功能，並且可能每天都會多次刪除功能。另一方面，如果我們使用2個長時間運行的分支，比如說，如果我們使用2個長時間運行的分支開發和掌握git-flow中描述的，我們可以解決修補程序問題，我們可以使用pull-requests合併要開發的功能分支，我們可以使用pull請求來發布分支，以便將最近的更改合併到master中，但是我們可以將合併的更改合併回來以使用拉取請求工作流進行開發。如您在github流文章（＃6 - 在審查後立即部署）中看到的，github工程師不僅可以部署到生產環境，還可以部署到臨時環境。不僅工程師可以做到這一點，還有支持和設計師。但是，它只與一個整合分支有什麼關係？如果最後的拉取請求在幾小時或幾分鐘內即將投入生產，則不需要臨時環境。有時他們似乎將功能分支部署到分段中，這是有道理的，但它們並未集成，因此我將在上面介紹的內容中看到，即使在部署功能部件之前它們合併了來自主部件的更改 - 分段分段（你認爲這將是一個好主意？）。或者是否有多個臨時環境，每個功能分支一個？但這種方式再一次讓你失去了持續集成的優勢。正如所說的，我認爲你不能在beta測試環境中做到這一點。

我發現在這兩種工作流程，git流程和github流程中都存在問題，我更喜歡github流程，但如果您沒有良好的測試覆蓋率並需要人員進行更多測試，似乎很難。

那麼，當人們需要更多測試（qa和beta測試人員）時，如何集成和測試功能分支？

Answer 1

你可以沿着一個共同的集成分支跑幾支頭：

----A---B---C---D---E---F---G---H---I 
       \   \   \ 
       goodToGo testing  toBeTested