Подвижный рабочий процесс для ~15 разработчиков - мы должны использовать названные ответвления?
Моя команда, только начинающая с Подвижным и центральным репозиторием. У нас есть Гудзон, создающий подсказку из ответвления "по умолчанию" - который является в основном нашей магистралью. У нас была политика регистрации с нашим старым VCS, которые кодируют обзоры, тестирование, и т.д. должен быть сделан перед Вами регистрация к магистрали.
Так, скажем, Вы работаете над функцией X. Вы работаете над некоторым материалом, основывая его прочь "значения по умолчанию", и затем Вы фиксируете частичную функцию как контрольную точку. Локально Ваше "значение по умолчанию" теперь повреждается - Вы еще не совместно использовали его ни с кем, но если необходимо было сделать нажатие, хорошо теперь Вы взломали код в магистрали.
Даже если Вы ожидаете для продвижения, пока Вам не разобрались во всем этом, кажется, что существуют ситуации (например, работающий над двумя вещами сразу), где необходимо было бы продвинуть некоторые изменения, но не все.
Кроме того, при регистрации во всех изменениях контрольной точки тогда будут некоторые изменения в магистрали, которые создают, и другие в магистрали, которые не создают.
Мы начали использовать названный ответвлениями - но чем больше чтения, которое я делаю, тем больше я думаю, что мы неправильно используем названные ответвления.
Какие-либо предложения о том, как установить хороший рабочий процесс, который позволяет нам выполнять Гудзон и сохранять нашу политику магистрали?
4 ответа
Слушайте людей, которые предупреждают вас о производительности и/или дизайне. Вы жестко связываете поведение, чтобы удовлетворить довольно ограниченную потребность, когда вы можете разделить свои потребности с помощью расширения или декоратора.
-121--3119838- -121--3879655-Это вопрос мышления. Распределенные системы VCS не требуют наличия единого центрального репозитория.
Вместо того, чтобы иметь магистраль открытой для всех для регистрации, настройте ее с ограниченным доступом для записи. Только наборы изменений, которые были утверждены (протестированы, подписаны, что имеет смысл для вас), включены в магистральную линию.
То, как вы управляете получением изменений в магистраль, является широко открытым вопросом с множеством возможных ответов. Вот два из верхней части моей головы:
- Разработчики могли бы свободно перейти к центральному «тестовому» репо, из которого пересматриваются изменения.
- Если разработчики публикуют наборы изменений на своих рабочих станциях (помните, что ветви дешевые) и имеют основной процесс обзора получить их непосредственно оттуда.
В моей компании мы используем именованную ветку, чтобы различать стабильную версию (в которой мы фиксируем только исправления ошибок) и следующую версию, в которой происходит разработка, и мы регулярно переносим исправления из стабильной в стандартную (с hg merge stable в ветке по умолчанию).
Для проверки кода мы используем расширение mq, чтобы разработчики могли отправлять чистые исправления. И разработчики могут извлекать репозитории друг от друга, не загрязняя эталонный репозиторий.
Отказ от ответственности: мы не используем Hudson.
Вы можете рассмотреть, по крайней мере, два репозитория. В "основном" репозитории хранится ваш проверенный и отрецензированный код. Код попадает в этот репозиторий только после того, как Hudson протестирует его и после того, как будут завершены все ваши обзоры. Тестовый" репозиторий - это клон основного. Это репозиторий, который Hudson контролирует, так что всякий раз, когда изменения попадают в тестовый репозиторий, Hudson тестирует их. Возможно, вы сможете настроить шаг сборки Hudson, который будет перемещать изменения из тестового хранилища в основное, если тесты пройдут.
Разработчики всегда отправляют изменения в хранилище тестирования, но только извлекают их из основной линии, поэтому они всегда извлекают только проверенный код. Если им нужно обмениваться нетестированными наборами изменений, они могут напрямую проталкивать/вытаскивать между локальными репозиториями друг друга. Возможно, можно настроить Hg таким образом, чтобы магистраль принимала выгрузки только из репозитория тестирования, чтобы разработчики не могли случайно выгрузить код в магистраль вместо тестирования.
Возможно, было бы неплохо иметь также репозиторий для рецензирования. Таким образом, разработчики отправляют код на тестирование, Hudson отправляет проверенный код на рецензирование, а затем проверенный код отправляется в mainline.
Отказ от ответственности: я использовал Hg только в тривиальных проектах и тривиальными способами.
Во-первых, я настоятельно рекомендую Руководство по ветвлению в Mercurial
Затем вы можете нажать только текущую ветку: Nudge - Мягкая версия push
И, возможно, вы могли бы разрешить только головку на ветку: 32. Предотвратить push, который приведет к созданию нескольких заголовков
Другие вопросы SO, связанные с именованными ветвями:
- Mercurial: именованные ветки против нескольких репозиториев
- Структура репозитория Mercurial для нескольких ветвей