Git Mirror Clone

Коротко: Повна копія репозиторію Git з усіма гілками, тегами та повною історією комітів — а не звичайний checkout для роботи.

Докладніше: git clone --mirror <url> створює «голий» (bare) репозиторій (без робочого каталогу, лише тека .git). Потім git push --mirror <новий-url> переносить повну історію 1:1 у новий цільовий репозиторій. Щоб справді продовжити роботу, після цього все одно потрібен звичайний git clone нового репозиторію — тека-дзеркало лише проміжний крок.

Подробиці

Повна процедура

Повна процедура перенесення репозиторію через дзеркальний клон складається з трьох кроків:

git clone --mirror https://github.com/old-account/projekt.git
cd projekt.git
git push --mirror https://github.com/own-account/emzett.git
git clone https://github.com/own-account/emzett.git

Що конкретно означає «bare-репозиторій»

Звичайний клонований репозиторій складається з двох частин: теки .git (уся історія/метадані) і робочого каталогу (реально видобуті файли, які ви редагуєте). «Bare»-репозиторій, створений із --mirror, складається ЛИШЕ зі вмісту .git, без робочого каталогу — тобто немає видобутих файлів, з якими можна було б працювати напряму. Це навмисно: bare-репозиторій — чистий контейнер даних, призначений як проміжна станція чи ціль для push, а не для прямого редагування. Це також пояснює, чому після дзеркального push усе одно потрібен звичайний git clone нового репозиторію.

Відмінність від звичайного клона + push

Вирішальна відмінність від звичайного git clone + git push: звичайний клон теж отримує повну історію поточної видобутої гілки, але НЕ автоматично всі інші гілки/теги, а звичайний push переносить лише поточну гілку, а не всю мережу посилань. Під час перенесення репозиторію (на відміну від повсякденної роботи) ви, навпаки, справді хочете взяти все 1:1, зокрема гілки, які самі, можливо, ніколи не видобували, — наприклад, старі feature-гілки чи теги минулих релізів, що лишаються важливими для повної історії.

Що НЕ переноситься

Важливий момент, який легко прогледіти під час перенесення репозиторію: дзеркальний клон переносить повну історію Git, але НЕ специфічні для платформи метадані, такі як задачі (issues) GitHub, pull request, вікі-сторінки, релізи (як об’єкти GitHub, а не як теги Git) чи налаштування репозиторію (правила захисту гілок, вебхуки, налаштовані секрети). Усе це живе поза чистою об’єктною моделлю Git у власній базі даних GitHub і під час реального перенесення платформи має бути перенесене чи налаштоване заново окремо.

Автентифікація під час дзеркального push

Оскільки дзеркальний push потенційно переносить дуже багато посилань одразу, він особливо схильний до проблем автентифікації у великих репозиторіїв — прострочений токен чи неправильно налаштоване SSH-з’єднання часто спричиняє помилку лише посеред передавання, що може лишити цільовий репозиторій у неповному проміжному стані. Тому після дзеркального push, перш ніж видаляти чи архівувати старий репозиторій, радять порівняти кількість гілок/тегів у цільовому репозиторії з оригіналом.

Див. також: SSH-ключ (автентифікація Git), Git