Как применить политику коммитов в Mercurial DVCS

Question

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

Таким образом, идея заключается в том, что в хранилище будет ветвь "интеграции", которая не будет напрямую разрабатываться, вместо какой-либо работыбудет выполняться в другой ветви, а после завершения будет объединен с веткой интеграции - ниже приведен грубый пример с комментариями фиксации в фигурных скобках:

  O   {Implemented new feature X}
  |\
  | O {...}
  | |
  | O {...}
  |/
  O   {Fixed bug 002}
  |\
  | O {...}
  |/
  O   {added tag "Release 1.0"}
  |
  O   {Fixed bug 001}
  |\
  | O {...}
  |/
  O  -- integration branch
 /
O  -- default branch

Ветка "интеграции" разрешает только объединение-to и помечены.

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

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

Моя первоначальная мысль - добавить хук на pre-commit ( не precommit или pretxncommit, так как я считаю, что они запускаются, когда вы, например, создаете тег).Хук будет проверять, что, если вы были в ветви интеграции, есть два родителя, что означает, что это результат слияния, и потерпит неудачу, если это не так.

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

hg clone main_repo
hg update integration_branch
(make changes without starting a new branch)
hg commit -m "I made some changes"
hg push

Кроме того, как я могу применить это при использовании системынапример, Bitbucket?

Кроме того, разве это не правильный подход к рабочему процессу при использовании DVCS?

Answer 1

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

Говоря об отказе от записи в ветку только в репо, вместо того, чтобы запретить запись во весь центральный репо, для меня это звучит почти так, как будто вы спрашиваете, какМожете ли вы убрать великолепный атрибут DVCS # 1, который (а) о том, что существует не одна копия, и что каждая копия может иметь свои собственные правила доступа для чтения / записи, одна из этих копий является центральной, если вам нравитсяи (б) эти коммиты отделены от навязывания их кому-либо еще.Коммит - это локальное действие рабочей копии.Только после того, как эти коммиты попадут в авторитетный репозиторий, либо центральный, либо тот, которым управляет ваш лейтенант кода, вы даже внесли реальные изменения в рамках этого контролируемого процесса, используя DVCS.

ИлиВы думаете, что пользователи не должны даже фиксировать свои собственные локальные экземпляры DVCS, не создавая ветви?

Короче говоря, вы могли бы сказать, что рабочая копия каждой локальной машины - это ФИЛИАЛ, невидимая ветвь, не навязаннаякого-либо или даже имени, пока он не будет опрошен лейтенантом, который проведет проверку кода и интеграционную проверку всего набора изменений, что функционально эквивалентно тому, что вы могли бы назвать «функциональной ветвью» в CVCS.Все эти невидимые ветви доступны для записи, и центральное репо (не ветка, отдельное РЕПО) доступно только для чтения в зависимости от того, как оно настроено;пользователи могут синхронизироваться с ним, но не нажимать на него, кроме лейтенанта, который вносит в него новые изменения.Принципиально стабильный, но все же каждый может выполнить работу.

Answer 2

Если у вас есть доступ к hgrc центрального репо, вы можете определить хук pretxnchangegroup, который подтверждает, что входящие наборы изменений в ветви интеграции имеют 2 родителей (тогда как первый должен быть на ветка интеграции). AFAIK, в Bitbucket вы можете настроить только пост-проверки, используя брокеров . Эти брокеры не предотвращают нежелательные толчки, но могут уведомить вас, если кто-то не соблюдал правила.

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

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