問題將Git Feature分支合並到“Beta”分支（在它已經合並到“Develop”分支之后）

Question

我們有一個標准的Web項目，並為該項目維護3個核心分支：Master，Beta和Develop。 以下是我們使用的流程/工作流程的摘要：

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

（2）為新功能分支進行提交，並將功能分支合並到“開發”分支中; 然后將“開發”分支發布到要測試的測試環境。

（3）測試/批准新功能后，在同一功能分支中進行新的拉取請求; 這個新的pull請求被合並到'Beta'分支中。

'Beta'分支具有我們所有的“准備就緒”功能：事實上，我們將'Beta'分支直接發布到生產環境，當它准備就緒時，我們立即將'Beta'分支合並到'Master'分支......通過這樣做，'Master'分支始終是生產環境中代碼的副本。

問題：在上面的步驟3中，當我們嘗試將新的Feature分支合並到'Beta'分支時，pull請求包括已合並到'Develop'分支中的所有新提交。

示例：5個要素分支分別合並到“Develop”分支（分支標記為1,2,3,4和5）。 所有5個都經過了測試，但是前面有4個錯誤。所以分支“5”被批准，我們嘗試為該功能分支創建拉取請求並將其合並為“Beta”....但是當我們這樣做時， pull請求包括所有5個功能分支....而不僅僅是分支“5”的提交。

我們必須做錯事！ 我們可以做些什么來修復我們的流程/工作流程？

Answer 1

（3）測試/批准新功能后，在同一功能分支中進行新的拉取請求; 這個新的pull請求被合並到'Beta'分支中。

'Beta'分支具有我們所有的“准備就緒”功能：事實上，我們將'Beta'分支直接發布到生產環境，當它准備就緒時，我們立即將'Beta'分支合並到'Master'分支......通過這樣做，'Master'分支始終是生產環境中代碼的副本。

問題：在上面的步驟3中，當我們嘗試將新的Feature分支合並到'Beta'分支時，pull請求包括已合並到'Develop'分支中的所有新提交。

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

• 每個新功能分支都從另一個分支分支出來。 哪一個，發展？ 然后很明顯，無論開發提交是否在新創建的功能的歷史中，也將合並到beta分支中。 Git歷史是一個有向無環圖，每個提交指向一個（正常提交）或多個（合並提交）父提交。
• 為了使功能完全合並到開發中，可能會將功能分支定期重新定位到開發中，或者可能通過合並最新的開發來更新功能分支，這兩者都很有意義，我提倡它。 但在這種情況下，他們的歷史也包含了合並/變基時的所有發展歷史。

在每種情況下，您的工作流程都會從根本上被打破， 並且無法滿足您對beta分支的看法。 因此，如果你想避免挑選（糟糕！糟糕！糟糕！）你怎么能實現你想做的事情？ 有一些基本選擇：

1. 功能切換：丑陋。 我會盡可能遠離它。 在任何分支中停用功能的最佳方法是首先在該分支上沒有相應的提交。
2. 干凈利落地工作：好。 避免合並未經測試/未接受的功能以進行開發。 只有在完成后才會合並（如“完成定義”）並由客戶接受。 確保您設置了一個環境，使您的客戶可以直接在功能分支上進行測試，而不是將其全部壓縮到測試版分支上。 這樣開發的任何內容都固有地為生產做好准備，您不再需要beta分支。 未完成的工作永遠不會被合並到更高級別的分支。 這就是GitFlow的全部內容，它的工作原理。 即使你沒有完全使用GitFlow，但只是掌握，開發和功能分支，我的陳述的有效性仍然存在。 我在很多項目中都是這樣工作的，而且效果很好。 此外，如果您認為需要另一個分支來集成功能以用於將來的版本，請為它們創建一個新的“next_release”或“future”分支，並將它們合並到該分支，而不是開發。 然后定期從開發中刷新未來，因為您還希望在將來的版本中使用當前版本中的功能，但反之亦然。 我不相信這個額外的步驟是必要的。

Answer 2

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

Answer 3

將分支與另一個分支合並后 ，合並分支提交將在主分支上進行提交。

您可能想要做的甚至不是在開發分支上進行開發，而是為每個功能分支（當然是序列化功能），然后在將許多功能分支的包合並到​​之前單獨檢查錯誤。開發部門。

要擺脫進入開發分支的錯誤，你需要讓代碼在特征分支上工作然后合並，或者通過使用git revert 特征分支然后再次合並分支來git revert更改（僅有效地恢復分支）它引入開發分支的提交。

恢復開發分支（或層次結構中的任何更大的分支）在業界通常是不明智的，除非您只合並一個功能...因為不同的提交可以在它們之間建立依賴關系並且恢復可能會造成比它解決了。

為了更好地堅持恢復，請閱讀atlassian或可用文檔閱讀本指南 。

Answer 4

你是對的，我們的工作流程與傳統的GitFlow不同。 功能分支完全獨立地合並到EITHER develop或beta 。

測試/批准新功能后，將在同一功能分支中生成新的拉取請求

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

一堆不需要/不相關的功能分支提交也被合並到“beta”中

奇怪的是：這就好像f2在D2合並提交（它有f2但也是f1）上。

為了測試，你可以嘗試在命令行中挑選你想要的確切提交 ，然后將它們與--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）做同樣的事情。

Answer 5

你說將功能5合並到測試版中也會將功能1-4帶入測試階段。 如果是這樣，功能1-4的提交肯定在功能5分支中。 有三種方法可能發生：

1. 特征5在特征1-4合並到開發之后從開發中分支出來。

2. 在將特征1-4合並到開發之后，開發被合並到特征5（upmerge）中。

3. 功能1-4直接合並到功能5中。

請注意，分支不僅包含直接提交給分支的提交，還包括從repo開始到分支點的所有提交，以及分支中的任何提交都合並到分支中。

順便說一下，即使你將'merge'改為'rebase'，或者'發展'到任何其他分支，上述3分仍然保持不變。

Answer 6

我會按照以下步驟進行。

• 從開發創建的功能分支。
• 完成功能后，將它們合並為開發分支。
• 當測試時間到來時，我將創建一個測試分支並在那里進行測試。我將修復測試中出現的任何錯誤。
• 一旦我的測試全部成功，我將分支合並到master和develop。
• 然后我會將我的代碼從master環境發布到Beta環境。

我會記住以下事項。

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