Покращуємо процес роботи з Git
Джерело фото: https://images4.alphacoders.com/985/985805.png
Уявіть: вас викликали, щоб розібратися з інцидентом у продакшені. Покопавшись, ви встановили, який коміт зламав код. Ви вирішуєте відкотити ці зміни:
$ git revert 1a2b3c
На жаль, у результаті з'являється новий баг! Виявляється, у цьому старому «зламаному» коміті був прихований код, від якого залежала інша частина кодової бази. І після відкату змін сайт все одно залишився у неробочому стані. Як уникнути таких ситуацій? Щоб відповісти на це запитання, спочатку потрібно зрозуміти, як з'являються такі комміти.
Звичайний процес роботи з Git
Давайте розглянемо, як найчастіше відбувається робота з Git під час створення нової функції:
- 1. Ви створюєте нову гілку з main.
- 2. Зберігаючи свою роботу та виправляючи зустріті баги, ви робите комміти.
- 3. Коли з функцією покінчено, робите пул-реквест.
- 4. Коли пул-реквест схвалений, робите мерж гілки в main.
Ця процедура, напевно, вам знайома. Багатьох нас навчали працювати з Git саме таким чином. Але такий підхід має два слабкі місця.
По-перше , якщо ви робите коміти у ході справи, деякі з них можуть містити незакінчені
варіанти роботи. Це робить відкат
досить ризикованим.
По-друге , це може ускладнити перевірку пул-реквестів. Припустимо, вас попросили
перевірити новий пул-реквест. Автор
зазначив, що, крім додавання нової фічі, він також виправив баг, що не має до неї відношення.
Пул-реквест містить зміни у десятках файлів. Перегляд усіх комітів окремо не дає розуміння, які зміни відносяться до виправлення бага, а які до нової фічі. Крім того, ви помітили кілька змін, які начебто взагалі ніяк не пов'язані з описом пул-реквеста. Зрозуміло, перевірка цього пул-реквесту буде нешвидкою. А наскільки було б краще, якби кожен коміт стосувався лише однієї зміни! Але це важко досягти, коли ви в процесі розробки. Постійне виляння в сторони та переписування окремих частин – невід'ємна частина процесу. Наша робота рідко буває лінійною, і це відбивається на наших коммітах.
Як же нам зробити нашу історію комітів охайною та легко читаною, враховуючи при цьому нелінійність процесу розробки? Для цього ми можемо покращити базовий процес роботи з Git, внесши невеликі зміни.
Покращений процес роботи з Git
В основі наступного підходу лежить робочий процес мого колеги Дена Вендорфа. Його робота з Git побудована на ключовому принципі: спочатку робиш роботу, а комміти підчищаєш потім.
Перевага цього підходу в тому, що ви поділяєте власне розробку та написання комітів. У результаті ми отримуємо послідовність логічно згрупованих комітів, кожен із яких стосується лише однієї основної зміни в коді. Таким чином історія комітів стає чистішою, а пул-реквести перевіряються швидше та легше. Поліпшений робочий процес можна розбити на три кроки.
Крок 1. Вносимо зміни
Тут, в принципі, все залишається, як за звичайного робочого процесу. Починаємо зі створення нової гілки та вносимо до неї потрібні зміни. На цьому етапі не варто приділяти багато уваги написанню змістовних повідомлень комітів. Вони все одно не увійдуть до підсумкового пул-реквесту. Поки що буде достатньо простого work in progress (WIP), або будь-якого іншого повідомлення. Наприклад: "WIP: Started building new model" ("Робота ведеться: розпочато створення нової моделі"). Призначення цих комітів — не загубитися у виконаній роботі та окреслити її спільні напрямки.
На цьому етапі нормально залишати кодову базу в зламаному стані або комітити сирі фічі. Все це буде підчищено пізніше.
Крок 2. Скидання
Коли закінчите вносити зміни, можна буде зайнятися підготовкою до їх упорядкування. Для цього запускаємо наступну команду:
$ git reset origin/main
Без додаткових аргументів git reset не змінює робоче дерево, тому ваш код буде в безпеці. Але оскільки ви скидаєте все до давнішого коміту, git status буде показувати всі зміни, які ви зробили з початку роботи над функцією. Це ніби ви зробили всю потрібну роботу з кодом, але не робили жодних WIP-коммітів.
Не бійтеся скидати коміти! Ви завжди можете повернути їх. Кожен зроблений вами коміт залишається у папці .git , навіть після застосування reset. Це тільки здається, що вони зникають, насправді вони на місці просто заховані. Якщо ви хочете повернутися до коміту, на якому все працювало, git reflog покаже вам таймлайн усіх коммітів, на які ви посилалися у своєму локальному репозиторії, навіть між гілками. Запустіть git reflog , щоб знайти коміт, до якого хочете повернутися, а потім git reset <commit-sha>. Ця команда переведе HEAD поточної гілки на цей коміт. Тепер ми готові робити нові коміти.
Крок 3. Робимо нові, логічно згруповані коміти
Тепер перегляньте всі файли, які ви змінили. Чи можна щось логічно згрупувати? Наприклад, усі оновлення залежностей або зміни, що стосуються конкретної моделі. Тут немає якогось єдино правильного методу угруповання, ви робите це на власний смак. Додайте вибрані файли до стейджингу та зробіть коміт з описом змін.
Якщо ви змінювали небагато файлів, можна обійтися одним комітом. Але найчастіше поділ змін на окремі коміти, що добре прочитуються, легко простежуються, полегшує перевірку пул-реквеста. Що, якщо в одному файлі є низка змін, які мають входити до різних груп? Ви можете помістити в стейджинг частину файлу за допомогою git add --patch (або git add -p). Деякі редактори коду також дозволяють поміщати в стейджинг діапазон змін, а не файл.
На цьому етапі потрібно стежити, щоб кодова база була в робочому вигляді. Пам'ятайте, що головна мета впорядкування комітів – домогтися стану, коли відкат якихось змін не ламає код в інших місцях. Зробивши один із нових комітів, сховайте зміни, які не потрапили до комміту та стейджингу, за допомогою git stash. Після цього перевірте, чи все працює.
Якщо виявиться, що до коміта потрібно включити ще якийсь файл, виконайте git stash pop, щоб повернути заховані зміни, потім додайте в стейджинг пропущений файл (git add) і виконайте git commit --amend . Останній коміт буде замінено новим, з тим самим описом. Він включатиме і старий коміт, і зміну, яку ви щойно внесли.
Підсумковий результат
Розділивши свою роботу на логічно згруповані коміти, ви будете готові зробити пул-реквест! Підсумковий результат - набір змін, які ваш колега зможе переглянути коміт за коммітом.
Перевага такої роботи з Git у тому, що враховується звичайна плинність завдань і водночас є можливість підтримувати порядок в історії репозиторію.
Джерело: https://goo.su/C4CB
Переклад українською мовою: Аліна Берестень
Адміністратор: Дмитро Берестень