Wie importiere ich ein vorhandenes Git-Repository in ein anderes?

Ich habe ein Git-Repository in einem Ordner namens XXX und ich habe ein zweites Git-Repository namens YYY .

Ich möchte das XXX- Repository als Unterverzeichnis mit dem Namen ZZZ in das JJJ- Repository importieren und den gesamten Änderungsverlauf von XXX zu JJJ hinzufügen .

Ordnerstruktur vor:

├── XXX
│   ├── .git
│   └── (project files)
└── YYY
    ├── .git
    └── (project files)

Ordnerstruktur nach:

YYY
├── .git  <-- This now contains the change history from XXX
├──  ZZZ  <-- This was originally XXX
│    └── (project files)
└──  (project files)

Kann das gemacht werden oder muss ich auf Submodule zurückgreifen?

Der wahrscheinlich einfachste Weg wäre, das XXX- Zeug in einen Zweig in YYY zu ziehen und es dann in master zusammenzuführen:

In JJJ :

git remote add other /path/to/XXX
git fetch other
git checkout -b ZZZ other/master
mkdir ZZZ
git mv stuff ZZZ/stuff                      # repeat as necessary for each file/dir
git commit -m "Moved stuff to ZZZ"
git checkout master                
git merge ZZZ --allow-unrelated-histories   # should add ZZZ/ to master
git commit
git remote rm other
git branch -d ZZZ                           # to get rid of the extra branch before pushing
git push                                    # if you have a remote, that is

Ich habe das gerade mit ein paar meiner Repos versucht und es funktioniert. Im Gegensatz zu Jörgs Antwort können Sie das andere Repo nicht weiter verwenden, aber ich glaube, Sie haben das sowieso nicht angegeben.

Hinweis: Da dies ursprünglich im Jahr 2009 geschrieben wurde, hat git die in der Antwort unten erwähnte Zusammenführung von Teilbäumen hinzugefügt. Ich würde diese Methode wahrscheinlich heute verwenden, obwohl diese Methode natürlich immer noch funktioniert.

Wenn Sie den genauen Festschreibungsverlauf des zweiten Repositorys beibehalten und daher auch in Zukunft problemlos Upstream-Änderungen zusammenführen möchten, finden Sie hier die gewünschte Methode. Dies führt dazu, dass der unveränderte Verlauf des Teilbaums in Ihr Repo importiert wird, plus ein Zusammenführungs-Commit, um das zusammengeführte Repository in das Unterverzeichnis zu verschieben.

git remote add XXX_remote <path-or-url-to-XXX-repo>
git fetch XXX_remote
git merge -s ours --no-commit --allow-unrelated-histories XXX_remote/master
git read-tree --prefix=ZZZ/ -u XXX_remote/master
git commit -m "Imported XXX as a subtree."

Sie können Upstream-Änderungen folgendermaßen verfolgen:

git pull -s subtree XXX_remote master

Git findet selbst heraus, wo sich die Wurzeln befinden, bevor die Zusammenführung durchgeführt wird, sodass Sie das Präfix bei nachfolgenden Zusammenführungen nicht angeben müssen.

Der Nachteil ist, dass im zusammengeführten Verlauf die Dateien nicht fixiert sind (nicht in einem Unterverzeichnis). Als Ergebnis git log ZZZ/awerden Ihnen alle Änderungen (falls vorhanden) mit Ausnahme derjenigen im zusammengeführten Verlauf angezeigt. Du kannst tun:

git log --follow -- a

Dadurch werden jedoch keine anderen Änderungen als in der zusammengeführten Historie angezeigt.

Mit anderen Worten, wenn Sie die ZZZDateien im Repository nicht ändern , XXXmüssen Sie --followeinen nicht festgelegten Pfad angeben . Wenn Sie sie in beiden Repositorys ändern, haben Sie zwei Befehle, von denen keiner alle Änderungen anzeigt.

Git-Versionen vor 2.9 : Sie müssen die --allow-unrelated-historiesOption nicht an übergeben git merge.

Die Methode in der anderen Antwort, die read-treeden merge -s oursSchritt verwendet und überspringt, unterscheidet sich effektiv nicht vom Kopieren der Dateien mit cp und Festschreiben des Ergebnisses.

Die ursprüngliche Quelle war der Hilfeartikel "Subtree Merge" von github . Und noch ein nützlicher Link .

git-subtreeist ein Skript, das genau für diesen Anwendungsfall entwickelt wurde, bei dem mehrere Repositorys zu einem zusammengeführt werden, während der Verlauf beibehalten wird (und / oder der Verlauf von Teilbäumen aufgeteilt wird, obwohl dies für diese Frage irrelevant zu sein scheint). Es wird seit Release 1.7.11 als Teil des Git-Baums verteilt .

Verwenden Sie Folgendes, um ein Repository <repo>bei der Revision <rev>als Unterverzeichnis zusammenzuführen :<prefix>git subtree add

git subtree add -P <prefix> <repo> <rev>

git-subtree implementiert die Strategie zum Zusammenführen von Teilbäumen benutzerfreundlicher.

Für Ihren Fall würden Sie im Repository JJJ Folgendes ausführen:

git subtree add -P ZZZ /path/to/XXX.git master

Der Nachteil ist, dass im zusammengeführten Verlauf die Dateien nicht fixiert sind (nicht in einem Unterverzeichnis). Als Ergebnis git log ZZZ/awerden Ihnen alle Änderungen (falls vorhanden) mit Ausnahme derjenigen im zusammengeführten Verlauf angezeigt. Du kannst tun:

git log --follow -- a

Dadurch werden jedoch keine anderen Änderungen als in der zusammengeführten Historie angezeigt.

Mit anderen Worten, wenn Sie die ZZZDateien im Repository nicht ändern , XXXmüssen Sie --followeinen nicht festgelegten Pfad angeben . Wenn Sie sie in beiden Repositorys ändern, haben Sie zwei Befehle, von denen keiner alle Änderungen anzeigt.

Mehr dazu hier .

Es gibt eine bekannte Instanz davon im Git-Repository selbst, die in der Git-Community zusammenfassend als " die coolste Zusammenführung aller Zeiten " bezeichnet wird (nach der Betreffzeile, die Linus Torvalds in der E-Mail an die Git-Mailingliste verwendet hat, die dies beschreibt verschmelzen). In diesem Fall war die gitkGit-GUI, die jetzt Teil von Git ist, eigentlich ein separates Projekt. Linus hat es geschafft, dieses Repository auf diese Weise mit dem Git-Repository zusammenzuführen

• Es erscheint im Git-Repository so, als ob es immer als Teil von Git entwickelt worden wäre.
• Die ganze Geschichte wird intakt gehalten und
• Es kann weiterhin unabhängig in seinem alten Repository entwickelt werden, wobei Änderungen einfach git pullbearbeitet werden.

Die E-Mail die Schritte enthält zum Reproduzieren benötigt, aber es ist nicht für schwache Nerven: Erstens, Linus schrieb Git, so dass er wahrscheinlich ein bisschen mehr darüber weiß als du oder ich, und zweitens, das fast 5 Jahren war vor und Git hat sich seitdem erheblich verbessert , vielleicht ist es jetzt viel einfacher.

Insbesondere denke ich, dass man heutzutage in diesem speziellen Fall ein Gitk-Submodul verwenden würde.

Der einfache Weg, dies zu tun, ist die Verwendung des Git-Format-Patches.

Angenommen, wir haben 2 Git-Repositories foo und bar .

foo enthält:

• foo.txt
• .git

Bar enthält:

• bar.txt
• .git

und wir wollen mit foo enden, das die Bar enthält und diese Dateien enthält:

• foo.txt
• .git
• foobar / bar.txt

Also, um das zu tun:

 1. create a temporary directory eg PATH_YOU_WANT/patch-bar
 2. go in bar directory
 3. git format-patch --root HEAD --no-stat -o PATH_YOU_WANT/patch-bar --src-prefix=a/foobar/ --dst-prefix=b/foobar/
 4. go in foo directory
 5. git am PATH_YOU_WANT/patch-bar/*

Und wenn wir alle Nachrichten-Commits von bar neu schreiben möchten, können wir dies tun, z. B. unter Linux:

git filter-branch --msg-filter 'sed "1s/^/\[bar\] /"' COMMIT_SHA1_OF_THE_PARENT_OF_THE_FIRST_BAR_COMMIT..HEAD

Dadurch wird am Anfang jeder Festschreibungsnachricht "[bar]" hinzugefügt.

Diese Funktion klont das Remote-Repo in das lokale Repo-Verzeichnis. Nach dem Zusammenführen werden alle Commits gespeichert und git logdie ursprünglichen Commits und die richtigen Pfade angezeigt:

function git-add-repo
{
    repo="$1"
    dir="$(echo "$2" | sed 's/\/$//')"
    path="$(pwd)"

    tmp="$(mktemp -d)"
    remote="$(echo "$tmp" | sed 's/\///g'| sed 's/\./_/g')"

    git clone "$repo" "$tmp"
    cd "$tmp"

    git filter-branch --index-filter '
        git ls-files -s |
        sed "s,\t,&'"$dir"'/," |
        GIT_INDEX_FILE="$GIT_INDEX_FILE.new" git update-index --index-info &&
        mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"
    ' HEAD

    cd "$path"
    git remote add -f "$remote" "file://$tmp/.git"
    git pull "$remote/master"
    git merge --allow-unrelated-histories -m "Merge repo $repo into master" --edit "$remote/master"
    git remote remove "$remote"
    rm -rf "$tmp"
}

Wie benutzt man:

cd current/package
git-add-repo https://github.com/example/example dir/to/save

Wenn Sie ein wenig Änderungen vornehmen, können Sie sogar Dateien / Verzeichnisse von zusammengeführtem Repo in verschiedene Pfade verschieben, zum Beispiel:

repo="https://github.com/example/example"
path="$(pwd)"

tmp="$(mktemp -d)"
remote="$(echo "$tmp" | sed 's/\///g' | sed 's/\./_/g')"

git clone "$repo" "$tmp"
cd "$tmp"

GIT_ADD_STORED=""

function git-mv-store
{
    from="$(echo "$1" | sed 's/\./\\./')"
    to="$(echo "$2" | sed 's/\./\\./')"

    GIT_ADD_STORED+='s,\t'"$from"',\t'"$to"',;'
}

# NOTICE! This paths used for example! Use yours instead!
git-mv-store 'public/index.php' 'public/admin.php'
git-mv-store 'public/data' 'public/x/_data'
git-mv-store 'public/.htaccess' '.htaccess'
git-mv-store 'core/config' 'config/config'
git-mv-store 'core/defines.php' 'defines/defines.php'
git-mv-store 'README.md' 'doc/README.md'
git-mv-store '.gitignore' 'unneeded/.gitignore'

git filter-branch --index-filter '
    git ls-files -s |
    sed "'"$GIT_ADD_STORED"'" |
    GIT_INDEX_FILE="$GIT_INDEX_FILE.new" git update-index --index-info &&
    mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"
' HEAD

GIT_ADD_STORED=""

cd "$path"
git remote add -f "$remote" "file://$tmp/.git"
git pull "$remote/master"
git merge --allow-unrelated-histories -m "Merge repo $repo into master" --edit "$remote/master"
git remote remove "$remote"
rm -rf "$tmp"

Hinweise
Pfade werden über ersetzt. sedStellen Sie daher sicher, dass sie nach dem Zusammenführen in den richtigen Pfaden verschoben wurden.
Der --allow-unrelated-historiesParameter existiert nur seit git> = 2.9.

Basierend auf diesem Artikel hat die Verwendung von Teilbaum für mich funktioniert und nur die zutreffende Historie wurde übertragen. Hier posten, falls jemand die Schritte benötigt (stellen Sie sicher, dass Sie die Platzhalter durch die für Sie zutreffenden Werte ersetzen):

Teilen Sie den Unterordner in Ihrem Quell-Repository in einen neuen Zweig auf

git subtree split --prefix=<source-path-to-merge> -b subtree-split-result

in Ihrem Ziel-Repo im Zweig für geteilte Ergebnisse zusammenführen

git remote add merge-source-repo <path-to-your-source-repository>
git fetch merge-source-repo
git merge -s ours --no-commit merge-source-repo/subtree-split-result
git read-tree --prefix=<destination-path-to-merge-into> -u merge-source-repo/subtree-split-result

Überprüfen Sie Ihre Änderungen und legen Sie fest

git status
git commit

Vergiss es nicht

Bereinigen Sie, indem Sie den subtree-split-resultZweig löschen

git branch -D subtree-split-result

Entfernen Sie die Fernbedienung, die Sie hinzugefügt haben, um die Daten aus dem Quell-Repo abzurufen

git remote rm merge-source-repo

Eine weitere Antwort hinzufügen, da ich denke, dass dies etwas einfacher ist. Ein Pull von repo_dest wird in repo_to_import ausgeführt und dann ein Push --set-upstream url: repo_dest master wird ausgeführt.

Diese Methode hat bei mir funktioniert, indem ich mehrere kleinere Repos in ein größeres importiert habe.

So importieren Sie: repo1_to_import to repo_dest

# checkout your repo1_to_import if you don't have it already 
git clone url:repo1_to_import repo1_to_import
cd repo1_to_import

# now. pull all of repo_dest
git pull url:repo_dest
ls 
git status # shows Your branch is ahead of 'origin/master' by xx commits.
# now push to repo_dest
git push --set-upstream url:repo_dest master

# repeat for other repositories you want to import

Benennen oder verschieben Sie Dateien und Verzeichnisse an die gewünschte Position im ursprünglichen Repo, bevor Sie den Import durchführen. z.B

cd repo1_to_import
mkdir topDir
git add topDir
git mv this that and the other topDir/
git commit -m"move things into topDir in preparation for exporting into new repo"
# now do the pull and push to import

Die unter dem folgenden Link beschriebene Methode hat diese Antwort inspiriert. Ich mochte es, weil es einfacher schien. Aber Vorsicht! Es gibt Drachen! https://help.github.com/articles/importing-an-external-git-repository verschiebt git push --mirror url:repo_dest Ihren lokalen Repo-Verlauf und -Status auf remote (URL: repo_dest). ABER es löscht die alte Geschichte und den Zustand der Fernbedienung. Spaß folgt! : -E

Ich wollte in meinem Fall nur einige Dateien aus dem anderen Repository (XXX) importieren. Der Teilbaum war zu kompliziert für mich und die anderen Lösungen funktionierten nicht. Das habe ich getan:

ALL_COMMITS=$(git log --reverse --pretty=format:%H -- ZZZ | tr '\n' ' ')

Auf diese Weise erhalten Sie eine durch Leerzeichen getrennte Liste aller Commits, die sich auf die Dateien auswirken, die ich importieren wollte (ZZZ), und zwar in umgekehrter Reihenfolge (möglicherweise müssen Sie --follow hinzufügen, um auch Umbenennungen zu erfassen). Ich ging dann in das Ziel-Repository (JJJ), fügte das andere Repository (XXX) als Remote hinzu, holte es ab und schließlich:

git cherry-pick $ALL_COMMITS

Wenn Sie alle Commits zu Ihrem Zweig hinzufügen, haben Sie alle Dateien mit ihrem Verlauf und können mit ihnen alles tun, was Sie wollen, als wären sie schon immer in diesem Repository.

Siehe Basisbeispiel in diesem Artikel und berücksichtigen Sie eine solche Zuordnung für Repositorys:

• A<-> YYY,
• B <-> XXX

Entfernen Sie nach allen in diesem Kapitel beschriebenen Aktivitäten (nach dem Zusammenführen) den Zweig B-master:

$ git branch -d B-master

Drücken Sie dann die Änderungen.

Für mich geht das.

Ich war in einer Situation, in der ich gesucht habe, -s theirsaber diese Strategie gibt es natürlich nicht. Meine Geschichte war, dass ich ein Projekt auf GitHub gegabelt hatte und jetzt aus irgendeinem Grund mein lokales masternicht mit zusammengeführt werden konnteupstream/master obwohl ich keine lokalen Änderungen an diesem Zweig vorgenommen hatte. (Ich weiß wirklich nicht, was dort passiert ist - ich glaube, Upstream hat hinter den Kulissen vielleicht ein paar schmutzige Stöße gemacht?)

Was ich am Ende tat, war

# as per https://help.github.com/articles/syncing-a-fork/
git fetch upstream
git checkout master
git merge upstream/master
....
# Lots of conflicts, ended up just abandonging this approach
git reset --hard   # Ditch failed merge
git checkout upstream/master
# Now in detached state
git branch -d master # !
git checkout -b master   # create new master from upstream/master

Jetzt ist my masterwieder synchron mit upstream/master(und Sie können das oben Gesagte für jeden anderen Zweig wiederholen, den Sie ebenfalls ähnlich synchronisieren möchten).

Ich kann eine andere Lösung (Alternative zu Git-Submodulen ) für Ihr Problem vorschlagen - das Gil-Tool (Git-Links)

Es ermöglicht die Beschreibung und Verwaltung komplexer Abhängigkeiten von Git-Repositorys.

Außerdem bietet es eine Lösung für das Abhängigkeitsproblem der rekursiven Git-Submodule .

Angenommen, Sie haben die folgenden Projektabhängigkeiten: Beispiel eines Git-Repository-Abhängigkeitsdiagramms

Anschließend können Sie eine .gitlinksDatei mit einer Beschreibung der Repositorys definieren:

# Projects
CppBenchmark CppBenchmark https://github.com/chronoxor/CppBenchmark.git master
CppCommon CppCommon https://github.com/chronoxor/CppCommon.git master
CppLogging CppLogging https://github.com/chronoxor/CppLogging.git master

# Modules
Catch2 modules/Catch2 https://github.com/catchorg/Catch2.git master
cpp-optparse modules/cpp-optparse https://github.com/weisslj/cpp-optparse.git master
fmt modules/fmt https://github.com/fmtlib/fmt.git master
HdrHistogram modules/HdrHistogram https://github.com/HdrHistogram/HdrHistogram_c.git master
zlib modules/zlib https://github.com/madler/zlib.git master

# Scripts
build scripts/build https://github.com/chronoxor/CppBuildScripts.git master
cmake scripts/cmake https://github.com/chronoxor/CppCMakeScripts.git master

Jede Zeile beschreibt Git Link im folgenden Format:

1. Eindeutiger Name des Repositorys
2. Relativer Pfad des Repositorys (gestartet vom Pfad der .gitlinks-Datei)
3. Git-Repository, das im git-Klonbefehl Repository-Zweig zum Auschecken verwendet wird
4. Leere oder mit # begonnene Zeilen werden nicht analysiert (als Kommentar behandelt).

Schließlich müssen Sie Ihr Root-Beispiel-Repository aktualisieren:

# Clone and link all git links dependencies from .gitlinks file
gil clone
gil link

# The same result with a single command
gil update

Als Ergebnis klonen Sie alle erforderlichen Projekte und verknüpfen sie ordnungsgemäß miteinander.

Wenn Sie alle Änderungen in einem Repository mit allen Änderungen in untergeordneten verknüpften Repositorys festschreiben möchten, können Sie dies mit einem einzigen Befehl tun:

gil commit -a -m "Some big update"

Pull, Push-Befehle funktionieren auf ähnliche Weise:

gil pull
gil push

Das Gil-Tool (Git-Links) unterstützt die folgenden Befehle:

usage: gil command arguments
Supported commands:
    help - show this help
    context - command will show the current git link context of the current directory
    clone - clone all repositories that are missed in the current context
    link - link all repositories that are missed in the current context
    update - clone and link in a single operation
    pull - pull all repositories in the current directory
    push - push all repositories in the current directory
    commit - commit all repositories in the current directory

Weitere Informationen zum Abhängigkeitsproblem von rekursiven Git-Submodulen .

Lassen Sie mich Namen a(anstelle von XXXund ZZZ) und b(anstelle vonYYY ) verwenden, da dadurch die Beschreibung etwas leichter zu lesen ist.

Sagen Sie bitte Repository zusammenführen möchten ain b(Ich gehe davon aus sie nebeneinander angeordnet sind):

cd a
git filter-repo --to-subdirectory-filter a
cd ..
cd b
git remote add a ../a
git fetch a
git merge --allow-unrelated-histories a/master
git remote remove a

Hierfür müssen Sie git-filter-repoinstalliert haben ( filter-branchwird davon abgeraten ).

Ein Beispiel für das Zusammenführen von zwei großen Repositorys, wobei eines davon in einem Unterverzeichnis abgelegt wird: https://gist.github.com/x-yuri/9890ab1079cf4357d6f269d073fd9731

Mehr dazu hier .

Ich kenne keinen einfachen Weg, das zu tun. Sie könnten dies tun:

1. Verwenden Sie git filter-branch, um ein ZZZ-Superverzeichnis zum XXX-Repository hinzuzufügen
2. Verschieben Sie den neuen Zweig in das JJJ-Repository
3. Verbinden Sie den geschobenen Zweig mit dem Stamm von YYY.

Ich kann mit Details bearbeiten, wenn das ansprechend klingt.

Ich denke, Sie können dies mit 'git mv' und 'git pull' tun.

Ich bin ein fairer Idiot - seien Sie also vorsichtig mit Ihrem Haupt-Repository -, aber ich habe es nur in einem temporären Verzeichnis versucht und es scheint zu funktionieren.

Benennen Sie zuerst die Struktur von XXX so um, dass sie dem Aussehen entspricht, wenn sie sich in JJJ befindet:

cd XXX
mkdir tmp
git mv ZZZ tmp/ZZZ
git mv tmp ZZZ

Jetzt sieht XXX so aus:

XXX
 |- ZZZ
     |- ZZZ

Verwenden Sie nun 'git pull', um die Änderungen abzurufen:

cd ../YYY
git pull ../XXX

Jetzt sieht JJJ so aus:

YYY
 |- ZZZ
     |- ZZZ
 |- (other folders that already were in YYY)