Как импортировать существующий репозиторий Git в другой?

Ответ 1

Вероятно, самым простым способом было бы перетащить материал XXX в ветку в YYY, а затем объединить его с master:

В ГГГГ:

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

Я на самом деле только что попробовал это с парой моих репозиториев, и это работает. В отличие от ответа Йорг, он не позволит вам продолжать использовать другой репозиторий, но я не думаю, что вы все равно это указали.

Примечание: так как это было изначально написано в 2009 году, git добавил слияние поддеревьев, упомянутое в ответе ниже. Я бы, вероятно, использовал этот метод сегодня, хотя, конечно, этот метод все еще работает.

Ответ 2

Если вы хотите сохранить точную историю коммитов второго репозитория и, следовательно, также сохранить возможность легко объединять восходящие изменения в будущем, то вот метод, который вам нужен. Это приводит к тому, что в ваше хранилище импортируется немодифицированная история поддерева плюс один коммит слияния для перемещения объединенного репозитория в подкаталог.

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

Вы можете отслеживать восходящие изменения следующим образом:

git pull -s subtree XXX_remote master

Git самостоятельно выясняет, где находятся корни, прежде чем выполнять слияние, поэтому вам не нужно указывать префикс при последующих слияниях.

Git версии до 2.9: вам не нужно передавать опцию --allow-unrelated-histories в git merge.

Метод в другом ответе, который использует read-tree и пропускает шаг merge -s ours, практически ничем не отличается от копирования файлов с помощью cp и фиксации результата.

Первоначальный источник был из справочной статьи github "Слияние поддеревьев".

Ответ 3

git-subtree - это script, предназначенный именно для этого случая слияния нескольких репозиториев в один, сохраняя историю (и/или разбивая историю поддеревьев, хотя это, по-видимому, не имеет отношения к этому вопросу). Он распространяется как часть дерева git начиная с версии 1.7.11.

Чтобы объединить репозиторий <repo> в редакции <rev> в качестве подкаталога <prefix>, используйте git subtree add следующим образом:

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

git -subtree реализует стратегию слияния поддерева более удобным образом.

Для вашего случая, внутри репозитория YYY, вы будете запускать:

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

Ответ 4

Существует известный пример этого в самом хранилище Git, который коллективно известен в сообществе Git как " самое крутое слияние когда-либо" (после того, как тема темы Линус Торвальдс использовал в электронном письме в почтовом списке Git, который описывает это слияние). В этом случае графический интерфейс gitk Git, который теперь является частью Git надлежащим образом, фактически использовался как отдельный проект. Линусу удалось объединить этот репозиторий в репозиторий Git таким образом, чтобы

• он появляется в репозитории Git, как будто он всегда был разработан как часть Git,
• вся история сохраняется неповрежденной и
• он все равно может быть разработан независимо в своем старом репозитории, причем изменения просто выполняются git pull ed.

В электронном письме содержатся шаги, необходимые для воспроизведения, но это не для слабонервных: во-первых, Линус написал Git, поэтому он, вероятно, знает об этом немного больше, чем вы или я, а во-вторых, это было почти 5 лет назад, а Git значительно улучшилось с тех пор, поэтому, возможно, сейчас намного проще.

В частности, я предполагаю, что в настоящее время в этом конкретном случае будет использоваться подмодуль gitk.

Ответ 5

Простым способом сделать это является использование git format-patch.

Предположим, что у нас есть 2 git репозитории foo и бар.

foo содержит:

• foo.txt
• .git

bar содержит:

• bar.txt
• .git

и мы хотим закончить с помощью foo, содержащей историю bar, и эти файлы:

• foo.txt
• .git
• Foobar/bar.txt

Итак, чтобы сделать это:

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

И если мы хотим переписать все сообщения из бара, мы можем сделать, например, в Linux:

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

Это добавит "[bar]" в начале каждого сообщения фиксации.

Ответ 6

Основанный на в этой статье, использование поддерева - это то, что сработало для меня, и была перенесена только применимая история. Проводка здесь, если кому-то понадобятся этапы (обязательно замените заполнители соответствующими значениями):

в вашей исходной папке с разделом в новую ветвь

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

в вашем целевом репо слиянии в ветке с разделенным результатом

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

проверьте свои изменения и зафиксируйте

git status
git commit

Не забывайте

Очистите, удалив ветвь subtree-split-result

git branch -D subtree-split-result

Удалите удаленный файл, добавленный для извлечения данных из исходного репо

git remote rm merge-source-repo

Ответ 7

Эта функция будет клонировать удаленное репо в локальный репозиторий, после того как слияние всех коммитов будет сохранено, git log будет показывать оригинальные коммиты и правильные пути:

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

Как использовать:

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

Если вы делаете небольшие изменения, вы даже можете перемещать файлы/директории объединенного репо на разные пути, например:

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"

Уведомления
Пути заменяются с помощью sed, поэтому следите за тем, чтобы они перемещались по правильному пути после слияния.
Параметр --allow-unrelated-histories существует только с git >= 2.9.

Ответ 8

Добавление другого ответа, поскольку я думаю, что это немного проще. Потяните repo_dest в repo_to_import, а затем выполним команду push -set-upstream url: repo_dest.

Этот метод помог мне импортировать несколько небольших репозиториев в более крупный.

Как импортировать: 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

Переименуйте или переместите файлы и директории в нужную позицию в исходном репо перед импортом. например

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

Метод, описанный в следующей ссылке, вдохновил этот ответ. Мне понравилось, потому что это казалось более простым. НО Осторожно! Там будут драконы! https://help.github.com/articles/importing-an-external-git-repository git push --mirror url:repo_dest толкает вашу локальную историю репо и состояние на удаленный (url: repo_dest). НО удаляет старую историю и состояние пульта. Забавно!: -E

Ответ 9

Я хотел импортировать только некоторые файлы из другого репозитория (XXX) в моем случае. Поддерево было слишком сложным для меня, а другие решения не работали. Это то, что я сделал:

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

Это дает список разделенных пробелами всех коммитов, которые влияют на файлы, которые я хотел импортировать (ZZZ), в обратном порядке (возможно, вам придется добавить --follow, чтобы также перехватывать переименования). Затем я попал в целевой репозиторий (YYY), добавил другой репозиторий (XXX) как удаленный, сделал выборку и наконец:

git cherry-pick $ALL_COMMITS

который добавляет все коммиты в вашу ветку, вы, таким образом, будете иметь все файлы со своей историей и можете делать с ними все, что хотите, как если бы они всегда были в этом репозитории.

Ответ 10

Я был в ситуации, когда искал -s theirs, но, конечно, этой стратегии не существует. Моя история заключалась в том, что я разветкил проект на GitHub, и теперь по какой-то причине мой локальный master не мог быть объединен с upstream/master, хотя я не внес никаких локальных изменений в эту ветку. (На самом деле не знаю, что там произошло - думаю, вверх по течению сделали некоторые грязные толчки за кулисами, может быть?)

То, что я закончил, было

# 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

Итак, теперь мой master снова синхронизируется с upstream/master (и вы можете повторить выше для любой другой ветки, которую вы также хотите синхронизировать аналогично).

Ответ 11

См. Основной пример в в этой статье и рассмотрите такое отображение в репозиториях:

• A ↔ YYY,
• B ↔ XXX

После всей операции, описанной в этой главе (после слияния), удалите ветвь B-master:

$ git branch -d B-master

Затем нажмите изменения.

Это работает для меня.

Ответ 12

Я могу предложить другое решение (альтернатива git-submodules) для вашей проблемы - gil (git links) инструмент

Это позволяет описывать и управлять сложными зависимостями git-репозиториев.

Кроме того, он обеспечивает решение проблемы зависимости git-рекурсивных субмодулей.

Предположим, у вас есть следующие зависимости проекта: пример графика зависимости git-репозитория

Затем вы можете определить файл .gitlinks с описанием отношений с репозиториями:

# 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

Каждая строка описывает git ссылку в следующем формате:

1. Уникальное имя хранилища
2. Относительный путь к хранилищу (начинается с пути файла .gitlinks)
3. Git-репозиторий, который будет использоваться в команде git clone Репозиторий ветвь для оформления заказа
4. Пустая строка или строка, начинающаяся С#, не анализируется (рассматривается как комментарий).

Наконец, вам необходимо обновить корневой репозиторий с примерами:

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

# The same result with a single command
gil update

В результате вы клонируете все необходимые проекты и правильно связываете их друг с другом.

Если вы хотите зафиксировать все изменения в каком-либо репозитории со всеми изменениями в дочерних связанных репозиториях, вы можете сделать это с помощью одной команды:

gil commit -a -m "Some big update"

Команды Pull, Push работают аналогичным образом:

gil pull
gil push

Gil (git links) поддерживает следующие команды:

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

Подробнее о проблеме зависимости git рекурсивных подмодулей.

Ответ 13

Я не знаю, как это сделать. Вы МОЖЕТЕ сделать это:

• Использовать ветвь фильтра git для добавления супер-каталога ZZZ в репозиторий XXX
• Нажмите новую ветку в репозиторий YYY
• Объединить нажатую ветку с соединительной магистрали YYY.

Я могу редактировать детали, если это звучит привлекательно.

Ответ 14

Я думаю, вы можете сделать это, используя 'git mv' и 'git pull'.

Я честный git noob - так что будьте осторожны с вашим основным репозиторием - но я просто попробовал это во временном каталоге и, похоже, работал.

Сначала - переименуйте структуру XXX в соответствии с тем, как вы хотите, чтобы она выглядела, когда она находится в пределах YYY:

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

Теперь XXX выглядит следующим образом:

XXX
 |- ZZZ
     |- ZZZ

Теперь используйте 'git pull', чтобы получить изменения:

cd ../YYY
git pull ../XXX

Теперь YYY выглядит так:

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