將dev合并到主分支的正確方法

我在一家公司作業，我們決定要更正確地使用 git。我負責將 dev 分支集成到主分支中，我對如何在不同場景中正確合并感到困惑。

我們現在的作業方式：開發人員只需將他們的功能分支重新建立在dev分支上。完成后，他們將向dev分支提交合并請求。然后，我會檢查代碼（我們是一個小團隊），并接受合并請求。之后，他們只需洗掉功能分支。正確dev測驗分支后，我會在 GitLab 中創建一個到主分支的合并請求，將其分配給我自己并批準它。main這會在分支上創建一個提交：

將分支“dev”合并到“main”中

但是，現在dev分支是一個提交落后于main. 我如何最好地解決這個問題？到目前為止，我只是簡單地再次合并main，dev但這似乎既麻煩又奇怪，因為它們現在是我dev分支中的另一個提交；

將分支'main'合并到'dev'

我也可以在 main 上 rebase dev，但我知道“你永遠不應該 rebase public 分支”

這個SO question 告訴我正確的方法是首先將 main 合并到 dev 中，以確保 main 分支保持干凈。這會是實作dev --> main合并的最佳方式嗎？

這是否受到 git fast-forwards默認合并的概念的影響？我讀到，當從當前分支尖端到目標分支存在線性路徑時，就會發生快進合并。這意味著，當dev分支只是在合并時x的提交之前main，并且在此期間沒有向 main 提交（這在我們的作業中很常見，因為我們在技術上只提交到mainfrom dev），合并將自動快進合并？這種行為對于合并是否有問題，合并dev時main是否應該使用該-no-ff標志？

如果我理解正確，快進合并會將提交集成到分支中，而合并會導致合并始終創建一個新的提交物件，即使可以使用快進執行合并（來源：This SO question）。這是否意味著 ff 合并不會創建提交，而 dev 只是提前提交給 main？在本地合并分支后，我將如何向上游推送合并？我是否應該在本地合并 dev 和 main 或者只是繼續使用 gitlab Web 界面呢？devmain--no-ffx

不用說，我對這一切感到非常困惑。如果有人能把事情弄清楚就好了。

uj5u.com熱心網友回復：

您對做什么的理解git merge --no-ff幾乎是正確的。可能需要調整的部分是您使用集成這個詞來表示快進，而重要的是要意識到無論您是允許快進發生，還是使用--no-ff強制創建合并提交，生成的檔案結構是完全相同的。在這兩種情況下，所有提交都是“集成的”，您可以在具有相同提交 ID 的兩個分支中看到它們。強制合并提交會影響分支歷史的圖表。請注意，在快進合并之后，分支是相同的，這意味著兩個分支名稱都指向相同的提交 ID。如果快進是可能的，但你使用--no-ff相反，要創建合并提交，其中一個分支指向合并提交，并且如您所見，它將是源分支之前的一個提交。這導致我們提出您的問題：

但是，現在dev分支是一個提交落后于main. 我如何最好地解決這個問題？到目前為止，我只是簡單地再次合并main，dev但這似乎既麻煩又奇怪，因為它們現在是我dev分支中的另一個提交：

這里有兩個觀察：

1. 實際上，如果您在出現任何新提交之前dev合并到main然后再main回傳，則可以快速回傳到，并且您不必生成新的合并提交（帶有訊息“將分支主合并到開發”）如果你不希望。如果您允許快進合并，那么之后將指向與合并提交相同的提交，并帶有訊息“Merge branch dev into main”。如果您選擇使用該合并，那么您當然會創建一個新的合并提交。dev devdevdevmain--no-ff
2. 讓我們假設合并提交在那里，要么是因為新提交潛入dev了兩個合并之間，要么是因為您使用--no-ff并強制了它。所以呢？如果您強制合并提交（例如默認的 Git Flow 推薦），那么是的，您將有合并提交，這意味著dev并且main永遠不會相同，這完全沒問題。

現在讓我們來解決您的其他一些問題：

這個 SO question 告訴我正確的方法是首先將 main 合并到 dev 中，以確保 main 分支保持干凈。這會是實作 dev --> main 合并的最佳方式嗎？

隨你（由你決定。在 Git Flow 模型中，如果出現新的提交，main您通常會希望盡快合并main回來，dev這樣您就不會測驗與您將部署的內容不同的東西。 （或者更糟糕的是，如果您從dev臨時release分支進行部署，那么您不會從生產中洗掉修補程式更改，main因為它們還沒有在您的release分支中。）因此，您實際上不需要合并mainintodev合并dev到main.相反，如果出現修補程式，main您應該在dev不久之后將它們合并到。然后dev將始終準備好合并到main.

這是否受到 git fast-forwards 默認合并的概念的影響？...當 dev 分支只是在提交到 main 之前 x 時 ...合并將自動成為快進合并？

是的。如果可能，快進合并是默認設定。

這種行為對于將 dev 合并到 main 是否有問題，合并時是否應該使用 -no-ff 標志？

這沒有問題。您是否應該強制合并提交取決于您。有一些優點和缺點。取自我對另一個問題的回答：

合并（使用--no-ff）強制合并提交，這很有幫助，因為每個 PR 都包含與該 PR 關聯的提交串列，使您能夠查看顯示所有合并到分支的第一父歷史記錄，并輕松比較它們。強制合并提交的另一個好處是很容易通過簡單地恢復合并提交來恢復整個 PR，而不是單獨恢復原始 PR 中的每個提交。

請注意，GitLab 將“拉取請求”稱為“合并請求”，因此您可以在上一段中看到“PR”的地方替換“MR”。強制合并提交的唯一缺點是：如果您不關心剛才提到的任何這些優點，那么它會給結果圖增加不必要的復雜性。

最后，你問：

在本地合并分支后，我將如何向上游推送合并？我是否應該在本地合并 dev 和 main 或者只是繼續使用 gitlab Web 界面呢？

如果您沒有啟用分支保護，這沒有什么區別。dev如果您為您的和分支（在 GitLab 中）打開分支保護/策略main，那么您將需要使用合并請求功能來執行這些合并。完成合并請求后，您可以選擇是要快進還是強制合并提交。如果您在本地執行此操作，那么您只需將分支推送到遠程服務器 (GitLab)，前提是您有權執行此操作。無論哪種方式，最終的結果都是一樣的。

uj5u.com熱心網友回復：

當您一次提出多個問題時，我想將我的回答集中在您問題的一部分上。您可以問自己，該專案/團隊甚至擁有一個開發分支是否是一個好主意。沒有它，您可能會更有效率和/或擁有相同的代碼質量和/或維護能力。參見例如這個關于擁有開發分支的好處的問題。

關于本地與 Gitlab/Github 合并：我總是嘗試與 Gitlab 合并，因為它允許討論更改并將有關合并（請求）的鏈接更容易地發送給其他人。此外，它可以讓您在合并實際發生之前更輕松地依賴 CI，因此只有在管道成功時才進行合并（參見例如這個 Gitlab 檔案）。

uj5u.com熱心網友回復：

我認為解決您的問題（將提交中的更改從分支main帶到dev分支）的最佳解決方案是使用git cherry-pick. 這使您能夠從沒有main合并或變基的情況下進行一組提交，并避免您指出的所有問題。

看看這個指南，前段時間幫了我很多。

標籤：

上一篇：自新SSH規則以來的備用GitHub部署選項

下一篇：檔案夾丟失時的Git合并沖突