我將一個開放的 Git 存盤庫（upstream/master）匯入到我自己的存盤庫（origin/master）中，并在 origin/master 上進行開發。因為upstream/master 是活動的，自從我克隆repo 以來，很多提交已經被推送到分支中；upstream/master 和 branch/master 如下所示。
--o--o--M--...--N---...--O-----o <- upstream/master
\
A------B------C----- ... --D <- branch/master
如果我將上游合并到我的主分支中，它將如下所示：
--o--o--M--...--N---...--O-----o <- upstream/master
\
A---M--B----N-C------O--...--D <- master(upstream merged)
但是，由于合并時提交是交錯的，如果提交 N 破壞了我的主分支，則提交 CD 將被破壞。雖然我可以用新的提交修復分支，但 CD 部分仍然會損壞。
如何避免損壞的部分？或者對于這種情況有什么最佳實踐嗎？
uj5u.com熱心網友回復：
合并不會重寫任何現有的歷史記錄，實際上很難像在 git 中顯示的那樣創建“交錯”的歷史記錄。
如果你從這個開始：
--X-----M-----N-----O-----P <- upstream
\
A------B------C------D <- mybranch
然后將上游直接合并到 mybranch 將創建一個新的“合并提交”，其中：
- 應用兩個分支自上一個共同祖先（標記為 X）以來所做的更改
- 有兩個“父”提交，P 和 D，這就是 git 記錄歷史的方式
所以結果是這樣的：
--X-----M-----N-----O-------P <- upstream
\ \
A------B------C------D----E <- mybranch
從 git 的角度來看，所有顯示的提交都是提交 E 的“祖先”，無論它們在哪個分支上，但是 C 和 N 之間沒有直接關系。
有是一種方法來合并代碼，再現舊的改變，所謂的“重訂”，這看你每次對其進行更改，并創建一個新的提交假裝你做P上，而不是X的頂部是改變它沒有“交叉”但是，提交后，它會在您“重新定位到”之后將所有新內容按順序排列，給出如下內容：
--X-----M-----N-----O-----P <- upstream
\
A1------B1------C1------D1 <- mybranch
（很容易認為提交 A 到 E 已經“移動”了，但是 git 中的提交是不可變的，并且代表整個代碼的狀態，而不是更改，因此必須通過“rebase”創建新的提交 A1 到 E1機械。）
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/341651.html
標籤：混帐