git перенос репозитория с сохранением истории

Перемещение содержимого репозитория Git в другой репозиторий с сохранением истории

Я пытаюсь переместить только содержимое одного репозитория ( repo1 ) в другой существующий репозиторий ( repo2 ) с помощью следующих команд:

Но это не работает. Я просмотрел аналогичный пост, но нашел только одно перемещение папки, а не содержимое.

Я думаю, что команды, которые вы ищете:

Сначала мы должны извлечь все удаленные ветви и теги из существующего репозитория в наш локальный индекс:

Мы можем проверить все недостающие ветви, которые нам нужны для создания локальной копии:

Давайте используем SSH-клонированный URL нашего нового репозитория, чтобы создать новый удаленный в нашем существующем локальном репозитории:

Теперь мы готовы отправить все локальные ветви и теги на новый пульт с именем new-origin:

Давайте сделаем new-origin удаленным по умолчанию:

Переименуйте new-origin только в origin, чтобы он стал удаленным по умолчанию:

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

Теперь предположим, что вы хотите синхронизировать исходные и конечные репозитории в течение определенного периода времени. Например, в текущем удаленном репо все еще есть активность, которую вы хотите перенести в новое / замененное репо.

Чтобы получить последние обновления (при условии, что у вас нет локальных изменений):

NB: Я еще не использовал субмодули, поэтому я не знаю, какие дополнительные шаги могут потребоваться, если они у вас есть.

Самый простой подход, если Git уже отслеживает код, а затем установить новый репозиторий в качестве «источника», на который нужно нажать.

Источник

Перенос git-репозитория

Есть некоторый репозиторий с ветками master и develop :

Есть также пустой репозиторий

3 ответа 3

Updated: поправил с учётом комментариев

если на целевом сервере есть возможность выполнять команды оболочки от имени пользователя, которому принадлежит каталог с хранилищем (в вопросе для иллюстрации указан пользователь git), то можно обойтись без копирования хранилища с исходного сервера на локальный компьютер, а затем на целевой сервер.

сделайте текущим каталог с целевым хранилищем:

от имени пользователя, которому принадлежит этот каталог, подключите исходное хранилище под каким-нибудь именем, например, copy :

всё. при желании можно удалить ссылку на исходное-хранилище:

если у пользователя, которому принадлежит каталог с хранилищем, не разрешён запуск интерактивной оболочки, но у вас есть возможность выполнять команды от имени пользователя root, перечисленное выше можно сделать и от имени root-а, но по завершении, не меняя текущего каталога, надо установить всем файлам/каталогам такого же владельца и группу, как и у текущего каталога, с помощью, например, такой команды (естественно, от того же имени):

а если и исходный и целевой сервер — это одна и та же машина, то вместо всего вышеперечисленного можно просто скопировать файлы:

Источник

Выделение подпроекта в отдельный репозиторий на github

Недавно я столкнулся с задачей переноса папки с проектом из одного репозитория в другой на github. Звучит примитивно, но если рассмотреть то, что дано и то, что необходимо получить, могут возникнуть некоторые нюансы.

Что необходимо сделать:

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

Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:

В этом посте я хочу немного адаптировать процесс для лучшего восприятия.

Готово! Теперь в вашем новом репозитории есть только интересующая вас папка вместе со всей историей коммитов. Например, сразу после вышеописанных шагов я увидел следующее в своем новом репозитории:

Если вам нужно перенести все 50 (60? 100?) бранчей, то данное решение не будет удачным из-за слишком большого количества рутинной работы. Но я считаю, что для переноса достаточно лишь сохранить master и dev бранчи, потому что все feature branches уже должны быть в dev, а новые бранчи вы будете ветвить уже в новом репозитории.

UPDATE

Ну, а если new-repo является совсем свежим и не содержит даже readme файла – другими словами, вообще не содержит файлов, то все еще проще:

Источник

Как перемещать файлы из одного репозитория git в другой (не клон), сохраняя историю

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

но это кажется довольно запутанным. Есть ли лучший способ сделать что-то в этом роде? Или я выбрал правильный подход?

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

12 ответов

Если ваша история вменяема, вы можете взять коммиты как патч и применить их в новом репозитории:

или в одной строке

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

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

этап Один

сделайте копию репозитория A, так как следующие шаги делают major изменения в этой копии, которые вы не должны нажимать!

(предполагая, что myprojects-это репозиторий, из которого вы хотите скопировать)

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

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

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

например. FILE_TO_KEEP = ПФЛ.xml, чтобы сохранить только pom.xml-файл из FOLDER_TO_KEEP

Второй Этап

вы можете импортировать эти файлы в репозиторий B в каталоге, не являющемся корневым:

сделать это каталог

переместить файлы в этот каталог

добавить файлы в этот каталог

сохранить изменения и мы готовы объединить эти файлы в новый репозиторий

Третий Этап

сделайте копию репозитория B, если у вас его еще нет

(предполагая, что FOLDER_TO_KEEP-это имя нового репозитория, в который вы копируете)

создайте удаленное соединение с репозиторием A как ветвь в репозитории Б

Pull из этой ветви (содержащей только каталог, который вы хотите переместить) в репозиторий Б.

The pull копирует как файлы, так и историю. Примечание: Вы можете использовать слияние вместо вытягивания, но вытягивание работает лучше.

наконец, вы, вероятно, хотите немного очистить, удалив пульт подключение к хранилищу

нажимаем и все готово.

нашел этой очень полезно. Это очень простой подход, когда вы создаете патчи, которые применяются к новому РЕПО. См. связанную страницу для получения дополнительной информации.

Он содержит только три шага (скопировано из блога):

единственная проблема у меня было, что я не мог применить все патчи сразу, используя

под Windows я получил ошибку InvalidArgument. Поэтому мне пришлось накладывать все пластыри один за другим.

СОХРАНЕНИЕ ИМЕНИ КАТАЛОГА

подкаталог-фильтр (или более короткая команда git subtree) работает хорошо, но не работает для меня, так как они удаляют имя каталога из информации фиксации. В моем сценарии я просто хочу объединить части одного репозитория в другой и сохранить историю с полным именем пути.

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

этот ответ предоставляет интересные команды, основанные на git am и представлены с использованием примеров, шаг за шагом.

процедура

1. Извлечение истории в формате электронной почты

очистить временный каталог назначения

очистите ваше РЕПО источник

извлечь историю каждого файла в формате электронной почты

после: временная история в формате электронной почты

2. Реорганизовать дерево файлов и обновить изменение имени файла в истории [необязательно]

Предположим, вы хотите переместить эти три файла в другое РЕПО (может быть то же самое РЕПО).

поэтому реорганизуйте свои файлы:

ваша временная история теперь:

изменить также имена в истории:

Примечание: эта переписывает историю, чтобы отразить изменение пути и имени файла.
(т. е. изменение нового местоположения / имени в новом РЕПО)

3. Применить новую историю

применить фиксации из временных файлов истории:

ваш другой РЕПО теперь:

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

дополнительный трюк: обнаружение переименованных / перемещенных файлов в вашем РЕПО

чтобы перечислить переименованные файлы:

имея подобный зуд, чтобы поцарапать (altough только для некоторых файлов данного репозитория), этот скрипт оказался действительно полезным:git-import

которые затем применяются к новому репозиторию:

для подробной информации, пожалуйста, посмотрите:

для соответствия стандартам stackoverflow, вот процедура:

используя воодушевленность от http://blog.neutrino.es/2012/git-copy-a-file-or-directory-from-another-repository-preserving-history/, я создал эту функцию Powershell для того же самого, которая отлично работала для меня до сих пор:

использование для этого примера:

после того как вы сделали это, вы можете повторно организовать файлы migrate-from-project2 ветвь перед слиянием.

Я хотел что-то надежное и многоразовое (функция one-command-and-go + undo), поэтому я написал следующий сценарий bash. Работал на меня несколько раз, поэтому я решил поделиться им здесь.

он может перемещать произвольную папку /path/to/foo С repo1 на /some/other/folder/bar to repo2 (пути к папкам могут быть одинаковыми или различными, расстояние от корневой папки может отличаться).

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

поскольку это создает осиротевшую ветвь со всей историей старого РЕПО, а затем объединяет ее с главой, она даже будет работать в случае столкновения имен файлов (тогда вам придется разрешить слияние в конце, конечно).

если нет конфликтов имен файлов, вам просто нужно git commit в конце, чтобы завершить объединить.

недостатком является то, что он, скорее всего, не будет следовать переименованиям файлов (за пределами REWRITE_FROM папка) в исходном repo-pull запросы приветствуются на GitHub для размещения для этого.

в моем случае мне не нужно было сохранять РЕПО, из которого я мигрировал, или сохранять любую предыдущую историю. У меня был клочок той же самой ветки, из другого удаленного

на этих двух шагах я смог заставить ветку другого РЕПО появиться в том же РЕПО.

наконец, я установил эту ветвь (которую я импортировал из другого репо), чтобы следовать основной линии целевого репо (чтобы я мог точно различать их)

теперь он вел себя так, как-если бы это было просто еще одна ветка, которую я толкнул против того же РЕПО.

Источник

Перемещение репозиториев Git в другой проект с подробным журналом

если вы планируете объединить несколько Azure DevOps проектов в одну, вы, скорее всего, заинтересовались:

В этой статье вы узнаете, как переместить репозитории Git в другой проект с подробным журналом.

Что такое сценарий?

Как показано ниже, необходимо переместить репозиторий Мигратиондемо из Фабрикамолд в новый командный проект Fabrikam.

Разделы справки переместить?

Вы можете использовать два варианта, как описано ниже. функции импорта проще, но доступны только в Azure DevOps Services и TFS 2017 с обновлением 1 и более поздних версий.

Использование функции импорта Git в репозитории

Вручную перенесите репозиторий Git за пять простых шагов:

Создайте пустой репозиторий Git.

После создания репозитория вы получите пошаговые инструкции для быстрого начала работы. Скопируйте в Clone URL буфер обмена.

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

Зеркальное отображение репозитория

Отправить репозиторий

Выполните git push команду, чтобы передать локальные изменения в удаленный (целевой) репозиторий.

—mirror Параметр используется вместе с командой Clone и Push. Параметр обеспечивает репликацию всех ветвей и других атрибутов в новом репозитории.

Проверка нового репозитория

Убедитесь, что все ветви перемещены в новый репозиторий.

Настройка нового репозитория

Проверьте, правильно ли настроены разрешения и политики для нового репозитория. Параметры безопасности можно настроить после шага 1 или на этом этапе. Перенастройте сборки для подключения к новому репозиторию. наконец, уведомлять пользователей исходного репозитория о необходимости обновления удаленных элементов в Visual Studio или выполнении git remote set-url origin команды.

Не забывайте очищать исходный проект путем удаления репозитория (Будьте внимательны, нет отмены) или блокировки ветвей, чтобы никто случайно не обновлял его.

Подробные сведения о планировании коллекций командных проектов и командных проектов см. в руководстве по планированию, аварийному устранению проблем и восстановлению TFS в Azure IaaS.

(c) корпорация Майкрософт (Microsoft Corporation), 2016. Все права защищены. Этот документ предоставляется «как есть». Сведения и представления, представленные в этом документе, включая URL-адреса и другие ссылки на веб-сайты, могут измениться без предварительного уведомления. Вы несете ответственность за его использование.

Этот документ не предоставляет никаких юридических прав на интеллектуальную собственность в продуктах Майкрософт. Вы можете копировать и использовать этот документ для внутренних справочных целей.

Источник