Как настроить обзор кода с помощью Gitlab? Я вижу, что это указано как функция на веб-сайте Gitlab, но я не могу найти инструкций по ее настройке (в этом отношении любая ссылка на руководство пользователя Gitlab была бы очень признательна).
Некоторые из моих поисков показали, что можно использовать «запросы на слияние» ... но я считаю их ограничивающими. Выданный мерж-реквест показывает все коммиты между одной веткой и другой. Кажется, я могу просматривать только различия, созданные для каждого отдельного коммита. Например, допустим, у меня есть файл, который я хочу просмотреть. Это новый файл, но я внес в него изменения более 10 коммитов в ветке dev. Если я отправлю запрос на слияние для этой ветки разработки из интеграции, я увижу 10 коммитов, каждая из которых показывает дополнительные изменения, внесенные в файл ... Я хочу просмотреть все это. Это новое!
Я здесь не на то дерево лаю? Есть ли реальный инструмент проверки кода, который я могу использовать в GitLab, или я могу использовать запросы на слияние, и если они есть, я использую их неправильно? как лучше всего настроить здесь правильную проверку кода?
источник
Ответы:
Примечание: так как GitLab 6.4, бок о бок вид дифф доступен: см « запрос нагрузочный 5308 ».
(Июль 2013)
Однако пока нет возможности комментировать каждую строку, только на уровне файла.Даниэль Соколовски упоминает в комментариях, что теперь поддерживаются построчные комментарии (09/2014):
Это все еще может помочь при проверке кода.
6 лет спустя для GitLab 13.1 (июнь 2020 г.) :
См. Документацию и проблему
источник
Я делал обзоры кода в 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 или подобным. У меня есть ситуация, когда я разработал проект и хочу, чтобы весь код проверял все в команде.
Что я сделал:
Оформить первую фиксацию, внести в нее изменения, зафиксировать и нажать
Оформить последний коммит, внести в него изменения, зафиксировать и нажать
В GitLab / GitHub создайте запрос на перенос
Работает для меня!
источник
git br --delete --force origin FIRST_COMMIT LAST_COMMIT; git br --delete --force FIRST_COMMIT LAST_COMMIT
). Вы можете использовать другое главное ответвление для внесения изменений в него или создавать отдельные задачи вручную. А позже создайте одну или несколько веток (например, по одной на каждую проблему), если будет слишком много отзывов.