使用 Gitlab MR 合並到 master 后開發分支落后

Question

我使用 GitLab 合並請求合並了從開發到主的一些更改，並且我壓縮了提交。 合並后，我比較了兩個分支，它顯示了錯誤的差異。 我預計沒有差異，因為它們在合並后是相同的。 我檢查了提交圖，發現開發和主分支現在已斷開連接。

合並后的圖表：

為什么合並后master分支在develop之前？ 這是預期的行為嗎？ 我正在使用 Gitlab 12.9。 我想保留開發分支以供將來開發，但我想避免出現不必要的差異。

Answer 1

本質上，git 只有一種跟蹤歷史的方式：每個提交都有零個或多個父級。 通過從提交向后跟蹤其父項及其父項，git 可以確定該提交歷史中的提交。

當你合並兩個分支時，比如說develop成master，你有三個選擇：

1. 如果 master 上的所有提交在 develop 上已經存在，您只需移動 master 的分支指針以匹配 develop 即可，無需創建任何新提交。 這是一個“快進合並”。
2. 您可以創建一個新的提交，它同時具有開發和主控作為其父級。 開發歷史中的所有提交現在也都在主歷史中。
3. 您可以將兩個分支之間的所有差異“壓縮”到一個提交中，只有 master 作為其父級。 現在，develop 的所有更改都將在 master 上，但是構成這些更改的所有提交都不在 master 的歷史記錄中。

當您下一次要求合並相同的分支時，git 將查找在開發上存在但在主控上不存在的提交。 如果您選擇了選項 3，那么您從其中壓縮更改的所有提交仍屬於該類別。

教訓是只在你以后要扔掉的樹枝上使用壁球合並。 例如，您處理的每個任務都可以在一個新分支中； 你從develop（或master，或main，或任何地方）的當前state啟動它，擠壓合並它，然后刪除分支。 下一個任務再次從開發/主/主開始，而不是從舊任務分支開始，所以你壓扁的舊提交不再重要。

或者（和我個人的偏好），不要使用壁球合並。 使每個提交有意義，使用git rebase -i和git commit --amend來整理您不希望在歷史記錄中出現的愚蠢錯誤（小心只重寫您未與其他用戶或其他分支共享的歷史記錄） ，然后使用快進合並或合並提交。