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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете увидеть отправленный код в запросе на слияние для другого репозитория или в текущем репозитории.
пример 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чтобы понять, кто что сделал. Однако в этом представлении нет возможности общаться и добавлять комментарии. В этом случае я бы рекомендовал просто добавлять изменения в качестве комментариев.

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

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

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

Обычный вариант использования обзоров кода - это проверка кода в ветке перед слиянием с 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

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