Git рабочий процесс с обзором

Я занимаюсь процессом обзора моей небольшой команды (3 участника).

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

Я вижу несколько альтернатив для включения отзывов в этот новый процесс:

1. Разработчики остались в своей песочнице

Разработчик A разрабатывает новую функцию в ветки с названием feature, опубликованной в своем пабе, затем просит просмотреть рецензент B.
Рецензент B помещает feature в свой локальный remotes/A/feature и просматривает изменения, дает обратную связь A, A делает изменения.
Повторяйте до тех пор, пока B не примет состояние ветки feature.
B отмечает последний фиксатор (тег Reviewed-by, я не уверен, как это работает).
B публикует рассмотренную ветку в своем пабе и просит интегратора я интегрировать изменения в благословенное репо.
каждый может вытащить изменения из благословенного репо.

профи:

Интегратор
может отказаться от неисследованных коммитов/ответвлений.
отмеченная фиксация показывает, кто просмотрел новый feature.

минусы:

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

2. Разработчики добавляют свою новую функцию в филиал благословенного репо

Благословенное репо уже не так благословлено, но его ветвь master есть.

A развивает новую функцию в ветке и подталкивает ветку к благословенному.
A запрашивает обзор от B.
B рассматривает ветвь feature от благословенного, дает обратную связь.
A и B работают взад и вперед, пока не будет принята ветвь feature блаженного.
B обозначает последнее фиксацию (Reviewed-by).
Интегратор Я могу объединить ветвь feature в master.

плюсы:

немного проще

минусы:

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

3. Инструмент сторонней проверки

После некоторого времени просмотра я нашел reviewboard, что кажется приятным (если мы сможем пройти через установку на нашем сервере).

плюсы:

весь обзор доступен для справок в будущем

минусы:

настройка инструмента на стороне сервера
Разработчик A должен иметь возможность иметь незанятую ветвь feature в своем пабе. Как рецензент B может отметить фиксацию в pub как рассмотренную, так как она доступна только для чтения? В идеале скорость, с которой была проведена проверка фиксации, должна отображаться из git, без необходимости запускать обзор.
если рассмотренная функция в пабе не отмечена буквой B, как интегратор может узнать, был ли он рассмотрен? Открыв инструмент третьей стороны, но не слишком ли это громоздко?

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

Я ищу комментарии по этим альтернативам и другие предложения по пути! Я уже могу сказать, что я не люблю вариант 2.

Ответ 1

На самом деле, вариант 2, если настройка с gitolite -управленный ssh-доступ, может быть совершенно жизнеспособной:

Вы можете защитить главную ветвь от любой фиксации.

Несколько комментариев:

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

Ответ 2

Мы используем github в качестве центрального хранилища для разработчиков, которым нужно нажать, когда что-то готово для совместного использования. работайте в филиале на каждую функцию/билет/задачу, чтобы они были идентифицированы идентификатором JIRA. Это позволяет хорошо отслеживать область видимости.

Github имеет довольно хорошую поддержку обзоров кода, которая на практике работает очень хорошо. Рецензент может прикреплять примечания к строкам в дельтах или коде, и они отправляются по почте заинтересованным лицам. Статус функции отслеживается через статус Jira.

В нашем случае сервер CI контролирует этот сервер.

Я подумываю вытащить с этого сервера завершенные и проверенные функции в "благословенный" репозиторий UAT, чтобы начать передачу в производство контролируемым образом.

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

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

Мы видим, что преимущества в значительной степени перевешивают недостатки и заражают другие команды в нашей организации.