Іменування гілок

Наприклад:

Назва складається з таких частин:

• тип — призначення гілки;

• ідентифікатор — номер задачі або інший ідентифікатор;

• короткий опис — кілька слів про зміни.

Ідентифікатор задачі не завжди є обов’язковим. Якщо технічна зміна не пов’язана із задачею, його можна пропустити:

Типи гілок

Для початку достатньо кількох типів.

feature — нова функціональність

Використовуйте для додавання можливостей, яких раніше не було:

bugfix — виправлення помилки

Використовуйте для виправлення помилок у вже наявній функціональності:

Іноді замість bugfix використовують короткий варіант fix. Важливо не те, який варіант обрано, а послідовне використання одного варіанта в усьому проєкті.

release — підготовка релізу

Використовуйте для змін, пов’язаних із підготовкою конкретної версії:

У назві зазвичай вказують номер версії без зайвих слів.

chore — технічні зміни

Використовуйте для змін, які не додають користувацької функціональності та не виправляють помилку:

До таких змін можуть належати оновлення залежностей, налаштування інструментів або зміни конфігурації.

Правила для опису

Щоб назви залишалися читабельними, домовтеся про кілька простих правил.

Використовуйте нижній регістр

Краще писати всі назви в нижньому регістрі:

Замість:

Це зменшує кількість варіантів написання та помилок під час пошуку.

Розділяйте слова дефісами

Для слів в описі використовуйте дефіси:

Не використовуйте пробіли:

Пробіли у назвах гілок незручні для командного рядка та автоматизації.

Робіть назви короткими

Назва має описувати суть роботи, але не замінювати опис задачі:

Краще, ніж надто довга назва:

Не використовуйте нечіткі назви

Назви на кшталт test, new, changes або my-branch не пояснюють призначення гілки:

є кориснішою за:

Не додавайте зайву інформацію

Якщо в назві вже є тип і номер задачі, не потрібно повторювати їх в описі:

Замість:

Приклад робочого процесу

Припустімо, у трекері є задача з номером 42: додати сторінку профілю користувача.

Створіть гілку з узгодженою назвою:

Після виконання змін перевірте назву поточної гілки:

Очікуваний результат:

Опублікуйте гілку у віддаленому репозиторії:

Параметр -u пов’язує локальну гілку з віддаленою. Надалі для відправлення змін буде достатньо команди:

Назви для різних типів роботи

Однакові правила можна застосовувати до різних ситуацій:

Якщо команда використовує номери задач, вони мають бути в однаковому форматі. Наприклад, не варто змішувати:

Краще заздалегідь обрати один варіант, наприклад:

Перейменування гілки

Якщо гілку назвали неправильно, її можна перейменувати локально.

Для перейменування поточної гілки використовуйте:

Перевірте результат:

Якщо стара назва вже була опублікована, потрібно оновити віддалений репозиторій:

Видаляти стару віддалену гілку слід лише після перевірки, що нову гілку створено правильно.

Узгодження правил у команді

Правила іменування варто записати в документації проєкту. Мінімальний набір домовленостей може мати такий вигляд:

Також зафіксуйте:

• чи є номер задачі обов’язковим;

• які типи гілок дозволені;

• чи використовуються лише нижній регістр і дефіси;

• хто перевіряє назви перед злиттям;

• чи дозволені додаткові типи, наприклад hotfix.

Правила мають бути простими. Якщо формат надто складний, учасники команди частіше відхилятимуться від нього.

Типові помилки

Використання пробілів

Правильно:

Змішування регістру

Правильно:

Відсутність типу

Правильно:

Тип одразу показує призначення гілки.

Надто загальна назва

Краще:

Непослідовні назви для однакової роботи

Якщо команда обрала bugfix, обидві гілки мають називатися послідовно:

Використання особистих назв

Назва має описувати роботу, а не автора:

Common mistakes

• Створювати гілку з назвою, яка не пов’язана із задачею.

• Змішувати fix, bugfix і hotfix, не визначивши різницю між ними.

• Використовувати пробіли, великі літери або спеціальні символи без потреби.

• Додавати надто багато слів у назву.

• Забувати номер задачі, якщо він є обов’язковим правилом команди.

• Перейменовувати локальну гілку, але залишати стару назву у віддаленому репозиторії.

• Використовувати різні формати для однакових типів змін.

Summary

• Назва гілки має бути короткою, зрозумілою та передбачуваною.

• Зручний базовий формат: <тип>/<ідентифікатор>-<опис>.

• Для нової функціональності використовуйте feature.

• Для виправлень — bugfix.

• Для підготовки релізу — release.

• Для технічних змін — chore.

• Використовуйте нижній регістр, дефіси та узгоджений формат ідентифікаторів.

• Правила іменування потрібно зафіксувати та однаково застосовувати в усій команді.