Хороша угода про іменування названих гілок в обраному вами {DVCS}

16

Ми повільно інтегруємо Mercurial у свій офіс і займаємось веб-розробкою, ми почали використовувати названі гілки.

Ми не зовсім знайшли хорошої конвенції щодо назви наших гілок.

Ми намагалися:

FeatureName (може бачити це причиною проблеми вниз)
DEVInitial_FeatureName (Може заплутатися, коли розробник приходить і йде по лінії)
{uniqueID (int)} _ Особливість

Поки унікальний ID_featureName виграє, ми думаємо підтримувати його у невеликій БД лише для довідки.

Він мав би: branID (int), featureName (varchar), featureDescription (varchar), дата, хто тощо ...

Це дасть нам гілки на зразок: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... і ми мали б простий посилання на те, що робить ця гілка, не перевіряючи журнал.

Будь-яке краще рішення там?

version-control mercurial

— jfrobishow
джерело

14

Якщо у вас немає трекера проблем, рекомендую налаштувати його, а потім скористатися {issue tracker name} _ {номер квитка}. Коли хтось із цього часу виправить помилку, і ви не знаєте, як саме функція повинна працювати, буде легко помітити файл і повернутись туди, де користувач, можливо, запитав саме про цю функціональність.

— Аса Айерс
джерело

Погоджено, у нас є помилка помилок і плануємо використовувати bugID у назві гілки для виправлення помилок. Моє запитання стосувалося абсолютно нового розвитку, коли ви нічого не виправляєте, а додаєте щось абсолютно нове. Я гадаю, ми могли б створити тупу білет на підвищення та йти звідти.

— jfrobishow

5

Ви абсолютно повинні створювати квитки на нові функції. Роботи, які слід також відстежувати. +1 для отримання унікального ідентифікатора

— AShelly

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

— Аса Айерс

2

Я пропоную просте і називати гілки відповідно до FeatureName(або feature-name) конвенції. Так, це означає спільний простір імен, але це рідко є проблемою в реальному світі. Після того, як функція виконана і повністю об'єднана в основну лінію, гілку можна буде безпечно видалити.

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

— Адам Бертек
джерело

1

Я згоден, це шлях. У якому б світі у вас було стільки гілок, що ви не можете уникнути зіткнення?

— альтернатива

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

— jfrobishow

1

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

— AShelly

1

Я бачу, тому що в "великому корпоративному середовищі" розробникам не можна довіряти. Але зачекайте, вони також складають назви змінних, функцій та файлів. Ми повинні створити комітет для контролю над цим! (іронія)

— Адам Біртек

2

Я рекомендую використовувати таку форму (як приклад):

BUG_ID
BUG # ID
TICKET_ID
БІЛЕТ # ID
feature_bla-bla-bla
реліз-x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

Просто виберіть хороші префікси (щоб дозволити вихід фільтру з гілок hg ), правило написання великої літери та роздільник між префіксом та ідентифікатором / іменами.

— гавенкоа
джерело

+1 ми закінчилися з BUGID_ {freeCamelCasedTextDescription}.

— jfrobishow