在直接提交與短期分支中提過，主幹更新後，需要先取得更新，重新驗證準備合併的程式。

開發者提出 PR 前，需要先將準備合併的程式與當時的主幹放在一起驗證。測試通過，只能說明這個組合通過了測試。其他 PR 先合併後，主幹已經改變，原本的結果就不足以判斷接下來的合併是否能正常運作。

但多人同時準備合併時，重新驗證期間仍可能有其他提交進入主幹，因此還需要協調合併順序，讓驗證涵蓋實際要合併的組合。

兩個通過的 PR 合在一起

假設兩位開發者同時修改清單功能，分別提出 PR A 與 PR B。兩人都從主幹版本 T 開始，在各自的分支完成驗證。

PR A 新增一個清單頁面，使用共用格式化函式。原本函式在資料未填寫時回傳空字串，新頁面再把空字串顯示成「未填寫」。

PR B 則調整格式化函式，讓未填寫資料直接回傳破折號，並更新既有頁面的相關測試。

兩個 PR 分別和 T 放在一起時都通過，但 A 與 B 一起合併後，新頁面收到的是破折號，不再顯示約定的「未填寫」。

兩人修改不同檔案，版本控制可能不會回報文字衝突，但一起使用時仍有行為差異。如果 A 已合併到主幹，B 接下來要驗證的就是 T ＋ A ＋ B，不能沿用 T ＋ B 的通過結果。

取得主幹更新並重新驗證

兩位開發者可以先約定讓 A 合併。確認主幹已包含 A 後，負責 B 的開發者再取得更新，把 B 與新的主幹放在一起驗證。

這時，新頁面的測試會提醒兩人重新確認共用函式的約定。兩人決定如何保留新頁面的提示後，由負責 B 的開發者調整程式與測試。

驗證期間如果又有其他提交進入主幹，受測組合就再次改變。團隊可以透過合併權限與分支保護規則要求重新檢查，但仍需要有人安排順序，避免成員輪流更新分支、等待驗證，卻一直無法合併。

自動安排合併順序與驗證

當多人經常需要輪流更新分支、等待驗證時，可以把安排合併順序與建立受測版本的步驟交給工具。開發者將準備合併的 PR 加入合併佇列（Merge Queue），工具依順序把最新主幹、排在前面的 PR 與這次的 PR 組合起來，交給建置服務檢查，通過必要檢查後才合併到主幹。

以 A 排在 B 前面為例，工具可以先建立 T ＋ A 供測試，同時準備 T ＋ A ＋ B。這些暫時組合出的版本稱為候選合併結果，還沒有進入主幹。B 的候選版本已包含 A 新增的頁面與測試，因此能在 B 合併前發現提示文字不符預期的問題。

實際工具可能一次處理一筆，也可能預先建立多個候選組合並行驗證。

讓建置服務驗證正確版本

這類安排可以由程式碼協作平台或 CI 工具提供，例如 GitHub 的 Merge Queue、GitLab 的 Merge Trains，具體設定與處理方式依工具而異。

設定建置服務時，需要確認它取得的是佇列產生的候選版本。如果仍然只測 PR 原本的分支，就沒有驗證加入前方變更後的行為。測試結果也要回報給對應的候選版本，佇列才能判斷是否符合合併條件。

以 GitHub 的合併佇列為例，若必要檢查由 GitHub Actions 執行，工作流程還要接收 merge_group 事件；只設定 pull_request，不會自動完成這次候選組合的檢查。

設定佇列時，也要限制直接合併，讓提交依照佇列的順序進入主幹。否則，若有人在檢查期間直接合併其他 PR，原本準備的候選版本就不再是實際的合併組合。

處理失敗與等待

本例 A 的候選結果通過後可以合併，B 則因新頁面的測試失敗而被移出佇列。兩位開發者修正 B 後，再將它加入佇列。此時主幹與排序可能已經改變，因此佇列要重新建立候選版本。

若被移出的是 A，原本包含 A 的後續候選組合也要重建；T ＋ A ＋ B 的結果不能直接當成 T ＋ B 的結果。

佇列不會讓測試自動變快。建置資源不足時，候選版本仍要等待；頻繁改變順序或更新 PR，還可能讓原本的候選組合失效，需要重新建置。

如果只是偶爾有兩個 PR 同時準備合併，先協調順序可能已經足夠；當反覆更新與等待成為日常負擔，再考慮用佇列自動安排。

小結

主幹更新後，接下來要合併的程式組合也跟著改變。團隊需要讓受測版本跟上這些變化，才能依據驗證結果判斷是否適合合併。合併佇列可以自動安排順序與組合驗證，程式之間的行為差異仍需要開發者討論與修正。

佇列處理的是已經準備好合併的提交。如果依賴的介面還沒完成，就要先解決開發期間的等待。接著回到新客戶清單，說明如何在讀取介面完成前，先開發與測試清單。

參考資料

• GitHub Docs：Managing a merge queue
• GitLab Docs：Merge trains
• Trunk Based Development：Continuous Integration