好吧，我認為這是一個簡單的git場景，我錯過了什么？我有一個master分支和一個feature分支。我做了一些工作master，一些工作，feature然后再做一些工作master。我最終得到這樣的東西（詞典順序暗示了提交的順序）：A--B--C------F--G (master) \ D--E (feature)我沒有問題要git push origin master保持遠程master更新，也沒有git push origin feature（當打開時feature）為我的feature工作維護遠程備份。到目前為止，我們很好。但是現在我想在主人feature的F--G提交之上重新定義，所以我git checkout feature和git rebase master。還好?，F在我們有：A--B--C------F--G (master) \ D'--E' (feature)問題：當我想要備份新的rebased feature分支時git push origin feature，推送被拒絕，因為樹由于變基而發生了變化。這只能通過解決git push --force origin feature。我討厭使用--force而不確定我是否需要它。那么，我需要它嗎？重新定位是否必然意味著下一個push應該是--force完美的？這個功能分支不與任何其他開發者共享，所以我事實上沒有問題，推力，我不會丟失任何數據，問題更具概念性。
3 回答
千巷貓影
TA貢獻1829條經驗 獲得超7個贊
而不是使用-f或--force開發人員應該使用
--force-with-lease
為什么？因為它檢查遠程分支的更改，這絕對是個好主意。讓我們想象一下，詹姆斯和麗莎正在研究同一個功能分支，麗莎已經推動了提交。詹姆斯現在重新調整他的當地分支，并在試圖推動時被拒絕。當然，詹姆斯認為這是因為改變并使用--force并且會改寫所有Lisa的變化。如果詹姆斯曾經使用過--force-with-lease，那么他會收到一個警告，告知其他人已做過提交。我不明白為什么有人會在推銷一個rebase之后使用--force而不是--force-with-lease。
GCT1015
TA貢獻1827條經驗 獲得超4個贊
對此的一個解決方案是執行msysGit的rebasing合并腳本所做的事情- 在rebase之后，在舊的head中feature合并-s ours。你最終得到了提交圖：
A--B--C------F--G (master)
\ \
\ D'--E' (feature)
\ /
\ --
\ /
D--E (old-feature)
...而你的推動feature將是一個快速前進。
換句話說，你可以這樣做：
git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature
（未經測試，但我認為這是正確的......）
鳳凰求蠱
TA貢獻1825條經驗 獲得超4個贊
問題是git push假設遠程分支可以快速轉發到本地分支，即本地和遠程分支之間的所有區別在本地有一些新的提交，如下所示：
Z--X--R <- origin/some-branch (can be fast-forwarded to Y commit)
\
T--Y <- some-branch
執行git rebase提交時，D和E將應用于新基礎，并創建新的提交。這意味著在rebase之后你會有類似的東西：
A--B--C------F--G--D'--E' <- feature-branch
\
D--E <- origin/feature-branch
在那種情況下，遠程分支無法快速轉發到本地。雖然，理論上本地分支可以合并到遠程（顯然你在這種情況下你不需要它），但是git push只執行快進合并它會引發錯誤。
什么--force選項只是忽略遠程分支的狀態并將其設置為您正在推送它的提交。所以git push --force origin feature-branch簡單地origin/feature-branch用本地覆蓋feature-branch。
在我看來，master只要您是唯一一個在該分支上工作的人，就可以將功能分支和強制推送回遠程存儲庫。
- 3 回答
- 0 關注
- 1252 瀏覽
添加回答
舉報
0/150
提交
取消