Как объединить несколько коммитов в один

Объединение коммитов (Squash) в Git

Объединение нескольких коммитов в один — это техника, известная как squash commit (слияние коммитов). Она широко используется для поддержания чистой истории проекта, особенно перед слиянием веток. Есть два основных подхода: через интерактивный ребейз и через слияние с squash-опцией.

Зачем объединять коммиты?

• Чистота истории: Преобразует серию мелких коммитов (например, "фикс опечатки", "еще одна правка") в один осмысленный коммит.
• Упрощение ревью: Ревьюверам проще анализировать один логический коммит, а не десяток промежуточных.
• Соблюдение конвенций: Часто требуется, чтобы каждая фича или баг-фикс был оформлен одним коммитом.
• Подготовка к слиянию: Перед мержем ветки в основную (main/master) часто делают squash, чтобы не засорять историю.

Метод 1: Интерактивный ребейз (Interactive Rebase) — самый гибкий способ

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

Процесс:

1. Определите коммит, до которого нужно объединить. Например, чтобы объединить последние 3 коммита:

   git rebase -i HEAD~3
   

    Или чтобы начать ребейз с конкретного коммита:

```bash
git rebase -i a1b2c3d4
```

2. В открывшемся редакторе вы увидите список коммитов. Для объединения вам нужно заменить ключевые слова pick для всех коммитов, кроме первого (самого старого), на squash (или просто s). Последний также можно заменить на fixup (f), если нужно отбросить их сообщения. bash pick d1e2f3a Добавил новую функцию squash a2b3c4d Исправил опечатку в комментарии squash b5c6d7e Добавил недостающую проверку

    Здесь второй и третий коммиты будут "вжаты" в первый.

1. После сохранения и закрытия файла откроется новый редактор для создания сообщения нового объединенного коммита. По умолчанию там будут все сообщения из сливаемых коммитов. Нужно отредактировать его, оставив одно ясное и информативное сообщение.

2. Сохраните и закройте. История переписана.

Сильное предупреждение: Если вы уже отправили (push) эти коммиты в общий репозиторий, и кто-то мог их забрать (pull), переписывание истории вызовет конфликт. В этом случае нужен git push --force-with-lease, но делайте это с большой осторожностью, предупредив команду.

Метод 2: Слияние с опцией --squash (Squash Merge)

Это более безопасный метод, особенно при работе с Pull/Merge Request. Он не переписывает историю, а создает новый коммит с результатом слияния.

Процесс:

1. Вы находитесь в ветке, в которую нужно влить изменения (например, main или master).
2. Выполняете команду слияния с флагом --squash для ветки с изменениями (feature-branch).

   git checkout main
   git merge --squash feature-branch
   

3. Git выполнит слияние всех изменений из feature-branch, но не создаст коммит автоматически. Все изменения будут помещены в индекс (staging area) вашей текущей ветки.
4. Вам нужно создать новый коммит с подходящим сообщением:

   git commit -m "Реализована новая платежная система (фича #123)"
   

5. После этого вы можете удалить старую ветку feature-branch. В ее истории все мелкие коммиты останутся, но в main попадет только один красивый коммит.

Пример рабочего процесса с Pull Request (PR/MR)

В современных платформах (GitHub, GitLab, Bitbucket) squash часто делается через веб-интерфейс:

1. Вы создаете ветку feature/login-form и делаете в ней 10 коммитов.
2. Создаете Pull Request в main.
3. После одобрения ревью вы или мейнтейнер нажимаете кнопку "Squash and merge".
4. Платформа сама создаст один новый коммит в main, содержащий все изменения из вашей ветки, и предложит ввести сообщение для него.
5. Ветка feature/login-form может быть удалена.

Вывод: когда что использовать?

• git rebase -i: Используйте для локальной чистки истории в своей feature-ветке перед тем, как отправить изменения или создать PR. Идеально для исправления своих же "сырых" коммитов.
• git merge --squash или кнопка в интерфейсе: Используйте при окончательном слиянии ветки в основную. Это стандартная практика во многих командах для поддержания линейной и чистой истории в main.

Ключевой принцип: История в общих ветках (main, develop, master) должна быть читаемой и логичной. История в ваших локальных или feature-ветках может быть любой, главное — привести ее в порядок перед интеграцией.