將Git Feature分支合併到「Beta」分支（已合併到「Develop」分支後）問題

我們有一個標準Web項目併爲此項目維護3個核心分支：Master，Beta和Develop。以下是我們使用的流程/工作流程摘要：將Git Feature分支合併到「Beta」分支（已合併到「Develop」分支後）問題

（1）請求新功能/更新，以便我們創建新功能分支。

（2）爲新的Feature分支提交提交，並將Feature分支合併到'Develop'分支;然後將'Develop'分支發佈到測試環境進行測試。（3）一旦新功能被測試/批准，新的拉取請求將在同一個功能分支中進行;這個新的pull請求將被合併到'Beta'分支中。 'Beta'分支具有我們所有的「隨時可用」功能：事實上，我們直接將「Beta」分支發佈到生產環境，當準備就緒時，我們立即將「測試版」 '分支到'主'分支......通過這樣做，'主'分支始終是生產環境中代碼的副本。

問題：在上面的第3步中，當我們試圖將新的Feature分支合併到'Beta'分支時，該請求包含所有已經合併到'Develop'分支中的新提交。

示例：5個特徵分支單獨合併到'Develop'分支（分支標記爲1,2,3,4和5）。所有5個都經過了測試，但是前4個有bug。所以分支「5」被批准，我們試圖爲該Feature分支創建一個拉取請求，並將它合併到'Beta'....但是當我們這樣做時，該拉請求包括全部5個特徵分支....不僅僅是分支「5」的提交。

我們必須做錯了！我們可以做些什麼來解決我們的流程/工作流程？

來源

2016-11-14 Kris

的可能的複製[待辦事項Git的合併影響「合併」分支？]（http://stackoverflow.com/questions/40466290/do-git-merges-affect-the-merged-branch） –

哪個分支你測試了嗎？不同的功能彼此干擾的頻率如何？ – oyvind

我問的原因是因爲它看起來像只在一個分支上進行測試（開發），但是您仍然能夠獨立地測試/批准更改。所以我猜猜這些功能通常不會相交。 – oyvind

這就是git的工作方式。您需要爲每個功能創建單獨的分支。

來源

2016-11-14 17:38:19

來自OP公司的員工：我們確實爲每個功能創建了獨立的分支，因爲這是GitFlow的完整基礎。功能是從「開發」分支創建的，如果我們需要在測試版網站上進行這些更改，那麼它們將從其中合併回「開發」，並且還會轉換爲「測試版」。 –

傳統將決定合併功能分支以「開發」，然後在準備好時將「開發」合併爲「測試版」，但這對我們不起作用。客戶端有時需要選擇性地測試新功能，而不使用該站點的最前沿版本，這是現有測試版分支的要點。它基本上是一個較低版本的「開發」版本，但它是合併到官方版本的主版本。 –

我們的問題是，有時，試圖在已將特徵合併到「開發」之後嘗試將特徵合併到「測試版」中時，將包括不應包含在特徵分支中的幾個不相關的提交，因爲既不是開發版，測試版或主人應該被合併到一個功能。我們只需要弄清楚什麼地方出了問題，這樣我們就可以讓我們的團隊在將來不會犯同樣的錯誤。 –

一旦你合併與另一個分支，合併分支提交得到承諾在主分支。

你可能想要做的是不是即使在開發分支進行開發工作，而是另闢蹊徑的它然後將它們分別合併前檢查錯誤每個功能（序列化功能，當然）什麼許多功能包的分支進入開發分支。

爲了擺脫鑽進開發分支的bug反正你將需要得到工作的特性分支代碼，然後歸併或使用git revert恢復的特性分支，然後合併恢復更改（有效地還原僅提交給開發分支的提交

在開發分支（或層次結構中的任何更大的分支）上恢復通常在業界不受歡迎，除非您合併只是一個功能......因爲不同的提交可以建立依賴關係b他們自己和回覆會造成更多的傷害，而不是解決問題。

爲了獲得更好的回覆讀取this guide by atlassian或available documentation。

來源

2016-11-14 18:02:41

嗨，我和OP一樣在同一個團隊中 - 我們正在完成從「開發」分支創建的各個功能分支的所有工作，然後在完成時將其合併回「開發」。這些功能分支有時也會合併到「測試」分支，以定期部署到測試版服務器。最後，只要準備就緒，「測試版」就會定期合併到主分支。 –

這個工作流程應該可以正常工作，但由於某種原因，無論何時我們試圖將我們的功能分支合併到「測試版」（在他們已經被合併爲「開發」之後），一堆不需要/不相關的功能分支提交被合併到「測試版」以及。我們需要弄清楚發生了什麼問題，因此我們可以將功能分支完全獨立於「開發」和「測試」。 –

我不確定我是否理解......您正在將功能分支合併到測試版分支中？在開發分支設置好後，你應該： 'checkout beta'，'merge development'，並且分支被合併。如果你完全搞砸了開發分支，垃圾提交被埋在其他提交下面......你想做什麼，除非你準備['櫻桃']（https://git-scm.com/ docs/git-cherry-pick），將刪除開發分支，並從工作測試版再次分支出來。我認爲這是一個學校項目的種類？如果是這樣，請不要挑選 –

你是對的，我們的工作流程與傳統的GitFlow不同。特徵分支完全獨立地合併爲EITHER develop或beta。

一旦新功能進行測試/批准，新拉請求同一個要素分支

 f2--f2--f2 (f2) 
    /  \ 
d--d--d--D1-------D2 (develop) 
\  /
f1---f1

不需要的/不相關的特性分支提交的一堆合併爲「測試版」製作以及

奇怪：這就好像f2是在D2合併提交（其中有f2但也是f1）。

對於測試，你可以嘗試命令行到cherry-pick the exact commits you want，然後merge them with --squash。

git checkout -b tmp develop 
git cherry-pick $(git merge-base develop f2) f2 
git checkout beta 
git merge --squash tmp

這樣的話，你可以驗證你只會讓你處於測試階段所需的準確f2合併分支，不是所有的其他功能。
一旦通過驗證，我們可以從一個GUI（例如像SourceTree）做同樣的工作

來源

2017-02-26 21:53:43 VonC

（3）一旦新功能進行測試/批准，新拉請求在同一製造特色分支;這個新的pull請求將被合併到'Beta'分支中。 'Beta'分支具有我們所有的「隨時可用」功能：事實上，我們直接將「Beta」分支發佈到生產環境，當準備就緒時，我們立即將「測試版」 '分支到'主'分支......通過這樣做，'主'分支始終是生產環境中代碼的副本。

問題：在上面的第3步中，當我們試圖將新的Feature分支合併到'Beta'分支時，該請求包含所有已經合併到'Develop'分支中的新提交。

不，這沒有意義。如果發生這種情況，您省略了重要信息，例如：

每個新功能分支都從另一個分支分支出來。哪一個，發展？那麼很明顯，無論開發提交是在新創建的特性的歷史中，還將被合併到測試版分支中。 Git歷史是一個有向非循環圖，每個提交指向一個（正常提交）或多個（合併提交）父提交。
爲了使特性融合得到乾淨的發展，也許特性分支定期重新開發，或者通過合併最新開發來更新特性分支，這兩者都很有意義，我提倡它。但在這種情況下，他們的歷史也包含了合併/重組時的所有發展歷史。

在每種情況下您的工作流程是從根本上打破，不能關於你的一個beta分支的思想工作。所以如果你想避免櫻桃採摘（壞的！壞的！壞的！）你怎麼能達到你想要的？有一些基本的選項：

功能切換：醜陋。只要有可能，我會遠離它。在任何分支中取消激活功能的最佳方法是首先不在該分支上進行相應的提交。
工作乾淨：很好。避免合併未經測試/未接受的功能進行開發。只有當它們是完成（如在「完成的定義」中）並且被客戶接受時才合併它們。確保你設置了一個環境，使你的客戶可以直接測試功能分支，而不是將它們全部混合到測試版分支上。通過這種方式，無論發展如何，本質上都是爲生產做好準備，而且您不再需要beta分支。未完成的工作永遠不會被合併到更高層次的分支中。這就是GitFlow的全部內容，它的工作原理。即使你沒有充分利用GitFlow，但只是掌握，開發和設計分支，我的陳述的有效性就成立了。我在許多項目中都是這樣工作的，而且工作起來非常漂亮。此外，如果您認爲您需要另一個分支來將功能集成到未來版本中，請爲他們創建一個新的「next_release」或「future」分支，並將它們合併到該分支，而不是開發。然後定期從開發中刷新未來，因爲您還希望在未來版本中使用當前版本的功能，但反之亦然。我幾乎不相信這個額外的步驟將是必要的。

來源

2017-02-26 23:10:32 kriegaex

Keith Pickering對另一個答案的評論表明，功能分支是從'develop'分支創建的。我認爲你的第一個要點是發現。 – mkasberg

對不起，我還沒有徹底閱讀其他答案。 – kriegaex

您說，將功能5合併到測試版中會將功能1-4帶入測試版。如果是這樣，特徵1-4的提交肯定在特徵5分支中。有3種方式可能發生：

特徵5從特徵1-4被合併爲展開後從展開分支出來。
在特徵1-4合併爲開發後，開發被合併到特徵5（上行）中。
特點1-4直接併入功能5.

謹防分支不僅包含直接向分公司提交，而且全部來自回購之初到提交分支點和分支中的任何提交合併到分支中。

順便說一下，即使您將「合併」更改爲「rebase」或「develop」到任何其他分支，以上3點仍然成立。

來源

2017-03-03 00:27:18 oyvind

我會做下面的步驟。

從開發創建的功能分支。
一旦功能完成合並它們開發分支。
當測試的時間到了，我會創建一個測試分支並在那裏做測試。我會修復那些在測試中出現的錯誤。
一旦我的測試都取得成功，我將分支合併到master和develop中。
然後，我會將我的代碼從主環境釋放到Beta環境。

我會記住下列事情。

如果特定發佈不需要某個功能，我不會將該功能合併到develop分支。
如果我在測試時無法解決任何錯誤，我不會釋放該代碼，因此在問題中，我將解決所有錯誤並將釋放整個代碼。

來源

2017-03-05 10:55:00

將Git Feature分支合併到「Beta」分支（已合併到「Develop」分支後）問題

回答

相關問題