Как настроить обзор кода с помощью Gitlab?

85

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

Некоторые из моих поисков показали, что можно использовать «запросы на слияние» ... но я считаю их ограничивающими. Выданный мерж-реквест показывает все коммиты между одной веткой и другой. Кажется, я могу просматривать только различия, созданные для каждого отдельного коммита. Например, допустим, у меня есть файл, который я хочу просмотреть. Это новый файл, но я внес в него изменения более 10 коммитов в ветке dev. Если я отправлю запрос на слияние для этой ветки разработки из интеграции, я увижу 10 коммитов, каждая из которых показывает дополнительные изменения, внесенные в файл ... Я хочу просмотреть все это. Это новое!

Я здесь не на то дерево лаю? Есть ли реальный инструмент проверки кода, который я могу использовать в GitLab, или я могу использовать запросы на слияние, и если они есть, я использую их неправильно? как лучше всего настроить здесь правильную проверку кода?

djc6535
источник
1
GitLab 6.4 и его параллельное представление различий могут помочь при проверке кода: см. Мой ответ ниже
VonC
С GitLab 13.1 (июнь 2020 г.) у вас теперь есть обзоры запросов на слияние. См. Мой отредактированный ответ ниже
VonC

Ответы:

24

Примечание: так как GitLab 6.4, бок о бок вид дифф доступен: см « запрос нагрузочный 5308 ».

(Июль 2013)Однако пока нет возможности комментировать каждую строку, только на уровне файла.
Даниэль Соколовски упоминает в комментариях, что теперь поддерживаются построчные комментарии (09/2014):

Члены вашей команды могут комментировать запрос на слияние в целом или отдельные строки с комментариями строк.

Это все еще может помочь при проверке кода.

https://f.cloud.github.com/assets/4224518/1558702/e0fe633a-4fa3-11e3-9388-3f3e445cb6d4.png


6 лет спустя для GitLab 13.1 (июнь 2020 г.) :

Рецензии на мерж-реквест перенесены в Core

Изначально представленная в GitLab 11.4 как функция GitLab Premium, проверка запросов на слияние позволяет рецензентам слияния:

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

https://about.gitlab.com/images/13_1/batch_comments.png

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

См. Документацию и проблему

VonC
источник
Теперь поддерживаются построчные комментарии: «Члены вашей команды могут комментировать мерж-реквест в целом или отдельные строки со строковыми комментариями». ( about.gitlab.com/2014/09/29/gitlab-flow )
Daniel Sokolowski
1
@DanielSokolowski Отлично! Я включил ваш комментарий в ответ для большей наглядности.
VonC
9

Я делал обзоры кода в Gitlab более двух месяцев, почти без проблем. Я настроил rss2email для отправки уведомлений по электронной почте каждый раз, когда разработчик отправляет новые коммиты. Затем я использую функцию комментариев Gitlab для коммитов, чтобы сделать некоторые комментарии о размещенном коде.

К сожалению, Gitlab не позволяет комментировать файлы, только в коммитах (как и Github, я думаю). Всякий раз, когда я оказываюсь в ситуации, когда мне нужно прокомментировать что-то, что я пропустил в предыдущей фиксации, я использую инструмент обвинения, чтобы найти фиксацию, которая ввела / изменила секцию кода, которую нужно прокомментировать.

Он далек от совершенства, но пока работает хорошо.

Герберт Амарал
источник
1
Вместо rss2email можно использовать уведомления Gitlab, чтобы получать уведомления о толчках.
vadipp
У меня такая же проблема / решение. Я считаю, что было бы неплохим дополнением к функции, если бы вы могли добавить комментарий к правильному коммиту, обвиняя конкретную строку в просмотре различий или файлов (я имею в виду просмотр файлов или различий в веб-интерфейсе, а не поиск виноватых).
AlejandroVD
2

Вы можете увидеть отправленный код в запросе на слияние для другого репозитория или в текущем репозитории.
пример http://demo.gitlab.com/diaspora/diaspora/commits/master

Затем вы можете добавить комментарии к зафиксированным изменениям файла (кнопка Reply) или ко всей фиксации

пример http://demo.gitlab.com/diaspora/diaspora/commit/42f47626890218a180870bc3f44ec57625b0779c

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

Для ревю файла, в котором много коммитов, например http://demo.gitlab.com/diaspora/diaspora/blame/master/README.md, посмотрите на него, blameчтобы понять, кто что сделал. Однако в этом представлении нет возможности общаться и добавлять комментарии. В этом случае я бы рекомендовал просто добавлять изменения в качестве комментариев.

Пол Верест
источник
7
Я получаю 404 за первую, вторую и последнюю ссылку в вашем ответе.
Брайан Окли
1
Как сказано на домашней странице, demo.gitlab.com «ЯВЛЯЕТСЯ SANDBOX - он сбрасывается каждый час», поэтому все примеры были уничтожены. Это не лучший автомобиль для примеров.
Uriah Blatherwick
Да, пожалуйста, пересмотрите настройку с соответствующими примерами. Ваш ответ кажется в целом твердым советом.
данные
0

Да. Запросы на слияние - это то, как выполняются партнерские проверки.

Должна быть вкладка 'diff', на которой будут показаны изменения всех коммитов (упоминается здесь: http://youtu.be/DyAX8ws5OIc?t=3m2s ).

Видео также прекрасно объясняет, как его можно использовать для экспертной оценки.

Onionjake
источник
0

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

Что я сделал:

Оформить первую фиксацию, внести в нее изменения, зафиксировать и нажать

git co -b FIRST_COMMIT eb67f06c2b3222c0219214b176c41922bc454881
vi README.md
git add README.md
git ci -m "First commit modified so can get full diff against it"
git push --set-upstream origin FIRST-COMMIT

Оформить последний коммит, внести в него изменения, зафиксировать и нажать

git co -b master
vi README.md
git add README.md
git ci -m "Last commit modified so can get full diff against it"
git push --set-upstream origin LAST-COMMIT

В GitLab / GitHub создайте запрос на перенос

  • Это одно слияние LAST_COMMIT с FIRST_COMMIT

Работает для меня!

HankCa
источник
Разве это не оставляет вас с двумя «нежелательными» ветвями в репозитории и без отслеживания комментариев в основной ветке? Если комментарии требуют изменения кода, вы затем объединяете их в мастер?
user2084572
Да, будут ветки FIRST_COMMIT и LAST_COMMIT, которые легко удалить ( git br --delete --force origin FIRST_COMMIT LAST_COMMIT; git br --delete --force FIRST_COMMIT LAST_COMMIT). Вы можете использовать другое главное ответвление для внесения изменений в него или создавать отдельные задачи вручную. А позже создайте одну или несколько веток (например, по одной на каждую проблему), если будет слишком много отзывов.
HankCa