Переписывание истории

Переписывание истории в Git — это процесс создания новых коммитов для замены старых. Это полезно для исправления ошибок или улучшения структуры истории, но требует осторожности, чтобы не сломать ветки других разработчиков. Инструментарий для переписывания истории включает git commit --amend, git rebase -i и git filter-repo. Правило номер один: никогда не переписывайте распространённые коммиты, которые уже были отправлены другим разработчикам.

Как это работает

Переписывание истории в Git осуществляется с помощью различных команд. Например, git commit --amend позволяет изменить последний коммит, добавив или убрав изменения. Команда git rebase -i позволяет интерактивно squash, reword, edit или drop коммиты, что помогает улучшить структуру истории. Для массовых операций, таких как удаление утечек секретной информации, используется git filter-repo или устаревший git filter-branch.

Визуализация истории коммитов может быть выполнена с помощью команды git log --oneline --graph --all, которая отображает ветвление и слияние коммитов в графическом виде. Команда git blame <file> позволяет определить, кто последний раз изменял каждую строку в файле. git bisect автоматизирует бинарный поиск по коммитам, чтобы найти конкретный коммит, который внес изменения, вызывающие баг.

Когда применять

Переписывание истории применяется в различных ситуациях. Например, команда git cherry-pick <sha> позволяет применить конкретный коммит к текущей ветке, создавая новый коммит с тем же изменением. Это полезно для backport фиксов с основной ветки на ветку релиза. Команда git bisect используется, когда известно, что "работало на коммите X, сломано на Y". Она находит breaking коммит за логарифмическое количество шагов, что значительно ускоряет процесс поиска проблемы. Команда git blame используется для нахождения PR, который внёс конкретную строку кода, после чего можно прочитать описание PR для контекста.

Типичные ошибки

Типичные ошибки при переписывании истории включают cherry-pick и последующее merge, что приводит к дублированию изменений в истории. Также если используется git bisect, но не указаны четкие "good" и "bad" границы, результат может быть непредсказуемым. Другой распространённой ошибкой является использование git blame на коммит, который содержит рефакторинг, вместо коммита, который содержит оригинальную вставку. В таких случаях следует использовать команду git log --follow <file> для определения перемещённых файлов.

Связанные понятия

• Cherry-pick и история
• Cherry-picking коммитов