Как удалить старые коммиты в Git и начать с чистой истории

Кратко

• Если нужно удалить всю историю репозитория до определённого коммита (например, чтобы убрать чувствительные данные или начать с чистой истории), можно создать «orphan» ветку, переместить нужные коммиты и затем принудительно запушить изменения. Этот процесс изменяет историю — предупредите коллег и сделайте бэкап.

Быстрые ссылки

• Зачем удалять старые коммиты?

• Как удалить все коммиты до выбранного коммита

Зачем удалять старые коммиты Git

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

Типичные причины:

• Репозиторий использовался как шаблон и содержит старые правки, которые не нужны в новом проекте.
• В истории случайно оказались секреты (ключи, пароли, токены), которые нужно полностью удалить.
• Желание уменьшить размер репозитория, удалив устаревшие крупные бинарные файлы.

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

Как удалить все коммиты до выбранного коммита

Шаг 1. Найдите SHA-1 (идентификатор) коммита, после которого вы хотите сохранить историю. Это можно сделать в GUI (GitHub, GitKraken и т. п.) или через терминал:

git log

Шаг 2. Создайте «orphan» ветку на основе нужного коммита. Orphan-ветка — это ветка без предков: её HEAD не ссылается на существующие коммиты до указанной точки.

git checkout --orphan orphan-branch ee96691d2785da4bbbbb058382d41e0ccf2a7e7b

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

Шаг 3. Зафиксируйте текущее состояние как новый первый коммит в orphan-ветке:

git add -A

git commit -m "Truncated history"

Шаг 4. Теперь нужно переместить оставшиеся коммиты (те, что идут после точки отсечения) поверх новой orphan-ветки и обновить метку ветки master. Выполните rebase с опцией –onto:

git rebase --onto orphan-branch ee96691d2785da4bbbbb058382d41e0ccf2a7e7b master

Эта команда переместит все коммиты, следующие за указанным SHA, на вершину orphan-ветки, а затем обновит указатель ветки master на новую последовательность.

Шаг 5. Убедитесь, что история выглядит как нужно. Если всё в порядке, удалите временную orphan-ветку и выполните сборку мусора для очистки старых объектов:

git branch -D orphan-branch

git prune --progress

git gc --aggressive

Шаг 6. Если репозиторий связан с удалённым (remote), потребуется принудительная публикация, чтобы заменить историю на удалённом сервере:

git push --force

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

Практические рекомендации и предупреждения

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

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

• Если множество разработчиков работают с репозиторием и синхронизируются регулярно. В таких случаях изменение истории создаст дополнительную работу для команды.
• Если цель — откат отдельного коммита без удаления всей истории — лучше использовать git revert.

Альтернативные подходы

• git revert: создаёт новый коммит, отменяющий изменения целевого коммита, без переписывания истории. Подходит для публичных репозиториев.
• git filter-repo / BFG Repo-Cleaner: инструменты для массового удаления файлов/паттернов из истории (полезно при удалении секретов). Требуют аккуратности и тестирования.
• Создать новый репозиторий и вручную перенести только нужные файлы и настройки.

Когда переписывание истории полезно

• Удаление чувствительных данных, которые появились в ранних коммитах.
• Подготовка репозитория как шаблона без истории предыдущих проектов.
• Сокращение размера истории при наличии больших удалённых файлов.

Контрпримеры и случаи, когда это не сработает

• Если секреты были опубликованы в клонах/форках третьих сторон, удаление в основном репозитории не устранит их в чужих копиях.
• Если история интегрирована в CI/CD, ссылки на старые коммиты в артефактах могут сломаться.

Пошаговый чеклист (роли и действия)

Для владельца репозитория (администратор):

• Сохранить резервную копию репозитория (клонировать в отдельную папку).
• Сообщить всем участникам о намерении переписать историю и согласовать время работ.
• Выполнить операцию на локальном клоне и проверить результат.
• Выполнить git push –force и проверить CI-пайплайны.

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

• Сделать бэкап незакоммиченных изменений (git stash или патч).
• После уведомления переклонировать репозиторий или выполнить ресинхронизацию по инструкции владельца.

Плейбук: быстрый SOP для очис́тки истории

1. Создать резервную копию: git clone –mirror backup-repo
2. Найти SHA коммита-источника: git log –oneline
3. Создать orphan-ветку: git checkout –orphan orphan-branch
4. Добавить и закоммитить: git add -A && git commit -m “Truncated history”
5. Перебазировать master: git rebase –onto orphan-branch master
6. Удалить временную ветку: git branch -D orphan-branch
7. Очистить объекты: git prune –progress && git gc –aggressive
8. Принудительно запушить: git push –force

Критерии приёмки

• В локальном репозитории нет ссылок на нежелательные коммиты (проверить git log).
• В удалённом репозитории после force-push история соответствует ожиданиям.
• Все разработчики получили инструкции по синхронизации.

Критические риски и способы их смягчения

Риски:

• Потеря данных при ошибочном удалении нужных коммитов.
• Конфликты и рассинхронизация у разработчиков.
• Остатки чувствительных данных в закэшированных копиях или форках.

Митигаторы:

• Всегда делать полную резервную копию (git clone –mirror).
• Тестировать процесс на отдельной копии перед применением к основному репозиторию.
• Сообщить всем участникам и предоставить инструкции по обновлению локальных копий.

Удаление чувствительных данных: дополнительные заметки о конфиденциальности

Если причина очистки — удаление секретов, используйте специализированные инструменты (git filter-repo или BFG) и последовательно проверяйте следующие места:

• Все ветки и теги
• Форки и публичные зеркала
• CI/CD системы и кеши артефактов

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

Набор тестов и критерии успешности

• Проверка содержимого git log: старые коммиты до контрольной точки отсутствуют.
• Проверка SHA-1: новый «первый» коммит имеет ожидаемую метку.
• Запуск CI: сборки проходят с новой историей.
• Восстановление из резервной копии: если требуется, можно вернуть старый репозиторий.

Мини-словник (1 строка)

• Orphan-ветка — ветка без родительских коммитов; используется для создания новой истории.
• Force-push — принудительная отправка, которая перезаписывает историю удалённого репозитория.
• Rebase –onto — перемещает набор коммитов на новую базу.

Итоги

• Удаление старой истории в Git возможно и полезно в отдельных сценариях (удаление секретов, подготовка шаблона).
• Процесс включает создание orphan-ветки, реорганизацию коммитов через rebase и принудительную отправку на remote.
• Всегда делайте резервную копию и заранее уведомляйте коллег.

Важно: переписывание публичной истории — действие с последствиями. Планируйте и коммуницируйте заранее.