Что такое squash коммитов?

Squash коммитов — это техника в системе контроля версий Git, предназначенная для очистки истории проекта. Она позволяет объединить несколько коммитов в один, сохраняя все изменения, но представляя их как единый логический блок работы.

Зачем нужен squash?

В процессе разработки программисты часто создают множество мелких коммитов: "исправил опечатку", "добавил проверку", "отрефакторил". Для локальной работы это удобно, но при слиянии в основную ветку такая детализация засоряет историю, затрудняя её чтение и анализ. Squash решает эту проблему, группируя все изменения, связанные с одной задачей или фичей, в один осмысленный коммит с понятным сообщением.

Как выполняется squash?

Чаще всего squash выполняется во время операций git rebase (интерактивный режим) или git merge (с опцией --squash).

• Через интерактивный rebase: Это даёт полный контроль над историей. Вы указываете, какие коммиты нужно "схлопнуть".
• Через merge с squash: При слиянии ветки в основную все коммиты из ветки объединяются в один новый коммит в целевой ветке.

Практический пример

Допустим, у вас есть три коммита в ветке feature/login:

git log --oneline
# a1b2c3d Добавил валидацию email
# e4f5g6h Исправил ошибку в условии
# i7j8k9l Обновил текст кнопки

Вы хотите объединить их в один коммит перед слиянием в main. Используем интерактивный rebase:

git rebase -i HEAD~3

В открывшемся редакторе для первых двух коммитов меняем pick на squash или s, оставляя pick для последнего (или первого, в зависимости от порядка). После сохранения Git предложит создать новое единое сообщение коммита.

Где и когда применять?

Squash особенно полезен в рабочих процессах, основанных на Pull/Merge Requests (например, в GitFlow или GitHub Flow). Все коммиты из feature-ветки объединяются в один при мерже, что делает историю main ветки линейной и чистой. Однако не стоит применять squash к коммитам, которые уже были опубликованы в общий репозиторий, чтобы не переписывать общую историю.

Итог: Squash коммитов — это инструмент для поддержания чистоты и читаемости истории Git. Его стоит применять перед слиянием feature-веток в основную, чтобы представить законченную работу как одно целое, упрощая навигацию и анализ истории проекта.