Es stellt sich heraus, dass die Antwort viel einfacher ist, wenn Sie einfach versuchen, zwei Repositorys zusammenzukleben und es so aussehen zu lassen, als wäre es die ganze Zeit so gewesen, anstatt eine externe Abhängigkeit zu verwalten. Sie müssen lediglich Ihren alten Repos Fernbedienungen hinzufügen, sie mit Ihrem neuen Master zusammenführen, die Dateien und Ordner in ein Unterverzeichnis verschieben, die Verschiebung festschreiben und für alle weiteren Repos wiederholen. Submodule, Teilbaumzusammenführungen und ausgefallene Rebases sollen ein etwas anderes Problem lösen und sind nicht für das geeignet, was ich versucht habe.
Hier ist ein Beispiel für ein Powershell-Skript zum Zusammenkleben von zwei Repositorys:
# Assume the current directory is where we want the new repository to be created
# Create the new repository
git init
# Before we do a merge, we have to have an initial commit, so we'll make a dummy commit
git commit --allow-empty -m "Initial dummy commit"
# Add a remote for and fetch the old repo
git remote add -f old_a <OldA repo URL>
# Merge the files from old_a/master into new/master
git merge old_a/master --allow-unrelated-histories
# Move the old_a repo files and folders into a subdirectory so they don't collide with the other repo coming later
mkdir old_a
dir -exclude old_a | %{git mv $_.Name old_a}
# Commit the move
git commit -m "Move old_a files into subdir"
# Do the same thing for old_b
git remote add -f old_b <OldB repo URL>
git merge old_b/master --allow-unrelated-histories
mkdir old_b
dir –exclude old_a,old_b | %{git mv $_.Name old_b}
git commit -m "Move old_b files into subdir"
Natürlich können Sie stattdessen old_b in old_a zusammenführen (was zum neuen kombinierten Repo wird), wenn Sie dies lieber tun möchten - ändern Sie das Skript entsprechend.
Verwenden Sie Folgendes, wenn Sie auch laufende Feature-Zweige übernehmen möchten:
# Bring over a feature branch from one of the old repos
git checkout -b feature-in-progress
git merge -s recursive -Xsubtree=old_a old_a/feature-in-progress
Dies ist der einzige nicht offensichtliche Teil des Prozesses - dies ist keine Zusammenführung von Teilbäumen, sondern ein Argument für die normale rekursive Zusammenführung, das Git mitteilt, dass wir das Ziel umbenannt haben und Git dabei hilft, alles richtig auszurichten.
Ich schrieb eine etwas ausführlichere Erklärung nach oben hier .
