Перенос git-репозитория
Как полностью перенести репозиторий a в b ?
Под полностью подразумевается, что должны сохраниться все ветки и все коммиты.
Отслеживать
задан 27 сен 2016 в 18:04
123k 24 24 золотых знака 126 126 серебряных знаков 303 303 бронзовых знака
3 ответа 3
Сортировка: Сброс на вариант по умолчанию
git clone --bare [email protected]:my-repo-a.git git fetch origin git remote add new-origin [email protected]:my-repo-b.git git push --mirror new-origin git remote rm origin git remote rename new-origin origin
Updated: поправил с учётом комментариев
Отслеживать
34k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака
ответ дан 27 сен 2016 в 18:11
Alex Chermenin Alex Chermenin
5,468 15 15 серебряных знаков 36 36 бронзовых знаков
первой командой стоило добавить $ git clone —bare [email protected]:my-pepo-a.git .
27 сен 2016 в 19:35
и вместо двух команд push можно было использовать одну, с опцией —mirror : $ git push —mirror new-origin . она отправит все указатели — и ветки и метки.
27 сен 2016 в 20:02
А для чего нужен bare? // + @alexanderbarakin
28 сен 2016 в 21:11
@Qwertiy, без —bare , помимо копирования содержимого хранилища, из него будет ещё локально распаковано содержимое ветки, являющейся текущей. для решения задачи, оозвученной в вопросе, эта операция (распаковка) не требуется.
28 сен 2016 в 22:21
вроде после первого шага — перед fetch нужно перейти в скаченную директорию
16 сен 2020 в 6:58
если на целевом сервере есть возможность выполнять команды оболочки от имени пользователя, которому принадлежит каталог с хранилищем (в вопросе для иллюстрации указан пользователь git), то можно обойтись без копирования хранилища с исходного сервера на локальный компьютер, а затем на целевой сервер.
-
сделайте текущим каталог с целевым хранилищем:
$ cd /путь/к/my-repo-b.git
$ git remote add --mirror=fetch copy url-исходного-хранилища
$ git remote update copy
всё. при желании можно удалить ссылку на исходное-хранилище:
$ git remote remove copy
если у пользователя, которому принадлежит каталог с хранилищем, не разрешён запуск интерактивной оболочки, но у вас есть возможность выполнять команды от имени пользователя root, перечисленное выше можно сделать и от имени root-а, но по завершении, не меняя текущего каталога, надо установить всем файлам/каталогам такого же владельца и группу, как и у текущего каталога, с помощью, например, такой команды (естественно, от того же имени):
$ chown -R --reference=. .
а если и исходный и целевой сервер — это одна и та же машина, то вместо всего вышеперечисленного можно просто скопировать файлы:
$ cp -a /путь/к/my-repo-a.git/* /путь/к/my-repo-b.git/
Перемещение репозиториев Git в другой проект с точным журналом

Если вы планируете объединить несколько проектов Azure DevOps в один, вам, вероятно, интересно:
- Что делать со всеми репозиториями?
- Переместить или объединить их?
- Сохранить историю или только верхушку айсберга?
Из этой статьи вы узнаете, как переместить репозитории Git в другой проект с полным журналом точности.
Какой сценарий?
Как показано ниже, необходимо переместить репозиторий MigrationDemo из FabrikamOld в новый командный проект Fabrikam.
Разделы справки двигаться?
У вас есть два варианта, как описано ниже. Функции импорта проще, но доступны только в Azure DevOps Services и TFS 2017 с обновлением 1 и более поздних версий.
Использование функции импорта репозитория Git
С помощью функции импорта репозитория можно импортировать репозиторий Git в командный проект из Team Foundation Server (TFS), Azure Repos или любого другого поставщика исходного кода Git, например GitHub. Дополнительные сведения см. в документации по репозиторию импорта .
Вручную перенесите репозиторий Git за пять простых шагов:
Создайте пустой репозиторий Git.
В обозревателе кода щелкните имя репозитория. В списке выберите Новый репозиторий , выберите тип Git и присвойте ему имя.

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

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

Зеркальное отображение репозитория
Перейдите в командную строку разработчика и путь к локальному (исходному) репозиторию для репозитория MigrationDemo в FabrikamOld. git clone —mirror Выполните команду , используя URL-адрес клонирования, приведенный выше.
Командная строка: git clone —mirror https://demo-fabrikam.visualstudio.com/DefaultCollection/Fabrikam/_git/MigrationDemo
Как показано, clone —mirror в этом случае является избыточным, так как удаленный репозиторий является голым. Он используется здесь как безопасный и простой способ настройки пульта дистанционного управления.

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

Параметр —mirror используется как с командой клонирования, так и с командой push. Параметр гарантирует, что все ветви и другие атрибуты будут реплицированы в новом репозитории.
Проверка нового репозитория
Перейдите на веб-портал Azure DevOps и проверьте новый репозиторий и журнал в центре КОДА .

Убедитесь, что все ветви перемещены в новый репозиторий.
Настройка нового репозитория
Убедитесь, что разрешения и политики правильно настроены для нового репозитория. Вы можете настроить безопасность после шага 1 или на этом этапе. Перенастройте сборки для подключения к новому репозиторию. Наконец, уведомите пользователей исходного репозитория об обновлении удаленных репозиторий в Visual Studio или выполните git remote set-url origin команду .
> git remote set-url origin https://demo-fabrikam.visualstudio.com/DefaultCollection/Fabrikam/_git/MigrationDemo
Не забудьте очистить исходный проект, удалив репозиторий (будьте осторожны, отмена не выполняется) или блокировка ветвей, чтобы никто случайно не обновлял его.
(c) Корпорация Майкрософт за 2016 г. Все права защищены. Этот документ предоставляется «как есть». Информация и мнения, выраженные в этом документе, включая URL-адреса и другие ссылки на веб-сайты Интернета, могут изменяться без предварительного уведомления. Вы принимаете на себя весь риск, связанный с его использованием.
Этот документ не предоставляет вам каких-либо юридических прав интеллектуальной собственности на какие-либо продукты Майкрософт. Вы можете копировать и использовать настоящий документ для внутреннего использования и в справочных целях.
Перенос git репозитория
Небольшой набор команд для переноса одного git репозитория в другой. Я, например, пользовался при переносе из Github в Gitlab.
git clone --bare git@git.test.com:my-repo-a.git cd my-repo-a.git git fetch origin git remote add new-origin git@git.test.com:my-repo-b.git git push --mirror new-origin git remote rm origin git remote rename new-origin origin
Давай разберем команды:
git clone —bare — клонируем не сам репозиторий, а директорию .git
git fetch origin — убеждаемся, что у нас все изменения присутствуют
git remote add — добавляем новый remote репозиторий
git push —mirror new-origin — загружаем весь наш репозиторий в новый. mirror передает все refs — тэги, бранчи
git remote rm — удаляем старый origin локально
git remote rename — переименовываем new-origin в origin, чтобы было проще работать
Как переместить локальный репозиторий git
Запись: xintrea/mytetra_db_armagedec/master/base/1481567592x5vf9ygodr/text.html на raw.githubusercontent.com
Разработка с применением GIT обычно начинается с того, что вначале программист держит локальный GIT репозитарий на своей рабочей машине, и ежедневно коммитит в него. Но наступает момент, когда нужно перенести репозитарий на сервер для совместной работы или синхронизации с разных компьютеров. Перенести нужно вместе со всей историей коммитов. В этой статье написано как это сделать.
Итак, предположим, что у нас создан на GitHub.com или на BitBucket.org новый репозитарий. URL этого репозитария пусть будет следующим:
Находясь в рабочей директории даем две команды:
$ git remote add server https://username@bitbucket.org/username/funnyproject.git
$ git push server master:master
Первой командой мы добавили в настройки репозитария URL сервера. Второй командой залили на сервер полную копию локального GIT репозитария основной ветки.
Далее предполагается, что теперь при выполнении команд push и pull , GIT должен работать с вышеуказанным сервером. Другими словами, сервер должен быть установлен по-умолчанию. Для этого обязательно нужно дать команду:
$ git config remote.origin.url https://username@bitbucket.org/username/funnyproject.git
После которой git push и git pull будут по-умолчанию работать с сервером. Если этого не сделать, при push будет ошибка:
fatal: No destination configured to push to.
А при pull тоже будет похожая ошибка:
fatal: No remote repository specified. Please, specify either a URL or a
remote name from which new revisions should be fetched.
Так что устанавливайте значение конфигурационной переменной remote.origin.url в URL сервера, как это показано выше. Или можно воспользоваться следующей командой:
git remote set-url origin https://username@bitbucket.org/username/funnyproject.git
Узнать, какие настройки сделаны в текущем GIT репозитарии можно с помощью команды:
$ git config —list
Ну вот впринципе и все. Напомню, на всякий случай, набор команд чтобы закоммитить изменения и отправить на сервер:
$ git add .
$ git commit -a
$ git push
А перед началом работы теперь нужно синхронизироваться с сервером с помощью команды:
Надеюсь, этот рецепт поможет вам сберечь часы, потраченные на раскопки в документации.
- Первичная настройка Git (First Time Git Setup)
- Удаление remote branch
- Шпаргалка по командам
- Формат pretty
- Как смержить изменения с experimental в master
- Как переключится на нужный коммит
- Понимание работы merge
- Как просмортеть изменения внесенные определенным коммитом
- Как посмотреть историю изменения конкретного файла
- Как вернуть один файл в состояние, которое было в определенном коммите
- Как узнать текущую ветку
- Как внести изменения в последний коммит
- Как подключить новую ветку с сервера
- Как исправить HEAD detached from
- Как испарвить ошибочный комментарий к коммиту
- Как создать новую ветку в условиях, когда произошли изменения после последнего коммита
- Как залить локальную ветку на удаленный репозиторий
- Ежедневный git
- Команда stash
- Как посмотреть настройки репозитория
- Как перенести локальный репозиторий на сервер
- Команда reset, откат
- Команда revert
- Работа с ветками
- Команда rebase
- Особенности log при навигации по истории с помощью checkout
- Разница между pull и fetch
- Удачная модель ветвления
- Использование proxy
- Использование различных SSH ключей
- Очистка индекса
