我有一個項目託管在GitHub上。我們正在開發一個名爲metamodel的共享主題分支上的一組新功能，並推送給GitHub。同時，我們還在進行錯誤修復工作。這個計劃最終將元模型集成到主模型中，這時元模型分支將會消失。這兩個分支都包含兩個目錄，我們要把它們的內容合併到一個目錄中。此時，2個目錄已經在2個分支之間發散。此外，他們將繼續分歧，直到分支機構整合。在不同的git分支上合併2個目錄的內容並稍後整合分支
如果我將兩個目錄合併到每個分支上，我會將分支集成在一起會發生什麼？作爲一個項目，我們作爲一個項目，已經選擇通過重組的方式來整合分支機構，以防在此發生。
Git並不關心目錄，甚至文件名。它關心內容。而且它合併相當聰明（它會知道什麼時候只是移動或重命名）。
所以，基本上，在回答你「將這些分支結合在一起會發生什麼時會發生什麼」的問題時，答案是 - 「我不知道。」我沒有看到內容。但我可以告訴你，Git會比較有效地比較內容中的差異/相似性，並將所有內容組合在一起。 Git遇到的任何問題都會顯示爲合併衝突，您需要根據具體情況解決這些衝突。
在這種情況下，考慮到你的Git歷史和變化開始變得相當複雜，我會小心重新設計。 rebase可能正常工作，但我會準備回滾，以防它變得混亂。
由於您的分支機構分散，走了不同的路線和路徑，您最好直接合並以將它們重新組合起來。這樣你就不會冒險以有害/不可恢復的方式重寫歷史（請記住，重新定義是重寫歷史的一種形式）。此外，直接的Git合併會產生一個新的提交，其中包含所有事件的組合（考慮到已經發生的巨大差異），可能是一個有價值的「叉路」承諾，以防萬一需要回滾。
重新整合是很好的，因爲它清理你的歷史，但我絕對不會在像這樣的複雜情況下做到這一點。
基本上，如果你曾經推過一個分支到遠程，你會希望在大多數情況下避免在分支上使用rebase。在分支機構上進行一些本地更改以改善歷史記錄很不錯，但在此之後，只需使用merge，即可推送到遠程。
我只是專注於合併和清理任何衝突。