обзор кода с помощью git-flow и github

С обычными git и github я могу сделать обзор кода, просто создав запрос на извлечение из ветви функций, над которой я работаю, в главную ветку. Как бы я делал обзоры кода с помощью git-flow? С таким рабочим процессом, как «Завершение функции git flow», я не понимаю, где на самом деле происходит проверка кода и как git-flow или git могут облегчить это рассмотрение.

Мы наткнулись на эту проблему в последнее время. Нам действительно нравится git flow, так как он использует хороший уровень семантики (используя тот же уровень, который вы используете в групповом обсуждении: «Я начну функцию A» больше, чем «Я создам ветку, извлечу ее»), в то время как git - это очень «уровень реализации» (который также хорош и полезен, но отличается).

Проблема, с которой мы столкнулись, заключается в том git feature finish, что она объединяет ветку с разработкой, в то время как мы хотим, чтобы запрос на отправку отправлялся и (это важно) объединялся рецензентом , а не коммиттером, чтобы подчеркнуть принадлежность команды.

Наше текущее решение:

1. Кто-то использует Git Flow для создания ветки
2. Когда закончите, он создаст запрос на извлечение (используя github)
3. Обзор проводится с потенциальными дополнительными коммитами
4. Вытягивающий запрос объединяется рецензентом с помощью GitHub .
5. Завершение функции git flow не завершено (ветка уже объединена)

Это согласуется с нашей практикой, с недостатком необходимости самим удалять ветку (так как мы не выполняем git flow finish). Наш следующий шаг, вероятно, будет заключаться в том, чтобы переопределить некоторые части потока git (поскольку речь идет главным образом о цепочечных командах git), чтобы учесть это (имея «чистящую» часть финиша, без слияния).

Команда, с которой я работаю, использует для этого следующий процесс:

1. Создайте ветку объектов: git flow feature start module_1
2. Код обновляется в ветви функций
3. Когда изменения фиксируются, они помещаются в GitHub (или один раз в конце, если это предпочтительно)
4. Когда функция завершена, в GitHub сравнивается запрос на извлечение developи ветвь функции.module_1
5. Команда рассматривает запрос на получение и комментирует
6. Любые изменения из запроса извлечения делаются в функциональной ветви
7. После того, как все изменения включены в ветвь функции, ветвь функции заканчивается: git flow feature finish module_1
8. developФилиал выталкивается GitHub (GitHub будет автоматически маркировать запрос тянущий , как замкнутый / сливались , когда это произойдет)

Обычно весь этот процесс выполняется первоначальным автором, но это не обязательно. Любой в нашей команде может вмешаться и начать этот процесс в любой момент. Все, что им нужно сделать, это проверить ветку функции и продолжить процесс. git flow feature finish module_1Любой, кто когда-либо запускает, получит роскошь удаления своей локальной ветки функций, но любой, кто выберет ветку, должен сделать это вручную, если он хочет использовать что-то подобное git branch -D feature/module_1.

Для исправлений мы используем похожий подход и создаем запрос на извлечение в GitHub перед завершением исправления.

Если вы делаете обзоры кода, то я предполагаю, что у вас есть центральное хранилище, которое содержит «официальный» код. Разработчики вытягивают и толкают в этот центральный репозиторий.

Когда вы используете Gerrit , сам Gerrit становится центральным хранилищем (он имеет встроенные SSH и HTTP-серверы, которые позволяют пользователям взаимодействовать с ним в основном так же, как они уже есть). При использовании Gerrit рабочий процесс становится:

1. Разработчик вносит изменения в любую ветку, фиксирует локально.
2. Разработчик подталкивает эти изменения к Герриту.
3. Геррит создает обзорные пункты для других.
4. Пэры рассматривают код, комментируют и принимают или отклоняют коммит.
5. При фиксации принято, то Геррит делает эти изменения доступны для других , чтобы вытащить из отрасли.

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

Это хорошо работает с git-flow (или любой другой схемой ветвления), потому что Gerrit поддерживает просмотр изменений, сделанных в любой ветке.

Вот еще одно предложение.

1. Выполните обычный процесс Git Flow, чтобы создать элемент , но не заканчивайте и не объединяйте его.
2. Создайте запрос на извлечение , но не объединяйте его. Подождите, пока утверждающий оставит комментарий. Комментарий является знаком одобрения.
3. Сделайте конец потока мерзавца . (Это может сделать как утверждающий, так и разработчик, в зависимости от того, о чем договорилась команда.) Запрос на извлечение будет помечен как объединенный на github. Вам все еще нужно удалить ветку на источнике.