Рабочий процесс Mercurial для ~ 15 разработчиков. Должны ли мы использовать именованные ветви?

Question

Моя команда только начинает работу с Mercurial и центральным хранилищем. У нас Хадсон строит верхушку ветви «по умолчанию», которая в основном является нашей основной веткой. У нас была политика регистрации со старой версией VCS, согласно которой проверки кода, тестирование и т. Д. Должны выполняться перед регистрацией на главной линии.

Итак, допустим, вы работаете над функцией X. Вы работаете над некоторыми вещами, основываясь на «по умолчанию», а затем фиксируете частичную функцию в качестве контрольной точки. Локально ваше «значение по умолчанию» теперь нарушено - вы еще никому его не поделились, но если вы хотите сделать толчок, то теперь у вас есть неработающий код в магистрали.

Даже если вы ждете нажатия, пока не разберетесь со всем этим, создается впечатление, что существуют ситуации (например, работа над двумя вещами одновременно), когда вам необходимо внести некоторые изменения, но не все.

Кроме того, если вы отметите все изменения контрольной точки, то будут некоторые ревизии в основной линии, которые строят, и другие в основной линии, которые не строят.

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

Любые предложения о том, как настроить хороший рабочий процесс, позволяющий нам запускать Hudson и придерживаться нашей основной политики?

Answer 1

Во-первых, я настоятельно рекомендую Руководство по ветвлению в Mercurial

Далее, вы можете нажать только текущую ветвь: Смещение - более мягкая версия Push

А может быть, вы решите разрешить только голову на ветку: 32. Предотвратить толчок, который создаст несколько голов

Другие вопросы SO, связанные с именованными ветвями:

• Mercurial: Именованные ветви и несколько хранилищ
• Макет хранилища Mercurial для нескольких веток

---

Answer 2

В моей компании мы используем именованную ветку, чтобы различать стабильную версию (в которой мы фиксируем только исправления ошибок) и следующую версию, в которой происходит разработка, и мы регулярно возвращаем исправления из стабильных в стандартные ( hg merge stable в ветви по умолчанию).

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

Отказ от ответственности: мы не используем Хадсон.

Answer 3

Это вопрос мышления. Распределенные VCS не требуют, чтобы вы хранили единый центральный репозиторий.

Вместо того, чтобы открывать магистраль для всех, установите ее с ограниченным доступом для записи. Только изменения, которые были одобрены (проверены, подписаны, что имеет для вас смысл), включены в основную линию.

То, как вы управляете получением изменений в основной строке, является тогда широко открытым вопросом со многими возможными ответами. Вот два из головы:

• Разработчики могут свободно продвигаться к центральному репозиторию «тестирования», в котором рассматриваются изменения.
• Пусть разработчики публикуют наборы изменений на своих рабочих станциях (помните, что ветки дешевы), а основной процесс проверки забирает их прямо оттуда.

Answer 4

Вы можете рассмотреть как минимум два хранилища. В репозитории mainline есть ваш проверенный и проверенный код. Код отправляется в этот репозиторий только после того, как Хадсон его проверил, и после всех проверок, которые вы сделали. «Тестирующий» репозиторий был бы клоном магистрали. Это хранилище, которое отслеживает Hudson, так что всякий раз, когда набор изменений передается в хранилище тестирования, выполняется тестирование Hudson. Вероятно, вы можете настроить шаг сборки Hudson, который будет переносить изменения из репозитория тестирования в основную ветку, если тесты пройдут.

Разработчики всегда переходят в репозиторий тестирования, но извлекают его только из основной линии, поэтому они всегда извлекают только проверенный код. Если им нужно обмениваться непроверенными наборами изменений, они могут передавать / извлекать данные напрямую между локальными репозиториями друг друга. Возможно, можно настроить Hg так, чтобы магистраль принимала только толчки из репозитория тестирования, чтобы разработчики не могли случайно перейти на магистраль вместо тестирования.

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

Отказ от ответственности: я использовал Hg только на тривиальных проектах и ​​тривиальными способами.

Answer 5

Можно также использовать расширение Bookmarks вместо именованных ветвей.

Если вы знакомы с git, закладки ведут себя как ветви git, а не как ртутные ветви.