Как настроить проверку кода с помощью Gitlab?

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

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

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

Ответ 1

Примечание: поскольку GitLab 6.4, бок о бок diff view доступен: см. " запрос на растяжение 5308".

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

example http://demo.gitlab.com/diaspora/diaspora/commit/42f47626890218a180870bc3f44ec57625b0779c

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

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

Ответ 4

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

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

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