#version-control #mercurial
#управление версиями #mercurial
Вопрос:
У нас есть команда из 10 разработчиков, которые параллельно работают над разными функциями, иногда эти функции используют общий код, иногда нет. И теперь мы меняем наш процесс на ветвление для каждой функции, и кажется, что mercurial больше подходит для такой разработки.
Я вижу этот процесс так: 1. создайте ветвь выпуска (r-b) по умолчанию (магистраль) 2. создайте ветвь функций (f-b) по умолчанию (магистраль)
Когда разработчик решит, что его функция завершена, он может объединить f-b с r-b. Когда приходит время переходить к контролю качества, мы объединяем все готовые f-b в r-b и создаем релиз для нашего QAs.
Вопросы:
-
Когда QA обнаруживает ошибку, разработчик должен изменить свой f-b и снова объединить его с r-b. Означает ли это, что разработчик просто переключается на свой f-b и начинает исправлять ошибку, а затем снова выполняет простое слияние f-b с r-b?
-
Когда release передается QA, он переходит в PROD — как мы можем заморозить изменения? «тег hg» — хороший выбор, но кто-то может обновить тег, если он действительно этого хочет.
Спасибо
Ответ №1:
Если вы собираетесь объединяться с определенными ветвями выпуска, то ваши функциональные ветви должны быть разветвлены от ветви выпуска, а не от магистрали. Проще объединить с родительской ветвью, чем с ветвью, не являющейся родительской.
1) Если вы действительно хотите создавать ветви функций, то у каждой ошибки будет своя ветвь. Это поможет отделить исправления ошибок от новых функций. В конце концов, это ветвление для каждой функции, а не ветвление для каждого разработчика.
2) Я использовал тег Hg. Вы правы, что кто-то может изменить, переместить тег, если он действительно этого хочет, но теги имеют версию, и вы можете установить перехваты в главном репозитории hg, чтобы выдавать предупреждения при перемещении тега. Я действительно не стал бы беспокоиться о перемещении тегов, если вы не можете доверять своим разработчикам, и в этом случае вы облажались.
Комментарии:
1. У нас еженедельный выпуск, и действительно трудно понять, попадает ли F-b # 1 в этот выпуск r-# 1. И в этом случае я хочу переместить f-b # 1 в следующий выпуск r-# 2 или следующий-следующий выпуск r-# 3. В этом случае разработчик просто обновляет свой f-b # 1 из trunk (после выпуска мы объединяем r-b с trunk, чтобы иметь последнюю стабильную сборку в качестве trunk) после r-# 1 и продолжаем работать. Я не знаю, хорошее ли это решение с точки зрения VSC, но разработчикам легко понять, что все f-b создается из trunk, и им все равно, в каком выпуске выходит их f-b.
2. 1. Мне не нравится ветвление для каждой ошибки, потому что мне не нужна эта ветвь — мне нужна хорошо выполненная функция. И снова разработчикам и мастерам сборки легко понять, как работать с точки зрения ветвления для каждой функции. это очень легко увидеть в JIRA, увидеть состояние проблемы с функцией и понять, что эта функция не может быть интегрирована в r-b или может. Но с помощью ветвления для каждой ошибки мастер сборки должен найти все связанные ветви. Но если это лучший способ для VSC управлять историей / слияниями / etc, то у меня нет выбора
Ответ №2:
Ответ на ваш первый вопрос «да».
Лучший способ заморозить выпуск до выпуска — создать отдельный клон выпуска, в который только менеджер выпуска может вносить изменения. То, что вы используете ветви, не означает, что нескольким клонам нет места в вашем рабочем процессе. Наличие клона, на котором QA проводит окончательное предполетное тестирование, в котором разработчики не могут вносить изменения, создает отличный брандмауэр.
Также рассмотрите возможность использования закладок для ветвей функций. Поскольку, как я уверен, вы знаете, имена ветвей с именем Mercurial никогда не исчезают, закладки, подобные git, хорошо работают для сортировки таких концепций, как функции и ошибки.
Комментарии:
1. в чем преимущества закладок? для меня именованные ветви — это более простые вещи, и они всегда хранятся в mercurial.
2. Преимущество, или, точнее, разница, заключается в их эфемерной природе. Они хранятся в репозитории, их можно нажимать и извлекать, но их также можно удалить. В основном они похожи на «теги с автоматическим продвижением». Многие люди находят именованные ветви разочаровывающими для недолговечных вещей, поскольку их никогда нельзя удалить. Если наличие 1000 ветвей вас не беспокоит (меня это не беспокоит), то в именованных ветвях нет ничего плохого.
3. Мне нужно более глубоко прочитать руководства mercurial, чтобы понять, как работают закладки. И вы можете удалить именованную ветвь с помощью «hg commit -close-branch»
4. Это не удаляет его. Это скрывает его от некоторых представлений, а не от других. Опять же, если вас устраивают именованные ветви, это здорово, я просто вижу, что многие люди спрашивают: «Как мне полностью избавиться от имени ветви?» и им не нравится ответ «Вы не можете». Набор изменений всегда находится в ветке, на которой он создан — название ветки является постоянной частью любого набора изменений — что, я думаю, отличная вещь, но не все это делают, и эти люди должны использовать закладки. Множество хороших опций; никаких жестких правил.
5. Скрытие нормально для меня как разработчика — мне все равно, как это работает, даже лучше, что именованная ветвь может быть повторно найдена в любое время. Всегда лучше иметь что-то, что вам не нужно, чем не иметь того, что вам действительно нужно 🙂 Спасибо за ответы.