Squash

Пока идёт работа, в ветке копятся коммиты «WIP», «поправил отступы», «опечатка», «ещё раз опечатка». Для автора это нормальные шаги, но в общей истории они только мешают: через полгода по ним не понять, что и зачем менялось. Squash превращает такую серию в один коммит с осмысленным сообщением — например, «Фильтр каталога по цене».

Делают это либо локально через интерактивный rebase, либо на платформе при слиянии запроса. На GitHub есть режим Squash and merge, в GitLab — флажок объединения коммитов в merge request.

Пример: интерактивный rebase

Команда git rebase -i HEAD~3 открывает редактор со списком трёх последних коммитов. Первый оставляют как есть, у остальных слово pick меняют:

pick   1a2b3c4 Фильтр каталога по цене
squash 5d6e7f8 Поправил вёрстку фильтра
fixup  9a8b7c6 Опечатка в шаблоне

squash склеивает коммит с предыдущим и предлагает объединить сообщения, fixup склеивает молча, отбрасывая своё сообщение. Есть и третий путь — git merge --squash feature: изменения ветки добавляются в индекс без коммита, и вы фиксируете их одной записью сами.

Когда squash вредит

• Коммиты уже отправлены в общую ветку и на них опираются коллеги. Сжатие переписывает историю, и у других начнутся расхождения.
• Ветка большая и содержит несколько независимых шагов. Один гигантский коммит потом трудно откатить частично или найти в нём причину ошибки через git bisect.
• Ветку после squash-слияния продолжают использовать. Git не видит связи между её коммитами и сжатым, и повторное слияние даёт лишние конфликты.

Squash и чистая история

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