Jak zaimportować istniejące repozytorium Git do innego?

Mam repozytorium Git w folderze o nazwie XXX i mam drugie repozytorium Git o nazwie YYY .

Chcę zaimportować repozytorium XXX do repozytorium YYY jako podkatalog o nazwie ZZZ i dodać całą historię zmian XXX do YYY .

Struktura folderów przed:

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

Struktura folderów po:

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

Czy można to zrobić, czy muszę skorzystać z podmodułów?

Prawdopodobnie najprostszym sposobem byłoby wciągnięcie elementów XXX do gałęzi w YYY, a następnie scalenie ich w master:

W RRRR :

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

Właśnie próbowałem tego z kilkoma moimi repozytoriami i działa. W przeciwieństwie do odpowiedzi Jörga nie pozwoli ci to na dalsze korzystanie z drugiego repozytorium, ale nie sądzę, że i tak to określiłeś.

Uwaga: Ponieważ pierwotnie napisano to w 2009 roku, git dodał scalenie poddrzewa wymienione w odpowiedzi poniżej. Prawdopodobnie skorzystałbym z tej metody dzisiaj, chociaż oczywiście ta metoda nadal działa.

Jeśli chcesz zachować dokładną historię zatwierdzeń drugiego repozytorium, a tym samym zachować możliwość łatwego scalenia wcześniejszych zmian w przyszłości, oto metoda, którą chcesz. Powoduje to niezmodyfikowaną historię importowania poddrzewa do repozytorium oraz jedno zatwierdzenie scalania, aby przenieść scalone repozytorium do podkatalogu.

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."

Możesz śledzić zmiany upstream w następujący sposób:

git pull -s subtree XXX_remote master

Git sam określa, gdzie znajdują się pierwiastki przed scaleniem, więc nie musisz określać prefiksu przy kolejnych scaleniach.

Minusem jest to, że w historii połączonego pliki są prefiksu (nie w podkatalogu). W rezultacie git log ZZZ/apokażą Ci wszystkie zmiany (jeśli wystąpią) oprócz tych w połączonej historii. Możesz to zrobić:

git log --follow -- a

ale to nie pokaże zmian innych niż w połączonej historii.

Innymi słowy, jeśli nie zmienisz ZZZplików w repozytorium XXX, musisz to określić--follow i nieokreśloną ścieżkę. Jeśli zmienisz je w obu repozytoriach, będziesz mieć 2 polecenia, z których żadne nie pokazuje wszystkich zmian.

Wersje Git wcześniejsze niż 2.9 : Nie musisz przekazywać --allow-unrelated-historiesopcji dogit merge .

Metoda w drugiej odpowiedzi, która używa read-treei pomijamerge -s ours krok, nie różni się niczym od skopiowania plików za pomocą cp i zatwierdzenia wyniku.

Oryginalne źródło pochodzi z artykułu pomocy github „Subtree Merge” . I kolejny przydatny link .

git-subtreejest skryptem zaprojektowanym do tego właśnie przypadku użycia łączenia wielu repozytoriów w jedno, przy jednoczesnym zachowaniu historii (i / lub dzieleniu historii poddrzewa, choć wydaje się to nie mieć znaczenia dla tego pytania). Jest dystrybuowany jako część drzewa git od wydania 1.7.11 .

Aby scalić repozytorium <repo>przy rewizji <rev>jako podkatalog <prefix>, użyj git subtree addnastępującego polecenia:

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

git-subtree implementuje strategię scalania poddrzewa w bardziej przyjazny dla użytkownika sposób.

W twoim przypadku w repozytorium YYY uruchomisz:

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

Minusem jest to, że w historii połączonego pliki są prefiksu (nie w podkatalogu). W rezultacie git log ZZZ/apokażą Ci wszystkie zmiany (jeśli wystąpią) oprócz tych w połączonej historii. Możesz to zrobić:

git log --follow -- a

ale to nie pokaże zmian innych niż w połączonej historii.

Innymi słowy, jeśli nie zmienisz ZZZplików w repozytorium XXX, musisz podać--follow i nieokreśloną ścieżkę. Jeśli zmienisz je w obu repozytoriach, będziesz mieć 2 polecenia, z których żadne nie pokazuje wszystkich zmian.

Więcej na ten temat tutaj .

Istnieje dobrze znany przykład tego w samym repozytorium Git, który jest zbiorowo znany w społeczności Git jako „ najfajniejsze połączenie kiedykolwiek ” (po temacie, którego Linus Torvalds użył w e-mailu do listy mailingowej Git, który opisuje to łączyć). W tym przypadku gitkGUI Git, który jest teraz częścią Git właściwego, faktycznie był osobnym projektem. Linusowi udało się połączyć to repozytorium z repozytorium Git w ten sposób

• pojawia się w repozytorium Git, tak jakby zawsze był rozwijany jako część Git,
• cała historia jest nienaruszona i
• nadal można go opracowywać niezależnie w starym repozytorium, a zmiany są po prostu git pulledytowane.

Wiadomość e-mail zawiera kroki niezbędne do odtworzenia, ale nie jest to dla osób o słabym sercu: po pierwsze, Linus napisał Git, więc prawdopodobnie wie o tym więcej niż ty lub ja, a po drugie, to było prawie 5 lat temu i git poprawiła się znacznie od tego czasu, więc może to jest teraz znacznie łatwiejsze.

W szczególności wydaje mi się, że w tym konkretnym przypadku należy użyć podmoduła gitk.

Najprostszym sposobem na to jest użycie łatki formatu git.

Załóżmy, że mamy 2 repozytoria git foo i bar .

foo zawiera:

• foo.txt
• .git

pasek zawiera:

• bar.txt
• .git

i chcemy skończyć z foo zawierającym historię paska i te pliki:

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

Aby to zrobić:

 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/*

A jeśli chcemy przepisać wszystkie zatwierdzenia wiadomości z paska, możemy to zrobić, np. W systemie Linux:

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

Spowoduje to dodanie „[bar]” na początku każdej wiadomości zatwierdzenia.

Ta funkcja sklonuje zdalne repo do lokalnego repozytorium, po scaleniu wszystkie commity zostaną zapisane, git logpokaże oryginalne commity i odpowiednie ścieżki:

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"
}

Jak używać:

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

Jeśli wprowadzisz małe zmiany, możesz nawet przenieść pliki / katalogi scalonego repozytorium na różne ścieżki, na przykład:

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"

Powiadomienia
Ścieżki zamieniają się przez sed, więc upewnij się, że po scaleniu poruszały się we właściwych ścieżkach.
Ten --allow-unrelated-historiesparametr istnieje tylko od git> = 2,9.

Na podstawie tego artykułu działało dla mnie poddrzewo i przeniesiono tylko odpowiednią historię. Publikuj tutaj, na wypadek gdyby ktoś potrzebował tych kroków (pamiętaj o zastąpieniu symboli zastępczych wartościami, które dotyczą Ciebie):

w twoim źródłowym repozytorium podziel podfolder na nowy oddział

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

w docelowym scaleniu repozytorium w gałęzi podzielonego wyniku

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

sprawdź zmiany i zatwierdź

git status
git commit

Nie zapomnij

Oczyść, usuwając subtree-split-resultgałąź

git branch -D subtree-split-result

Usuń dodany pilot, aby pobrać dane z repozytorium źródłowego

git remote rm merge-source-repo

Dodanie kolejnej odpowiedzi, ponieważ myślę, że jest to nieco prostsze. Wyciąganie repo_dest odbywa się w repo_to_import, a następnie wykonywany jest push --set-upstream url: repo_dest master.

Ta metoda zadziałała, importując kilka mniejszych repozytoriów do większych.

Jak importować: repo1_to_import do 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

Przed importem zmień nazwę lub przenieś pliki i katalogi w wybrane miejsce w oryginalnym repozytorium. na przykład

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

Metoda opisana pod poniższym linkiem zainspirowała tę odpowiedź. Podobało mi się, ponieważ wydawało się to prostsze. Ale strzeż się! Będą smoki! https://help.github.com/articles/importing-an-external-git-repository git push --mirror url:repo_dest wypycha lokalną historię repozytorium i stan do zdalnego (url: repo_dest). ALE to usuwa starą historię i stan pilota. Następuje zabawa! :-MI

W moim przypadku chciałem zaimportować tylko niektóre pliki z innego repozytorium (XXX). Poddrzewo było dla mnie zbyt skomplikowane, a inne rozwiązania nie działały. Oto co zrobiłem:

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

To daje rozdzieloną spacjami listę wszystkich zatwierdzeń, które wpływają na pliki, które chciałem zaimportować (ZZZ) w odwrotnej kolejności (być może trzeba dodać --follow, aby przechwycić także nazwy). Następnie poszedłem do docelowego repozytorium (RRRR), dodałem inne repozytorium (XXX) jako zdalne, wykonałem z niego pobieranie i wreszcie:

git cherry-pick $ALL_COMMITS

który dodaje wszystkie zatwierdzenia do twojego oddziału, będziesz mieć wszystkie pliki z ich historią i możesz robić z nimi, co chcesz, tak jakby zawsze były w tym repozytorium.

Zobacz Podstawowy przykład w tym artykule i rozważ takie mapowanie na repozytoria:

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

Po wszystkich czynnościach opisanych w tym rozdziale (po scaleniu) usuń gałąź B-master:

$ git branch -d B-master

Następnie wciśnij zmiany.

Mi to pasuje.

Byłem w sytuacji, w której szukałem, -s theirsale oczywiście ta strategia nie istnieje. Moja historia była taka, że ​​rozwidliłem projekt na GitHub, a teraz z jakiegoś powodu mój lokalny masternie mógł zostać połączony zupstream/master chociaż nie wprowadziłem żadnych lokalnych zmian w tym oddziale. (Naprawdę nie wiem, co się tam wydarzyło - myślę, że pod prąd zrobił jakieś brudne pchnięcia za kulisami, może?)

Skończyło się na tym, że to zrobiłem

# 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

Więc teraz mój masterjest ponownie zsynchronizowany z upstream/master(i możesz powtórzyć powyższe dla każdego innego oddziału, którego również chcesz zsynchronizować podobnie).

Mogę zaproponować inne rozwiązanie (alternatywa dla git-submodules ) dla twojego problemu - narzędzie gil (git links)

Pozwala opisywać i zarządzać złożonymi zależnościami repozytoriów git.

Zapewnia również rozwiązanie problemu zależności rekurencyjnych podmodułów git .

Rozważ, że masz następujące zależności projektu: przykładowy wykres zależności repozytorium git

Następnie możesz zdefiniować .gitlinksplik z opisem relacji z repozytoriami:

# 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

Każda linia opisuje link do git w następującym formacie:

1. Unikalna nazwa repozytorium
2. Ścieżka względna repozytorium (rozpoczęta od ścieżki pliku .gitlinks)
3. Repozytorium Git, które będzie używane w komendzie git clone Repozytorium oddziału do kasy
4. Pusta linia lub linia rozpoczynająca się od # nie są analizowane (traktowane jako komentarz).

Wreszcie musisz zaktualizować swoje główne repozytorium przykładowe:

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

# The same result with a single command
gil update

W rezultacie sklonujesz wszystkie wymagane projekty i połączysz je ze sobą w odpowiedni sposób.

Jeśli chcesz zatwierdzić wszystkie zmiany w niektórych repozytoriach ze wszystkimi zmianami w podrzędnych repozytoriach połączonych, możesz to zrobić za pomocą jednego polecenia:

gil commit -a -m "Some big update"

Polecenia pull, push działają w podobny sposób:

gil pull
gil push

Narzędzie Gil (git links) obsługuje następujące polecenia:

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

Więcej informacji na temat problemu zależności rekurencyjnych submodułów git .

Pozwól, że użyję nazw a(zamiast XXXi ZZZ) i b(zamiastYYY ), ponieważ dzięki temu opis jest nieco łatwiejszy do odczytania.

Powiedzmy, że chcesz scalić repozytorium ado b(jestem zakładając się znajdują obok siebie):

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

Do tego trzeba git-filter-repozainstalować ( filter-branchjest odradzane ).

Przykład połączenia 2 dużych repozytoriów i umieszczenia jednego z nich w podkatalogu: https://gist.github.com/x-yuri/9890ab1079cf4357d6f269d073fd9731

Więcej na ten temat tutaj .

Nie wiem, jak to łatwo zrobić. Mógłbyś to zrobić:

1. Użyj git filter-branch, aby dodać superkatalog ZZZ w repozytorium XXX
2. Wypchnij nowy oddział do repozytorium YYY
3. Połącz wypchniętą gałąź z pniem YYY.

Mogę edytować ze szczegółami, jeśli brzmi to atrakcyjnie.

Myślę, że możesz to zrobić za pomocą „git mv” i „git pull”.

Jestem uczciwym git noobem - więc uważaj na swoje główne repozytorium - ale właśnie wypróbowałem to w tymczasowym katalogu i wydaje się, że działa.

Po pierwsze - zmień nazwę struktury XXX, aby dopasować ją tak, jak ma wyglądać, gdy jest w YYY:

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

Teraz XXX wygląda następująco:

XXX
 |- ZZZ
     |- ZZZ

Teraz użyj „git pull”, aby pobrać zmiany między:

cd ../YYY
git pull ../XXX

Teraz RRRR wygląda następująco:

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