當它們不同步時，如何合並 git 中的兩個受保護分支？

Question

我的應用程序有一個 GitLab 存儲庫。 遵循一些准則 ( https://nvie.com/posts/a-successful-git-branching-model/ ) 我創建了一個反映生產版本的“主”分支和一個反映當前接受版本的“開發”分支測試。 驗收完成后推出develop版本並合並到main中。

一切正常，直到最近我們不得不進行緊急更改。 為此，我在 main 之外創建了一個分支，提交了更改並將它們合並回 main。

現在我們已經准備好開發下一個計划發布，所以我創建了一個從開發到主的合並請求。 這個合並請求告訴我 develop 是 main 之后的 2 次提交（由於緊急分支，這是真的）。 所以我創建了一個從 main 到 develop 的合並請求。 現在這個也落后於開發（由於此版本中的定期功能更新，這是真的）。

在緊急更改中，我們更改了 developmen 分支中不應更改的文件（快速修復，我們在主版本中以其他方式解決）。

現在我不能將 develop 合並到 main 中，因為我必須將 develop 推進到 main head，但我不能這樣做，因為我必須將“main”更改（或它們的覆蓋）提交到受保護的 develop 中。

創建一個新分支以將主要更改合並到開發的合並請求中是行不通的。

將 develop 移至 main 頭部而不能直接提交 develop （或 main）的正確方法是什么？

Answer 1

聽起來你有一個設置強制傳入分支在合並到main之前與main完全同步。 這有助於防止您幾乎發現自己遇到的情況，即當您有一個hotfix時，您沒有將這些更改合並回develop中，然后下次您從develop部署到生產中時，您會吹走這些更改在hotfix中。

如果您正在使用該設置，則只需啟用它即可合並到main中。 您不需要為合並到develop啟用該設置，但如果您希望為develop也保留它，則有一個解決方法。

通常，在將hotfix合並到main之后，您應該立即將main合並到develop 。 ¹由於develop是 GitLab 中的一個受保護分支，這可能只是意味着創建一個從main到develop的合並請求。 在某些情況下，您不能直接從main創建 MR 到develop ，而是需要使用中間臨時分支，例如：

1. 將main合並到develop時會發生沖突。
2. 沒有沖突，但至少有一項您不希望應用到develop分支的更改。
3. 您已在develop上啟用標志，即所有傳入的合並必須與develop保持同步。

無論上述異常原因是什么，創建中間分支的解決方案都是相同的（這些命令假定您的遠程名稱是origin ）：

# get the latest code
git fetch

# create a new temporary branch starting from the latest develop
git switch -c merge-main-into-develop origin/develop --no-track

# Merge in main
git merge origin/main
# resolve conflicts if needed and continue to complete the merge

# push out your branch and set it to track the new branch
git push -u

現在您可以創建一個從merge-main-into-develop到develop的 PR。

如果您碰巧遇到上面的異常情況#2，您不希望實際將所有修補程序更改從main引入develop ，您有幾個選擇：

1. 如果你想要一些文件而不是全部，你可以將合並命令更改為git merge origin/main --no-commit 。 這將暫停與已保存文件的合並，並且您可以在提交之前根據需要修改索引。 如果您有一些在main上修改的版本文件，您不希望在develop上更新，則可以選擇此選項。 考慮更新合並提交消息以解釋您正在更改的內容和原因。
2. 如果您不想將修補程序中的任何更改引入develop ，也許是因為您已經在develop上以不同的首選方式修復了相同的東西，您可以使用“我們的”合並策略，通過修改 merge 命令是： git merge origin/main -s ours 。這將帶來提交但沒有任何更改。考慮更新合並提交消息以解釋您這樣做的原因。
3. 與第 2 種方法類似的方法是按原樣接受合並，然后使用解釋原因的提交消息恢復合並。 這與 #2 具有相同的效果，但會創建一個額外的提交。 這種方法的優點是只需看一眼提交消息標題就可以更容易地預測發生了什么。

最終，這里的關鍵思想是在將develop合並回main之前，您需要main上的所有提交 ID 都出現在develop上。

---

¹ Git Flow 文檔建議將hotfix合並到main中，然后將hotfix合並到develop中。 這將產生相同的state但不會包含在main上創建的新合並提交（推薦）。 相反，通過將main合並到develop中，您也可以帶來新的合並提交，因此將使develop與main保持同步。 請注意，這也意味着您需要在將develop合並到main之后立即將main合並到develop中，只是為了帶來合並提交！