До недавнего времени нашим основным способом просмотра кода был просмотр лога коммитов гит в исследуемой ветке, и, если надо, более детальное изучение кода непосредственно в исходниках, с включенным режимом blame history (когда в IDE показывется какие строчки кем и когда были написаны). И этот способ вполне имеет право на жизнь, когда разработчиков не много, они делают аккуратные небольшие коммиты — с этим можно жить.
Однако, есть и другие способы. Например, один мой коллега на предыдущем месте работы в качестве код-ревью использовал GitLab. То есть код пишется в отдельной ветке, затем создается pull-request. Этот запрос на слияние проходит ревью, там же отписываются комментарии и замечания, код дорабатывается или же, если все ок, запрос одобряется и попадает в основную ветку разработки. Кстати говоря, в гитлабе, если запушить новую ветку и нажать в интерфейсе кнопку создания нового реквеста, гитлаб настолько умён, что сам автоматически подставляет почти все нужные значения, достаточно только нажать кнопку «создать». Вроде бы мелочь, но очень легко, просто и удобно. Для тех, кто не в курсе, GitLab — это, можно сказать, тот же GitHub на вашем сервере. Кстати, пара из core-девелоперов этого проекта — наши с вами соотечественники, что не может не радовать.
Для Trac’а так же можно получить код-ревью в виде плагинов, коих даже несколько. Однако ни один из этих плагинов не вызывает хоть какие-то положительные эмоции: страшные, кривые, неудобные. Я пробовал поставить и поиграться со всеми, какие нашел — половина не встала, потому что они уже сто лет как не поддерживаются, другие — просто ужасны.
Есть отдельные системы для код-ревью, такие как reviewboard или barkeep. В них, безусловно, удобно комментировать код, есть возможность просмотра дифов для веток и прочие плюшки. Если говорить про reviewboard или barkeep — то они умеют цепляться к уже существующим репозиториям, подгружать оттуда код и работать с ним. В отличие от того же Trac’а или GitLab’а, которомым для нормальной работу нужно, чтобы гит-репозиторий находился на локальной машине.
Также есть система управления проектом от фейсбука под названием phabricator. Это целый комбайн, на подобие gitlab, trac. В нем есть и система тикетов, вики, код-ревью и многое другое. Он также умеет работать с внешними репозиториями, то есть гит-репозитории не обязательно должны находится на этой же машине.
Главный недостаток таких систем, на мой взгляд, это необходимость дополнительного использования каких-то сторонних утилит для обеспечения код-ревью. Понятно, что не получится обойтись без каких-либо дополнительных действий для проведения код-ревью, но хочется свести эти действия к минимуму. В случае фабрикатора — это arc, а в ревьюбоард — это post-review. Во-первых, их надо поставить каждому разработчику — пусть это и не проблема, обычно это какие-то скрипты на php или питоне, так что они ставятся на любую ОС. Во-вторых, они меняют привычную концепцию работы: после привычных коммитов надо сделать еще несколько действий.
В фабрикаторе обычный процесс разработки задуман следующим образом: новая фича делается в отдельной ветке, далее она коммитится или же берется просто текущее состояние working directory, вызывается утилита arc diff, которая отправляет все изменения в текущей ветке на сервер для проведения код-ревью. Кому свалится запрос на код-ревью — настраивается в веб-интерфейсе, есть возможность создания гибких правил. Далее человек одобряет изменения в коде, или же комментирует, если ему что-то не нравится, автор исправляет, снова вызывает arc diff, который обновляет этот же запрос. Когда все становится хорошо, ревьюер закрывает запрос и автору нужно сделать arc land, чтобы влить эти изменения в основную ветку.
В случае с reviewboard, который оперирует патчами, вместо нормальных git diff, ему надо загрузить патч своих разработок либо через веб-интерфейс, либо через их утилиту. Даже если загружать патч неявно через их утилиту — ей надо скормить кучу разных параметров для корректной работы и, если какие-то настройки можно записать в конфиг, то, например, хэш базового коммита, для которого генерить диф — придется указывать каждый раз. Но он не лежит под рукой, надо окрыть гит-лог и найти коммит, из которого была сделана ветка. И эту операцию каждому разработчику придется делать регулярно. Это ужасно. Да и внешний вид системы красотой и изяществом не светит. Так что reviewboard, по крайней мере для нас — не вариант.
Есть еще такой проект «barkeep». Это система для код-ревью и только. Она умеет работать с внешними/удаленными репозиториями гит. Однако, на мой взгляд, в ней есть ряд недостатков. Во-первых, авторизация в системе происходит только через гугл, даже несмотря на то, что она стоит локально. Это конечно мелочь, но все же. Во-вторых, и это самое главное — эта система не имеет обратной связи с репозиторием, она только подкачивает себе изменения из репозитория, никаких мердж-реквестов и всего прочего. Она умеет показывать дифы по коммитам, которые можно построчно комментировать, запрашивать код-ревью и подтверждать. Но в нашем привычном алгоритме работы, когда человек делает фичу или багфикс в отдельной ветке, затем делает мердж-реквест своих наработок в основную ветку, а ревьюер может сразу увидеть агрегированный дифф всех изменений в ветке по сравнению с базовой и принять его, или же отклонить, подход баркипа нам не подходит. Потому что или придется по отдельности просматривать все коммиты в ветке, или же разработчик сам сольет свою ветку в основную и вот этот мердже-коммит отправит на ревью. А ведь еще он может слить ветку, а про ревью-реквест забыть. В общем — не вариант. Так что однозначно лучше выбрать gitlab, который не только обладает теми же самыми возможностями код-ревью, но и значительно большим функционалом. Кстати, по внешнему виду barkeep ну оооочень похож на gitlab, зацените сами.
Так же упомяну функциональность код-ревью в rhodecode, но про это подробнее уже писал выше.