Найкращі способи написання повідомлень Git Commit: як професіонали

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

\ Існують стандарти повідомлень коміту, яких дотримуються розробники по всьому світу, і добре дотримуватися популярних стандартів, щоб коли ви повернетеся через значний проміжок часу або хтось інший подивиться на ваші повідомлення коміту, вони не виглядали жахливо!

\

\ Команди повинні спочатку вирішити, яку конвенцію повідомлень коміту використовувати, що визначає історію контролю версій продукту, який вони створюють.

\ Хороше повідомлення Git коміту повинно мати правильний стиль, зміст та метадані.

\ Відомий Git коміт дотримується цієї конвенції:

<type>(<scope>): <message>

\ <type> може бути одним із наступних:

• feat для нової функції.
• refactor для рефакторингу виробничого коду, наприклад, перейменування функції.
• docs для змін у документації.
• fix для виправлення помилки для користувача.
• perf для покращення продуктивності.
• style для змін форматування, відсутніх крапок з комою тощо.
• test для додавання відсутніх тестів, рефакторингу тестів.
• build для оновлення конфігурації збірки, інструментів розробки або інших змін, не важливих для користувача.

\ Ви також можете додати свій власний тип, залежно від стандартів, яких дотримується ваша команда. Вищезазначені стандарти дотримуються командою ESLint. Ви можете перевірити їхні повідомлення коміту тут.

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

\ Багато розробників також використовують повідомлення як рядок теми і додають тіло; це, по суті, опис коміту, але однорядкове повідомлення коміту є кращим, доки ви можете зрозуміти контекст (що і чому в коміті). Якщо коміт вимагає більш детального опису, який не можна пояснити в одному рядку, тіло коміту завжди необхідне.

\ Ви також можете використовувати такі інструменти, як Glitter або Commitizen, для стандартизації ваших повідомлень коміту.

\ Не тільки це, ви також можете задатися питанням, чи існує інструмент, який перевіряє ваше повідомлення коміту і видає помилку, якщо воно не відповідає вказівкам. Commit lint є одним з них. Він допомагає вашій команді дотримуватися конвенції коміту.

\ Багато разів експерти галузі використовують свій тікет JIRA або Click Up як повідомлення коміту, щоб все можна було пов'язати або відстежити в будь-який час, і кодова база залишалася зручною для майбутніх розробників.

\ Деякі команди також люблять додавати емодзі до своїх повідомлень коміту. Я склав список емодзі та їх відповідних значень. Ви можете перевірити його тут.

\ У підсумку, важливо, щоб ваше повідомлення коміту було змістовним і не заплутувало ваших колег-розробників або майбутніх розробників щодо того, про що йдеться в конкретній зміні.

\ Якщо ви бажаєте дізнатися більше про конвенційні коміти, семантичні коміти або практики, яких дотримується галузь, ось деякі ресурси для вас:

1. Conventional Commits
2. Semantic Commits
3. How to write a commit message by CBeams

\