我剛剛完成了一個特別多毛的rebase（有人在分支上工作了幾周，但沒有重新綁定）。我花了大約兩三個小時，因爲我使用的「人類可讀」格式只是一堆ID和引用。在git rebase之後發生新提交時該怎麼辦？
當我做這個rebase時，在我有機會推動rebase的結果之前，在分支上出現了兩個提交。
有沒有一種最佳做法來獲得這些新的提交而不重新進行rebase或採取合併？我最初的想法是，我可以挑選那些新的提交和git push -f，但這會不會令人討厭？
你應該可以重新綁定你的提交。
唯一的問題是，您將不得不重新制定衝突解決方案，因爲您沒有激活git rerere。
那麼，你不必，與rerere-train.sh script。
見「Do you even rerere?」的Tristan Roussel：
在這種最簡單的形式，劇本從提交指定開始，經過每個家長都致力於尋找衝突。
這將允許您記錄那些過去的衝突解決方案，並再次重新綁定，而無需再次執行。
cherry-pick只是合併特定的提交，但如果你的分支包含很多提交需要合併，那麼更好rebase它。
不同的人可能有不同的最佳實踐。我遵循以下內容：
git pull --rebase這樣我就可以確保我的分支是從它創建的遠程分支獲得最新的。git push origin :feature_branch這將刪除刪除遠程功能分支。雖然我知道我可以簡單地做git push -force feature_branch但我想確認git會不會搞砸任何事:) :) :)git push origin feature_branch我會很高興知道你的做法或建議我的東西更好。
我不知道你是否明白髮生了什麼事。我做了rebase。但是後來有人偶然地向分支承諾。我問是否可以挑選那些或者是否有更聰明的方法。 （聽起來像櫻桃採摘是OK。） –
我的意思是櫻桃採摘是好的，但對於明確的歷史，我的意見總是更好地使用rebase。雖然練習你可以關注，但如果你看到git工作流程，你會發現專門用於修補程序的cherry-pick，但是有明確的歷史記錄rebase是最好的。如果你再次擔心你必須解決衝突，那麼VonC答案就是解決方案。 –
rebase只是一個自動化的櫻桃挑選系列，所以你確實可以挑選那些額外的提交。總的來說，像這樣重新分享共享分支是不禮貌的，因爲同樣的原因，將未公佈的分支推遲到將要像這樣重新分配的分支是無禮的。你和其他人需要在這裏同意這個協議：這是否會被重新發布，每個人都必須爲此做好準備，或者是永久的，沒有人必須變身，或者有一些混合，人們應該更多地溝通？ :-) – torek
是的，對方知道rebase即將到來。 （準備合併。）他只是沒有意識到他在分支上，並不斷推進一堆無關的工作。 –