Введение

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

Хорошее решение в такой ситуации - начать историю проекта заново: собрать один аккуратный Initial commit с текущим состоянием кода и перенести его на новый сервер. Сначала разберем простой алгоритм - пять шагов, которых достаточно в большинстве случаев. А после - уточним важные детали и нюансы, которые стоит знать перед тем, как применять этот способ на реальном проекте.

Простой алгоритм

Перед началом работы откройте терминал и перейдите в корневую папку локального репозитория.

Шаг 1. Создание независимой ветки

Создаем новую независимую (orphan) ветку. Она не тянет за собой историю предыдущих коммитов, позволяя начать с чистого листа. Назовем ее temp-branch:

git checkout --orphan temp-branch

После этой команды вы окажетесь в новой ветке. В ней пока нет ни одной записи в истории, но все файлы остаются на своих местах.

Шаг 2. Индексация файлов и создание коммита

Добавляем все рабочие материалы проекта в индекс Git и фиксируем их первым коммитом:

git add -A
git commit -m "Initial commit"

Теперь у вас есть ветка с единственным коммитом, который содержит актуальное состояние проекта.

Шаг 3. Замена старой ветки на новую

Убираем старую основную ветку (обычно master или main) и переименовываем временную ветку, делая ее главной:

# удаляем старую локальную ветку master
git branch -D master

# переименовываем временную ветку в master
git branch -m master

Шаг 4. Привязка нового сервера

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

Вариант А. Старый сервер больше не нужен, работаем только с новым

Это самый частый случай: вы полностью переезжаете на новый хостинг, а старый репозиторий планируете архивировать или удалить. Тогда просто заменяем адрес, на который указывает origin:

git remote set-url origin <URL_НОВОГО_РЕПОЗИТОРИЯ>

Само имя origin остается прежним - меняется только URL за ним. Проверить результат можно командой:

git remote -v

Вы увидите, что origin теперь указывает на новый адрес и для скачивания (fetch), и для отправки (push). Дальше все команды: git push, git pull - работают как обычно, без каких-либо изменений в синтаксисе, потому что Git по умолчанию обращается именно к origin.

Вариант Б. Старый сервер должен остаться доступным

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

git remote add new-server <URL_НОВОГО_РЕПОЗИТОРИЯ>

Теперь у репозитория два адреса одновременно: старый под именем origin и новый под именем new-server. Проверить это можно той же командой:

git remote -v

В выводе будут обе записи со своими адресами. Обратите внимание на важный нюанс: команда git push без указания имени сервера по-прежнему будет отправлять изменения в origin, то есть на старый сервер. Чтобы отправить коммит именно на новый сервер, имя нужно указывать явно:

git push -u new-server master

Флаг -u в этом случае привязывает вашу локальную ветку master к ветке master на new-server - после этого для последующих отправок туда достаточно будет просто git push, находясь в этой ветке.

Шаг 5. Отправка коммита на новый сервер

Если вы выбрали Вариант А из предыдущего шага, загружаем коммит стандартной командой - она автоматически уйдет на новый сервер, так как origin уже переключен:

git push -u origin master

Если же вы выбрали Вариант Б и добавляли новый сервер под именем new-server, используйте это имя вместо origin - команда та же, что приведена в шаге 4:

git push -u new-server master

Если репозиторий на новом сервере уже создан и там есть автоматические базовые файлы (README.md, .gitignore), Git может предложить сначала объединить изменения. Поскольку задача - заменить содержимое одним новым коммитом, используем принудительную отправку:

git push -f -u origin master

На этом перенос завершен: в новом репозитории лежит аккуратная история из одного коммита с актуальным кодом проекта.

Пояснения и важные детали

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

Когда этот способ действительно оправдан

• Передача проекта заказчику. Вы работали над проектом полгода, использовали внутренние ветки для экспериментов, коммитили черновики и временные решения. Заказчику не нужна эта "внутренняя кухня" - ему нужен рабочий код в аккуратном репозитории с одним понятным коммитом.
• Публикация в open source. В истории коммитов часто остаются следы конфигурационных файлов с внутренними адресами серверов, тестовыми учетными данными или устаревшими API-ключами. Даже если сейчас эти данные удалены из кода, они все равно доступны через git log любому, кто клонирует репозиторий. Обнуление истории - самый надежный способ закрыть эту проблему.
• Смена хостинга с оптимизацией репозитория. Если в истории когда-то были закоммичены большие бинарные файлы (архивы, видео, дампы баз данных), которые впоследствии удалили, файл .git все равно продолжает хранить эти данные. Перенос с чистой историей избавляет от этого балласта.

Если история коммитов важна для аудита изменений или юридических требований - обнулять ее не стоит. Здесь лучше подойдут более точечные инструменты вроде git filter-repo, которые чистят историю выборочно, не удаляя ее целиком.

Что стоит проверить перед началом

• Резервная копия. Скопируйте проект целиком или создайте архив - операция необратима, и лучше иметь возможность вернуться к исходному состоянию.
• Файл .gitignore. Убедитесь, что в него добавлены node_modules, venv, dist и прочие директории со сборочными артефактами - они не должны попасть в новый Initial commit.
• Сабмодули. Если в проекте используются git submodules, при создании orphan-ветки связи с ними могут потребовать переинициализации.
• Незавершенная работа в других ветках. После обнуления истории прочие ветки продолжат указывать на старую историю. Если там есть что-то важное - смержите это в рабочую ветку заранее.

Уточнения к шагу 1: orphan-ветка

Проверить, что переключение прошло успешно, можно командой git status - она покажет, что все файлы проекта отмечены как неотслеживаемые, и это нормально: для Git это действительно первая ветка без единой точки отсчета.

Например, если у проекта были ветки master, feature/payments и feature/auth, после команды появится четвертая ветка temp-branch, полностью изолированная от истории остальных трех. Посмотреть список всех веток можно командой git branch -a.

Уточнения к шагу 2: индексация и коммит

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

После коммита стоит убедиться, что в истории действительно ровно одна запись:

git log --oneline

Если строк больше одной - ветка была создана не как orphan, и стоит вернуться к первому шагу. Если в проекте есть папка вроде logs/ с многолетними файлами отладки, которую забыли добавить в .gitignore, эти файлы попадут в коммит и раздуют размер репозитория с самого начала - проверить состав будущего коммита удобно командой git status до выполнения git add -A.

Уточнения к шагу 3: замена ветки и очистка локального репозитория

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

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

git branch -D feature/payments feature/auth

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

git reflog expire --expire=now --all
git gc --prune=now --aggressive

Оценить размер репозитория до и после очистки можно командой du -sh .git - разница может быть весьма ощутимой, особенно если в истории раньше присутствовали крупные бинарные файлы.

Уточнения к шагу 4: подключение нового сервера

Проверить, что адрес обновился корректно, можно командой git remote -v

Она выведет текущие адреса для чтения (fetch) и записи (push), оба должны указывать на новый сервер.

При переносе, например, с GitLab на GitHub URL обычно меняется с git@gitlab.com:team/project.git на git@github.com:team/project.git. Если используется SSH-доступ, заранее убедитесь, что соответствующий ключ добавлен в настройках нового аккаунта, иначе push завершится ошибкой авторизации.

Уточнения к шагу 5: отправка и force push

Force push перезаписывает историю на удаленном сервере безвозвратно. Если с репозиторием уже работают другие участники команды или от него сделаны форки, их локальные копии разойдутся с сервером, и им потребуется заново клонировать проект. Прежде чем выполнять force push в уже используемый репозиторий, обязательно предупредите всех, кто с ним работает.

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

После отправки проверить результат можно через веб-интерфейс хостинга или командой:

git ls-remote origin

Что еще не переносится автоматически:

• Теги. Ссылаются на старую историю и не переносятся вместе с кодом - их нужно создать заново поверх нового Initial commit командой git tag v1.0.0.
• Настройки CI/CD. Пайплайны, вебхуки и секреты придется настроить заново на новом сервере.
• Права доступа и участники команды. Список коллабораторов и ролей настраивается отдельно на новой платформе.
• Локальные копии у коллег. Даже после чистого переноса у других участников команды могут остаться клоны со старой историей. Лучше явно попросить их удалить старую папку и склонировать проект заново, чем полагаться на git pull.

Заключение

Чему мы сегодня научились:

Работать с независимыми ветками. Флаг --orphan в Git - удобный инструмент, который позволяет создавать ветки без привязки к прежней истории, что отлично помогает при реорганизации репозиториев или подготовке кода к публикации.

Грамотно пересобирать локальную структуру. Мы узнали, как откреплять старые ветки (git branch -D) и переименовывать текущие (git branch -m), а также как полностью очищать .git от следов старой истории с помощью git reflog expire и git gc.

Управлять удаленными репозиториями. Теперь мы умеем не только переназначать адрес сервера через git remote set-url, но и понимаем, когда вместо этого стоит добавить второй сервер через git remote add - и как выбор между ними влияет на поведение git push.

Правильно применять Force Push. Мы закрепили понимание того, когда оправдан флаг -f. Он полезен, когда нужно полностью синхронизировать удаленный сервер с новой локальной историей, но требует предварительного предупреждения команды.

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

Теперь в вашем арсенале есть понятный и надежный алгоритм для комфортного переезда проектов на новые репозитории!