Процес роботи з комітами

Правила

До коміту слід ставитися як до закріплення деякого фінального, або проміжного, результату (залежно від поточного етапу розробки).

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

Перед та після кожного коміту необхідно проводити ретельне тестування нового коду. Якщо функціонал у коміті частковий (не працює для всіх сценаріїв, вимагатиме доопрацювання або рефакторингу), гарною практикою є відзначити ділянки, які потребуватимуть доопрацювання, з використанням //TODO: коментарів.

Коміт не повинен поєднувати рішення двох різних завдань. Навіть у разі коли вам необхідно закомітити відносно великий шматок функціонала, і одночасно внести мінімальну зміну або виправлення на іншій ділянці коду. Такі редагування потрібно робити двома (або більше) різними комітами.

В рамках одного коміту не бажано внесення змін до файлу з його одночасним перейменуванням. Часто в цьому випадку Git вважає, що був створений новий файл, і при цьому втрачається історія всіх попередніх змін - комітити такий файл не можна і необхідно провести перейменування та внесення змін двома різними комітами.

Повідомлення коміту має давати вам та іншим учасникам розробки максимально повне уявлення про те, які зміни він містить. Часто, коли рішення не очевидне, корисно, крім основного повідомлення до коміту, додати кілька речень з деталями.

Для написання повідомлень до комітів краще використовувати минулий час (“Implemented smth.”). Однак, при підключенні до роботи над проєктом, що вже існує, більше значення має спадкоємність підходів, тому якщо вибрано інший варіант (напр. теперішній час - “Implement smth.”), то слід дотримуватися саме його.

Якщо ви правильно розбили завдання на невеликі, зрозумілі, ізольовані складові, у вас автоматично виходитиме робити як мінімум кілька комітів на день, кожен з яких закриватиме частину поставленого перед вами завдання.

Також роботу над кожним окремим елементом програми (модуль, компонент, новий або експериментальний функціонал) слід інкапсулювати в окремій гілці (branch). По завершенні роботи над елементом/функціоналом, ця гілка (т.зв. “topic-” чи “feature-” branch) підлягає злиттю з тією гілкою, з урахуванням якої вона спочатку створювалася. Однак, слід завжди обговорювати політику роботи з гілками із замовником/представником замовника/віддаленою командою до початку роботи, щоб цей процес був узгоджений із уже прийнятими правилами та прозорий для всіх учасників проєкту. Наприклад, може мати місце таке:

• особлива система іменування (включення в ім'я гілки, наприклад, ID спринту або ID тікета в JIRA, який описує завдання), що полегшує менеджмент та/або необхідний для роботи всіляких "ботів"
• процесу мерджа топік гілки в одну з основних гілок може передувати незалежне code review, додаткове тестування QA командою, тестування навантаження
• в процесі роботи в новій гілці, базова для неї гілка може перейти в статус "замороженої" (наприклад, код, прийнятий в реліз), і більш недоступна для будь-яких змін і т.п.

Дотримання цих правил має такі переваги

Оскільки ви тестуєте власний код до і після коміту, під час написання наступної логіки, ви можете спиратися на цей код з певною часткою впевненості. В результаті це зменшує кількість змінних, які необхідно одночасно пам'ятати, а також дозволяє скоротити час, необхідний для знаходження помилок в новому коді.

Спрощується командна взаємодія, що особливо помітно, коли паралельно розробляються тісно пов'язані один з одним завдання. При регулярних комітах набагато простіше узгодити шлях вирішення завдання, єдність підходів, а також, у деяких випадках, можна покладатися на щойно створені компоненти.

Стає значно простіше робити ревʼю, або крос-рев'ю, і отримувати фідбек за написаним кодом, що значно підвищує динаміку розробки, а також прискорює процес обміну досвідом та знаннями всередині команди.

Сам підхід деякою мірою підштовхує вас до написання ізольованих компонентів, що слабко залежать один від одного. В результаті код спочатку більш структурований, вимагатиме менше циклів рефакторингу, і як наслідок, його набагато простіше підтримувати в майбутньому.

Стає простіше відстежувати як, коли і чому було написано ту чи іншу логіку. Ви повністю знаєте проєкт не коли ви розумієте як написаний код на цей час, а коли знаєте повну історію написання та проблеми, з якими зіштовхувалися інші розробники в процесі. Приклади:

• ви починаєте працювати над незнайомою ділянкою програми і бачите функціонал, який написаний досить складним чином і містить нетривіальні рішення. Спираючись на модульну, організовану структуру комітів і змін по файлу, що розглядається, ви досить легко зможете визначити які міркування привели розробників до представленого рішення.
• або виникла потреба терміново відкотити частину функцій програми. У цьому випадку швидкість багато в чому залежатиме від того як написаний і структурований код. Однак, якщо перед вами буде список простих, добре названих комітів, це значно прискорить вирішення завдання.