解決不同分支之間的合並沖突

Question

我公司有這樣的規定：

1. 功能分支是從主分支創建的
2. 功能分支完成后，我們做一個 PR 來開發分支
3. PR批准后，合並開發
4. QA 測試后，功能分支將合並回 master

這個流程在嘗試進行 PR 時產生了許多不必要的合並沖突（雖然如果 PR 與 master 沒有問題），我們如何改善這種情況？

編輯：我的公司似乎很可能使用基於主干的開發，並使用開發分支僅用於新功能的測試場（有時功能是由不同的開發人員使用多個分支開發的）

Answer 1

我們在公司中遵循以下步驟。 這可能會有所幫助：

1. 從 master 創建一個功能分支
2. 完成功能分支中的工作
3. 將 master 分支合並到 feature 分支，解決所有沖突。 為了盡量減少沖突，您可以每天一次將 master 合並到您的分支。
4. 解決沖突后檢查是否一切正常。 然后將其推送到您分支機構的遙控器。
5. 然后結帳給大師。
6. 合並從功能分支到主分支的所有內容。 由於我們已經將所有功能從功能分支合並到主分支，因此將功能合並到主分支應該不會引起任何沖突。

這樣 master 分支將始終是干凈的。 沖突將在功能分支中解決。 另外，如果你想拉請求到 master，首先將 master 分支的最新內容合並到你的 feature 分支。

總之，為了盡量減少沖突，請盡可能頻繁地使您的功能分支與您的主分支保持同步。 並解決您在功能分支中的所有沖突以保持主干凈。

Answer 2

您可以通過以下方式改善這種情況：

• Feature 分支應該從 Develop 分支創建
• 在開發分支中合並任何 PR 后，每個人都應該在本地重新建立他們的開發分支和各自的功能分支。
• 通過以上兩個步驟，只有在 QA Testing 和 develop 合並到 master 分支后才更改 Master。

如果我需要進一步解釋，請告訴我。

.

Answer 3

git 代碼的最大部分是沖突解決。 你的提交和你同事的提交越小，git 自動解決沖突的機會就越大。 非常大的提交主要是沖突的原因。

工作流程對我來說看起來不錯，不應該成為您不斷沖突的根本原因。 即使我同意功能分支應該從開發分支。