3.4 Галуження в git - Процеси роботи з гілками

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

Багато розробників підтримують з Git такий процес, коли тільки в master є стабільна версія коду — найімовірніше того, що був чи буде запроваджений у виробництво. Також вони мають паралельні гілки develop чи next, які використовуються для тестування стабільності — це не обов’язково постійно стабільні гілки, але, як тільки вони стабілізовуються, їх можна зливати з master. Також практикується мати тематичні гілки (коротко-термінові, як iss53, що ви створили раніше) та зливати їх, коли вони готові, проходять всі тести, та не привнесуть нових помилок.

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

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

Ви можете мати декілька рівнів стабільності. На більших проектах також практикують мати proposed чи pu (proposed updates) гілки, де зберігаються гілки, що вже інтегровані, але не готові бути перенесені в основні гілки next чи master. Ідея таких гілок в тому, що ваші гілки мають кілька рівнів стабільності і коли вони досягають більш стабільного рівня, їх зливають до гілок, котрі вище над ними. Зверніть увагу, що мати кілька довготривалих гілок не обов’язково, проте буває корисним, особливо коли маєте справу з великими чи складними проектами.

Тематичні гілки мають своє застосування в проектах будь-якого розміру. Тематична гілка — це короткострокова гілка, що створюється для окремо взятого завдання чи функціональності. Напевно, ви таке раніше не робили часто з іншими СКВ, оскільки загалом це досить “дорого” створювати та зливати гілки. Проте в Git це досить звична практика створювати, додавати коміти, зливати та видаляти гілки по кілька разів на день.

Приклад цього ви бачили раніше в попередньому розділі з гілками iss53 та hotfix Ви додавали кілька комітів в ці гілки та видаляли їх одразу після зливання в основну гілку. Така техніка дозволяє швидко та повністю змінювати контекст роботи, оскільки ваша робота в окремому елеваторі, де всі зміни пов’язані тільки з однією темою чи завданням, це полегшує та ізолює перегляд коду тощо. Ви можете тримати свої зміни там кілька хвилин, днів, чи місяців, і зливати аж тоді, коли вони будуть готові.

Розглянемо приклад, коли нам потрібно зробити завдання №91 (в master), ми робимо гілку (iss91), трохи там працюємо, потім робимо з неї ще одну гілку (iss91v2) щоб попробувати інший підхід, повертаємося в master на деякий час, і тоді робимо ще одну гілку щоб перевірити одну непевну ідею (гілка dumbidea). Історія комітів виглядатиме десь так:

Тепер, скажімо, вам сподобався підхід номер два (iss91v2) і ви показали свою ідею (гілку dumbidea) колегам, і вона їм здається геніальною. Ви можете викидати оригінальну iss91 (втрачаючи коміти C5 та C6) та зливати дві інші гілки. Тепер ваша історія така:

Ми приділимо більше уваги різним можливим робочим процесам ваших Git проектів в Розподілений Git, тому, перед остаточним рішенням яку ж схему обрати, прочитайте цей розділ.

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