所以說我已經提交了我的dev分支，
a
b
c
我向main分支發出拉取/合并請求，并打開了壓縮合并選項。
所以main分支現在看起來像，
merge from 'dev' to 'main'
squash: a, b, c
但是我的源分支dev仍然是三個單獨的提交。當我git rebase main在dev分支上進行操作時，這可能是一個問題，尤其是當main分支中塞滿了其他開發人員的壓縮合并時。
通常，我會cherry-pick提前提交到一個dev_bak分支。洗掉我當前的分支dev并通過執行重新發布它
git switch [any-branch]
git branch -d dev // delete dev branch
git checkout -b dev // re-create dev branch
git rebase main // do rebase
git push --force // force push to remote to overwrite
并挑選我的提前提交回到dev分支。
所以我想知道是否有一種快速的方法來做到這一點？也許git rebase --force？
謝謝！！
uj5u.com熱心網友回復：
首先，讓我們想象一下您的場景：
o---o---o-----S (main)
\
A---B---C (dev)
CommitS是 squashing 的結果A，B并C轉化為單個提交并將其應用到目標分支（又名“ squash merge ”）。
現在，你指的這個問題是由于這樣的事實，S是不相關的，以原提交A，B并且C即使它包含了同樣的變化。重訂dev之上main將導致合并沖突，Git的試圖重新應用上的壓扁的提交頂部同樣的變化。
您正在尋找的命令reset帶有以下--hard選項：
git switch dev
git reset --hard main
這會將dev分支移動到與以下相同的提交main：
o---o---o-----S (main, dev)
\
A---B---C
承諾A，B而C現在變得不可達，并最終將被洗掉。
請注意，該--hard選項還將同步您作業目錄中的檔案以匹配您要重置的提交。這意味著當您執行此操作時，您的作業目錄中任何未提交的更改都將被丟棄。在執行git reset --hard.
uj5u.com熱心網友回復：
您最好的選擇是不要對您不洗掉的分支使用壁球合并。一個壁球合并扔掉了一個分支上的歷史；無論如何，只有當您要洗掉該分支時才有意義。對于長時間運行的分支，最好創建一個合并提交，以便記錄分支之間的關系。
因為壁球合并不會記錄哪些提交被合并，如果您繼續使用分支，您將需要手動跟蹤。
如果您可視化您擁有的提交圖以及您嘗試創建的內容，那么您可以確定要使用的 rebase 命令 - 這不是關于“強制”rebase，而是關于告訴 git 您想要保留哪些提交。
假設我們從這個開始：
... <--A <--B <--C <--D <--E <--F
^ ^
main dev
然后將 dev 壓縮合并到 main（提交 DEF），并繼續提交到 dev：
... <--A <--B <--C <--D <--E <--F <--G <--H
\ ^
<-- DEF dev
^
main
你想要結束的是這個（提交 GR 和 HR 分別重新創建 G 和 H 的變化）：
... <--A <--B <--C
\
<-- DEF <--GR <--HR
^ ^
main dev
git rebase有一個三引數形式，我讀作“rebase commits from old_base to tip to new_base”：（git rebase old_base tip --onto new_base有些人更喜歡把第--onto new_base一個，這真的沒關系）。
因此，在這種情況下，我們希望“將 F 到 H 的提交重新系結到 DEF 上”（因為 F 是我們壓縮的最后一次提交）：
git rebase F H --onto DEF
由于我們有一些分支指標，我們只需要查找 F 的提交哈希，就可以這樣寫：
git rebase F dev --onto main
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/343930.html