將git merge和rebase結合起來會發生什麼？

一個反對git rebase的觀點可能是它是一個比合並更復雜的過程，如果多個開發人員共享一個功能分支，中游rebases意味着所有其他開發人員必須刪除他們的本地分支並從中央獲取全新副本存儲庫（或者開始使用差異分支）。將git merge和rebase結合起來會發生什麼？

在多個開發者共享一個分支的情況下，git merge是一個更簡單的工作流程。但是當功能完成後，最終合併到「掌握」呢？如果不是一路沿用「rebase」與master保持同步，你會一直使用'merge'，但在最終交付給'master'時，你會使用交互式'rebase'來實現一個乾淨的線性歷史記錄並壓扁無趣的承諾？特別是，當'合併'提交重播或git如何處理時會發生什麼？

來源

2017-02-28 Bryji

如果你最終推動力，Rebase只是一個問題，但如果你這樣做，任何操作都是一個問題。在您結束時將目標分支重新綁定的情況下，git處理完全正常，只是重放合併，如果相同的合併發生衝突，可能會發生衝突。對於大多數情況下，如果相應的合併也會有問題，那麼重新分配只會產生問題。

來源

2017-02-28 16:29:04

通常，您會希望避免重新扣款任何已通過推送公開的提交。在你的情況中，你可以避免這種情況，因爲你正在重新設計一個臨時特性分支，並且因爲你可以非常清楚地與你的團隊進行交流（即在那個分支上工作的那些分支），一旦開發結束，分支基本消失，已經重新進入你的主人。

除此之外，重新綁定包含合併的分支並沒有真正的問題。從主服務器提交的合併提交將從您的重定向分支中簡單消失（因爲您已重新組合，這些更改已經集成），並且您可以輕鬆地運行交互式合併，以便後續清理歷史記錄。

來源

2017-02-28 16:35:28 poke

我遇到的理由是，難以讓所有其他團隊成員對齊rebase。我不確定這是否真的會成爲問題。他們需要能夠理解和應對突然偏離本地的遠程分支機構。 – Bryji

是的，如果分支真的處於其生命的盡頭（由於合併或重新分配給主分支），您只會執行此操作。因此，理想情況下，在重新綁定之後，您將推送主分支並刪除遠程功能分支。這樣，其他成員不應該有真正的問題 - 除了當然一般的混淆，這就是爲什麼你應該溝通這個工作流程。除此之外，他們當地的（未經過重新設計和過時的）分支不會分手，而只會過時。 – poke

將git merge和rebase結合起來會發生什麼？

回答

相關問題