Лучшие практики

Атомарные коммиты

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

Коммит считается атомарным, когда его уже невозможно разделить на более мелкие осмысленные части.

Плохо
1a2b3c
Alex Shvets
2025-04-20 10:00
Added coupons functionality (and fixed links in email notification templates) (oh, and refactored email scheduler).
+ Store/Coupons.js
+ styles/coupons.css
M Core/Scheduler/emails.js
M Emails/layout.tpl
Хорошо
1a2b3c
Alex Shvets
2025-04-20 10:00
Added coupons functionality.
+ Store/Coupons.js
+ styles/coupons.css
9f5110
Alex Shvets
2025-04-20 11:00
Fixed links in email notification templates.
M Emails/layout.tpl
bbc129
Alex Shvets
2025-04-20 11:15
Refactored email scheduler.
M Core/Scheduler/emails.js

Преимущества

  • Проще понять: атомарные коммиты сфокусированы на одном логическом изменении. Другим разработчикам (и тебе в будущем) будет намного проще понять суть и последствия каждого коммита.
  • Упрощённая отладка: если закрался баг, атомарные коммиты помогают легко вычислить конкретный коммит, который всё сломал, так как каждый из них — это изолированное изменение.
  • Командная работа: коллегам гораздо проще проводить ревью и оставлять комментарии к конкретным изменениям, когда каждый коммит решает ровно одну задачу.
  • Чистая история: благодаря атомарным коммитам история проекта остаётся чистой и структурированной. В ней проще ориентироваться и прослеживать эволюцию кодовой базы.
  • Безопасная отмена правок: если какое-то изменение нужно отменить, атомарный коммит позволяет сделать это, не задев соседние правки. Риск добавить новых багов минимален.
  • Удобный cherry-pick: атомарные коммиты гораздо проще переносить между ветками, ведь каждый коммит — это полноценный и независимый кусок работы.

Подводные камни

Если переборщить, атомарные коммиты могут сыграть злую шутку:

  • Чрезмерное дробление: если разбивать изменения на совсем уж микроскопические части, история засорится десятками крошечных коммитов, в которых будет сложно разобраться.
  • Потеря контекста: из-за фокуса на мелких изолированных правках может потеряться общая картина новой возможности или исправления.
  • Лишняя трата времени: создание кучи мелких коммитов отнимает больше времени на сами коммиты, пуши и, возможно, создание нескольких pull request‑ов.
  • Сложности с отменой правок: если новая возможность размазана по множеству атомарных коммитов, а её изменения нужно отменить, сделать это чисто будет сложнее.
  • Худшая читабельность: полная история одного изменения может растянуться на много коммитов, что усложнит жизнь разработчикам, которые будут читать историю.

Главное здесь — найти баланс. Коммиты должны быть сфокусированными и понятными, но не настолько мелкими, чтобы потерять смысл и превратиться в головную боль при управлении историей. Логически завершённые, изолированные коммиты — вот наша цель.