Изучаем Git. Урок 17.
Зачем склеивать коммиты,
плюсы и минусы сквоша

Урок, в котором мы узнаем, зачем склеивать коммиты и нужно ли это делать, а также рассмотрим различные подходы к ведению истории коммитов и мерджа веток в мастер

Видеоурок

Этот урок разговорный, практики здесь нет. Только будем смотреть историю коммитов в IDE

Ниже только краткие выжимки и советы, остальное в видео

Разные подходы к ведению истории git и мерджа веток в мастер

1. Перед мерджем ветки в мастер склеиваем все подходы в один
2. Немного дробим коммиты, например, по принципу: 1 коммит - фронтенд, 2 коммит - бэкенд
3. Ведем подробную историю коммитов, каждый коммит содержит полезную информацию и описывает свое содержимое

Плюсы первого подхода: склеивания коммитов в один перед мерджем в мастер

1. История выглядит очень просто: один коммит - одна задача
2. История короче - быстрее читается
3. Нет мусорных коммитов с мелкими правками
4. Проще откатывать в случае багов на продакшене

Концепция независимых и самостоятельных коммитов

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

Такая концепция хорошо ложится на первый подход склеивания всех коммитов в один

Мнение автора

На мой взгляд, идея независимых коммитов несколько идеализирована и в реальной работе следовать ей сложно

Знать и пытаться использовать ее нормально, но без сильного увлечения

Почему при первом подходе склеивания коммитов в один можно меньше думать?

Потому что:
1. Не нужно придумывать хорошие commit message
2. Не нужно логически разбивать файлы и код по коммитам
3. Можно просто коммитить и пушить, не отвлекаясь от самого кода

Причина этого в том, что в итоге все равно все коммиты склеятся в один с каким-то общим названием, например, "Сделали новый отчет"

Второй подход: начинаем дробить коммиты

Плюсы:
1. Больше информации о задаче
2. Появляется информация об авторах

А зачем так нужна информация об авторах

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

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

Третий подход: создаем много коммитов, детально описываем каждый коммит, что в нем происходит

Плюсы:
1. Еще больше информации
2. Истоия git сама рассказывает о задаче
3. Полная информация об авторах отдельных участков кода
4. Легче получить информацию на код-ревью
5. Проще искать нужный код уже после мержда в мастер, когда придется делать аналогичную задачу
6. Возможность договориться о дополнительных правилах commit message, чтобы еще больше облегчить чтение истории
7. Такой подход заставляет лучше планировать свою работу

Осторожно, перфекционизм!

Я полностью разделяю третий подход к ведению истории git, но призываю не заходить в этом слишком далеко

Дробление коммитов - это не про маленькие коммиты. Это про полезные и понятные коммиты

Большие комммиты вполне допустими, если их не получается раздробить на несколько. Например, если мы отрефакторили модуль на 500 строк кода, не изменив его функционал - оставляем такой большой коммит - это нормально

Но если мы заменили один символ, поправив важную багу, то тоже оставляем. Так как это не мелкая правка, это правка важной баги

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

Спасибо за внимание и до встречи!

Следующий урок ⇨
Урок 18. git rebase

⇦ Предыдущий урок
Урок 16. Склеивание коммитов, git rebase --interactive

Все уроки курса

* платные уроки

список обновляется...

Изучаем Git. Урок 17.Зачем склеивать коммиты,плюсы и минусы сквоша