git / gerrit предотвращают объединение ветки Develop в стабильную ветку - PullRequest
Новая
       28

git / gerrit предотвращают объединение ветки Develop в стабильную ветку

5 голосов
/ 19 сентября 2011

Используя Gerrit, легко случайно объединить нестабильный код из разрабатываемой ветви в стабильную ветку:

$ git checkout develop<br> $ commit<br> $ git push origin HEAD:refs/for/stable

В Gerrit не очень ясно, что предлагаемое изменение исходит от ветки разработки и должно быть объединено в стабильную ветку. Есть ли способ предотвратить это слияние в git или в Gerrit?

Обновление: На данный момент мы используем пользовательскую команду push to gerrit, которая находит последнюю ветвь в источнике, на которой она была основана, и разрешаем только переход к этой ветке.

Ответы [ 3 ]

1 голос
/ 22 ноября 2012

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

Однако есть несколько вещей, которые Вы могли бы сделать:

  • обучать людейпоэтому при проверке они всегда проверяют имя ветки
  • устанавливают категорию "толкнул к правильной ветке" (howto здесь ) с такими опциями, как +1 "Правильная ветвь", 0 "Без оценки ", -1" Неправильная ветвь ", поэтому рецензент должен официально подтвердить, что он проверил имя ветви
  • , настроить инструмент непрерывной интеграции для автоматического просмотра и оценки вышеупомянутой категории ( Jenkins имеет плагин Вы можете использовать)

Не могли бы вы поделиться пользовательской командой, которую вы используете для push to gerrit, пожалуйста?

0 голосов
/ 17 июля 2014

Вы должны установить определенные средства управления доступом в Gerrit для своей "развивающейся" ветви этого репо.

Настройка как это: 

Reference: refs/for/refs/heads/develop
Push: Allow: <group>

Но не вот так: 

Reference: refs/for/refs/heads/*
Push: Allow: <group>

Таким образом, ваш <group> может нажимать только для просмотра "refs / for / development", а не "refs / for / stable" или любой другой ветки.

0 голосов
/ 20 мая 2013

Один из подходов может выглядеть примерно так:

Разделить пользователей

  • Группа отправителей - все разработчики, которых вы ожидаете посвятить только «разработке», а не «основной»'
  • Группа интеграторов - привилегированные разработчики, которые могут выдвигать и объединяться с «основным», создавать дополнительные ветви при необходимости.

В «git» разрешить принудительный доступ членам «Группы интеграторов».'(описано выше) только.

Отказ от ответственности: у меня нет опыта / настройки роли / настройки администратора Gerrit / Git, поэтому я, честно говоря, понятия не имею, как' git 'сможет получать информацию о том, к какой группе принадлежит любой пользовательк (ИМХО, это все еще может быть достигнуто вручную).

...