Рабочий процесс для обзора кода на основе GitHub

Я рассматриваю возможность использования GitHub в качестве основного инструмента для проверки кода. Благодаря таким функциям, как встроенное комментирование и сравнение, у него, похоже, есть много возможностей, которые предлагают такие инструменты, как Gerrit.

Кто-нибудь еще использовал GitHub для этого? Если да, то каков ваш рабочий процесс? И каковы ваши впечатления, как положительные, так и отрицательные?

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

EDITED с предлагаемым рабочим документом

Шаг 0. Настройте крюк после приема, используя удивительный reviewth.is.

Тогда:

  • Зафиксируйте как обычно commit -a -s, но в сообщении фиксации добавьте #reviewthis @username.

  • Если сборка завершилась неудачей, просмотр будет пропущен до восстановления сборки.

  • Комментарии рецензента о фиксации строки за строкой или на уровне файла.

  • GitHub автоматически уведомляет обозревателя комментариев.

  • Рецензент уведомляет рецензента по электронной почте, когда комментарии завершены с обзором резюме.

  • Рецензент отвечает на комментарии рецензента в GitHub, позволяя проекту получать доступ к истории обзоров кода.

Мои самые большие проблемы связаны с шагами 2 и шагами 4/5. Gerrit прекрасно работает, чтобы не просить обзоры, если сборка не удалась; Я бы хотел сделать это в GitHub. Шаги 4/5 также могут вызвать раздражение (несколько писем) и уменьшить автоматический характер процесса обзора (требуя резюме по электронной почте).

Мы используем Hudson как наш сервер сборки, если это помогает.

Любые мысли по этим проблемам также будут полезны.

Ответы

Ответ 1

Я использовал его для этого. Рабочий процесс, который я использовал, - это выполнить вашу работу в ветке темы и отправить запрос на перенос в этой ветке. Лицо (лица), занимающееся рассмотрением, проверяет код и фиксации, используя комментарии в режиме on-line (и по-фиксации). Кодер берет эту обратную связь и выполняет деструктивную перестановку в этой ветки темы, перетаскивает ее (переписывая историю в своем реестре github), тогда цикл обзора повторяется до тех пор, пока не будет приемлемо слияние.

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

Обновление: теперь я использую этот рабочий процесс как в моих проектах с открытым исходным кодом, так и в своей профессиональной работе он по-прежнему отлично работает.