Чи можете ви порекомендувати хороший шаблон повідомлення / рекомендації для виконання у компанії? [зачинено]

У Git можна встановити та застосувати хороший шаблон фіксації.

Чи можете ви порекомендувати (бажано з аргументацією) хороший шаблон / вказівки для виконання зобов'язань, які слід застосовувати в компанії?

я використовую

[Abc]: Message.

За допомогою Add, Mod (ify), Ref (акторські зйомки), Fix, Rem (ove) та Rea (спроможність), тоді легко витягти logfile.

Приклад:

Add: New function to rule the world.  
Mod: Add women factor in Domination.ruleTheWorld().  
Ref: Extract empathy stuff to an abstract class.  
Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid the nullpointer in People.  
Rem: freeSpeech is not used anymore.  
Rea: Removed old TODO and extra space in header.  

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

Ми використовуємо наступне:

[Ідентифікатор квитка в JIRA]: [Повідомлення: Що було зроблено] Наприклад - ABC-123: Додана можливість налаштування презентації для регіону.

У цьому випадку при правильній інтеграції ви зможете отримати змінені / видалені / додані файли у вашому трекері випусків. Однак майте на увазі, що вам слід запобігти щось на зразок ABC-123: Done або ABC-123: Якщо це можливо, виправлено за допомогою фільтрів.

Існує одне просте правило - це конвенція, яку дотримуються багато (якщо не всі) SCM та більшість інструментів, які працюють із SCM:

Перший рядок повідомлення про фіксацію - це короткий підсумок, а решта повідомлення містить деталі.

Отже, більшість інструментів відображає лише перший рядок та відображає все повідомлення на вимогу.

Типовим неправомірним використанням повідомлення про фіксацію є список змін (відображатиметься лише перша куля). Ще одне неправильне використання - це написання детального повідомлення в лунгу на одному рядку.

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

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

Інформація про те, що було вчинено, не повинна включатися, це може визначити система scm. Більше інформації про помилку / функції належить до того місця, де відслідковуються помилки та функції.

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

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

У Git можна застосувати майже все, що стосується гачків Git . Перегляньте приклади в .git / гаках для ідей.

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

Extracted checking foobar range from bar() into foo(min, max) to re-use
in yadda() and blah(). foo() returns true if foobar is in the
specified range and false otherwise.

BugID: 123456
ReviewedBy: mabuddy
AutomergeTo: none

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

Ми використовуємо шаблон, що містить

• Ідентифікаційний номер помилки / функції / виправлення
• Так / ні, що описує тестування коду чи ні
• І детальний розділ для короткого опису наміру скоєння

Перші два опущені більшу частину часу, однак (зрідка всі три), так що це насправді не велика справа.

Як правило, у мене є ідентифікатор, який є в системі відстеження квитків, яку я використовую, або огляд високого рівня в якості першого рядка. Тоді у мене в позиції "кулі" вказуються конкретні зміни в коміті. Тож я міг щось подібне:

MyVideoGameProject-123 OR Inventory System Improvements
Made inventory GUI drap and drap
Added ability to have multiple bag slots to expand inventory capacity

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

[ticketId] [ABC] [topicId] [WIP] Повідомлення, де:

• ticketId - ідентифікатор елемента в сховищі завдань
• ABC - додати (функція), виправити (виправлення), str (структура), dep (залежність) rem (зворотна несумісність / видалити), rea (читабельність), ref (рефакторинг)
• topicId - може бути селектором завдання для джинкінів та / або назви філії та / або назви теми для герріта
• WIP - незавершена робота чи ні (тобто для цього може знадобитися безперервна інтеграція)
• повідомлення - деталізація модифікації

Приклади:
[# 452567] [додати] [menu_item] новий елемент - гостьова книга
[# 452363] [виправити] [банер_top] [WIP] 1024x300 можна використовувати зараз
[# 452363] [виправити] [банер_top] 500x200 можна використовувати зараз
[ # 452713] [rem] [сторінка] ліве середнє оголошення