為什么先“merge main”來解決Pull Request沖突

Question

我發現解決 Pull Request 沖突的方法不是很直觀。 有人可以給出進一步的解釋或推理嗎？

設想：

兩個開發者同時開了兩個 PR。 一個是來自分支feature-1的 PR1，另一個是來自分支feature-2的 PR2，他們都編輯了同一個文件，這將導致沖突。

PR1 首先合並成功。 但是 PR2 現在有沖突需要解決。 解決這個問題的“官方”方法是：

1. 在本地，將最新的main和 merege main拉到分支feature-2 （並解決這里的沖突）；
2. 將分支feature-2推送到遠程。 現在可以進行PR2了。

而 the.network 看起來如下所示

我的問題是為什么我們不能通過將feature-2合並到main中來解決沖突（即，直接在這一步中解決沖突）？

相反，在“官方”方式中，我們必須將main合並到feature-2 ，然后再合並回main 。 它不直觀，而且往往會產生令人困惑的提交歷史記錄。 我能想到的唯一原因是 PR 工作流的設計者認為解決沖突是功能開發人員的責任而不是主要分支所有者。

我檢查過的所有教程都顯示了“官方”工作流程，我相信這是常見的做法。 但是我發現它不是很直觀。 我期待着更多的推理和有見地的評論。

Answer 1

當您與許多其他用戶一起工作時，例如您在公司的同事，通常有一個存儲庫的主副本，位於像 gitlab 這樣的服務器上。那里通常不允許您直接將某些內容推送到主分支。 您只能要求服務器將一個分支合並到主分支，但這只有在沒有合並沖突的情況下才有效。 所以你必須解決你分支上的合並沖突，這樣這個分支才能在沒有沖突的情況下被合並。

有時也可能對服務器有限制，只允許快進合並。 這意味着，只有在合並后您的分支與主分支的預期 state 沒有區別時，您才能合並。

如果您單獨在 git 存儲庫上工作並且可以完全訪問所有內容，那么完全可以合並到 main 並在合並時解決沖突。

Answer 2

持續部署工作流通常會在啟用綠色大“合並拉取請求”按鈕之前對 PR 分支的代碼運行單元或功能測試進行檢查，因此它們禁止推送main分支以防止未測試的代碼被提交或合並。

Answer 3

實際上，有時您可以在目標分支上執行此操作。 Pull Request 功能本身並不是 Git 的一部分，因此依賴於工具，但一些工具直接在 UI 中提供有限的合並沖突解決方案，例如：

1. GitHub
2. Azure 開發運營
3. GitLab

旁注：要在本地解決，您不必將目標合並到功能分支中。 在大多數工作流程中，您可以先將功能分支重新定位到目標上，以避免在功能分支上進行新的合並提交。 （顯然你不能在共享分支上這樣做，但通常對“功能”分支沒問題。）