我將嘗試描述導致誤解行為的 git 操作序列。
從這個場景開始，本地 (LM) 和遠程 (RM) 分支 master 提交 m1 和 m2：
RM --- m1 --- m2
LM --- m1 --- m2
創建本地功能分支（LF）并提交 f1
RM --- m1 --- m2
LM --- m1 --- m2
LF --- m1 --- m2 --- f1
推送此分支以跟蹤遠程分支 (RF)，然后將其合并到遠程主 (RM)：
RM --- m1 --- m2 --- f1
LM --- m1 --- m2
射頻 --- m1 --- m2 --- f1
LF --- m1 --- m2 --- f1
作為合并的結果，遠程功能分支 (RF) 被洗掉，新的提交 x 添加到遠程主 (RM)：
RM --- m1 --- m2 --- f1 --- x
LM --- m1 --- m2
LF --- m1 --- m2 --- f1
本地主分支 (LM) 已更新，并對本地功能分支 (LF) 進行新提交：
RM --- m1 --- m2 --- f1 --- x
LM --- m1 --- m2 --- f1 --- x
LF --- m1 --- m2 --- f1 --- f2
當推送本地功能分支 (LF) 時，提交 f1 和 f2 被視為要推送的提交，但自上次推送以來僅添加了 f2。這種行為的解釋是什么？git 幕后發生了什么？
請注意，如果此時從 master 創建了一個新分支，并且 f2 是從 LF 中挑選出來的，那么在執行推送操作時，只有 f2 顯示為要推送的提交。
uj5u.com熱心網友回復：
關鍵步驟是這一步：“...然后將其合并到遠程主站（RM）中” 根據使用的合并型別，結果將大不相同。
- 如果使用真正的快進，則歷史記錄看起來就像您繪制的那樣。
- 如果使用了變基，則提交“f1”將被重新創建，因此 RM 的歷史記錄實際上將是
m1 --- m2 --- f1_new. - “擠壓合并”與變基的作用相同，因為只有一次提交。
- “真正的合并”將創建一個合并提交，因此歷史記錄看起來像這樣：
m1 --- m2 -- M
\ /
f1
您看到的行為與使用變基或壓縮合并一致 - 您有一個與f1 相同的提交，但不是相同的提交。它有一個新的父節點和一個新的提交日期，因此有一個新的提交哈希。
您可以通過查看您擁有的分支歷史記錄中的提交哈希來親眼看到這一點。您標記為“f1”的提交實際上每個都有不同的 ID。
現在，當您要求分支之間的差異，或者從一個合并到另一個時，git 并不關心兩個提交是否“非常相似”，只有當它們實際上是完全相同的提交時。“RM”上不存在提交“f1”，因此將包含在比較或合并中。
經驗法則是永遠不要在要繼續使用的分支上使用變基或壓縮合并。使用真正的合并，然后 git 就會知道兩個分支之間的正確關系。
uj5u.com熱心網友回復：
當您將 f1 合并到 master 時，它在 git 眼中不再是 f1。Git 將其視為類似于f1'（一個新的提交哈希）。
所以你會有如下內容：
推送此分支以跟蹤遠程分支 (RF)，然后將其合并到遠程主 (RM)：
RM --- m1 --- m2 --- f1'
LM --- m1 --- m2
射頻 --- m1 --- m2 --- f1
LF --- m1 --- m2 --- f1
所以你的下一個序列是：
作為合并的結果，遠程功能分支 (RF) 被洗掉，新的提交 x 添加到遠程主 (RM)：
RM --- m1 --- m2 --- f1' --- x
LM --- m1 --- m2
LF --- m1 --- m2 --- f1
本地主分支 (LM) 已更新，并對本地功能分支 (LF) 進行新提交：
RM --- m1 --- m2 --- f1' --- x
LM --- m1 --- m2 --- f1' --- x
LF --- m1 --- m2 --- f1 --- f2
這就是為什么LF 的f1和f2被識別為新提交的原因。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/313224.html
標籤：混帐