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

16

Мы медленно интегрируем Mercurial в нашем офисе и занимаемся веб-разработкой, мы начали использовать именованные филиалы.

Однако мы не нашли хорошего соглашения в отношении названий наших ветвей.

Мы старались:

FeatureName (Может видеть, что это вызывает проблемы в дальнейшем)
DEVInitial_FeatureName (Может запутаться, когда разработчик придет и уйдет с линии)
{uniqueID (int)} _ Особенность

Пока побеждает uniqueID_featureName, мы думаем о том, чтобы сохранить его в маленькой БД только для справки.

Он будет иметь: branchID (int), featureName (varchar), featureDescription (varchar), дату, кто и т.д. ...

Это даст нам такие ветки, как: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... и у нас будет простая ссылка на то, что делает эта ветка без необходимости проверять журнал.

Есть ли лучшее решение там?

version-control mercurial

— jfrobishow
источник

14

Если у вас нет системы отслеживания проблем, я рекомендую настроить ее, а затем использовать {имя системы отслеживания проблем} _ {номер заявки}. Когда через несколько лет кто-то сообщит об ошибке, и вы не будете точно знать, как эта функция должна была работать, будет легко аннотировать файл и вернуться туда, где пользователь, возможно, запросил именно эту функцию.

— Аса Айерс
источник

Согласен, у нас есть багтрекер и мы планируем использовать bugID в названии ветки для исправления ошибок. Мой вопрос был больше о совершенно новой разработке, когда вы ничего не исправляете, а добавляете что-то совершенно новое. Я полагаю, мы могли бы создать тупой билет на улучшение и пойти дальше.

— jfrobishow

5

Вы обязательно должны создавать билеты на новые функции. Это работа, которую нужно отслеживать. +1 за запрос уникального идентификатора.

— 2010 года

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

— Аса Айерс

2

Я предлагаю сделать это простым и назвать ветви согласно FeatureName(или feature-name) соглашению. Да, это означает общее пространство имен, но это редко является проблемой в реальном мире. Как только функция завершена и полностью объединена с основной линией, ветку можно безопасно удалить.

Основная идея распределенного контроля версий заключается в том, что ветвление должно быть простым, введение дополнительной бюрократии, такой как обязательный уникальный идентификатор, только усложнит эту задачу.

— Адам Быртек
источник

1

Я согласен, это путь. В каком мире у вас когда-нибудь будет столько веток, что вы не сможете избежать столкновения?

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

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

— jfrobishow

1

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

— 2010 года

1

Я вижу, потому что в «большой корпоративной среде» разработчикам нельзя доверять. Но подождите, они также составляют имена для переменных, функций и файлов. Мы должны создать комитет, чтобы контролировать это тоже! (ирония)

— Адам Быртек

2

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

BUG_ID
BUG # ID
TICKET_ID
БИЛЕТ # ID
feature_bla-бла-бла
релиз-x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

Просто выберите хорошие префиксы (чтобы разрешить вывод фильтра из веток hg ), правило капитализации и разделитель между префиксом и ID / именами.

— gavenkoa
источник

+1 мы пошли с BUGID_ {freeCamelCasedTextDescription} в конце.

— jfrobishow