Почему мы для code review выбрали Bitbucket, а не GitHub

В нашей небольшой компании (6 backend + 4 frontend разработчика) для code review (далее CR) мы использовали Gerrit. Gerrit используется, например, для разработки Android ^[1]. Это инструмент, дающий очень много свободы в настройке процесса CR, но мы от него отказались. Почему? Он прекрасен для суровых backend парней, который легко делают interactive rebase, merge, resolve conflict, amend commit и т.д. Люди из frontend команды по ночам плачут в подушку от тягот рабочего процесса в Gerrit.

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

Мы пришли к Bitbucket. Под катом ответы на вопросы почему Bitbucket и почему не GitHub.

1. Unlimited private repos

Тарифные планы GitHub ^[2] основываются на количестве приватных репозитериев. Тарифные планы Bitbucket ^[3] — на количестве разработчиков в команде. Т.е. GitHub больше подходит для больших команд с малым количеством проектов, а Bitbucket — малым и средним командам с большим количеством проектов. Мы как раз являемся вторым вариантом и платим 10$ в месяц вместо 100$ в случае использования GitHub.

2. Side-by-side diff

После Gerrit side-by-side diff является необходимым условием, Bitbucket им обладает:

Здесь есть несколько некритичных недостатков, таких как невозможность комментирования кода в модальном окне side-by-side diff (issue ^[4]).

3. Запрет push-а в master ветку (issue ^[5])

Каждый pull request в нашей компании должен пройти code review (CR). Поэтому достаточно важным в нашем случае является подстраховка от случайного push в master ветку. Т.е. рабочий процесс выглядит так:

1. разработчик создает ветку (feature/foo или bug/bar)
2. делает изменения в коде и push в созданную ветку
3. делает pull request в случае если по его мнению ветка готова для CR
4. происходит CR, который хорошо описан в bitbucket guideline ^[6]
5. reviewer жмет кнопку Approve в случае если код по его мнению прошел CR
6. автор pull request-a делает merge после того как получил Approve как минимум от двух человек

4. В ногу со временем

На днях Bitbucket выкатили новый резиновый интерфейс ^[7]. Конечно, есть недочеты, но хорошая тенденция очевидна.

5. Приятные мелочи

• кнопка Approved для pull request-а
• нет жесткого ограничения размера репозитория/файла
• русский язык интерфейса (мы им не пользуемся, но все же)

Две детали, которые пришлось временно решить userscript-ами:

1. fancybox ^[8]. К сожалению да, ребята из команды Bitbucket используют fancybox в самом неподходящем для этого месте — Side-by-side diff. Скрипт выключает раздражающую fade-out анимацию
2. подсветка пробелов/табов ^[9], чтобы случайно не отправить в master несоответствия с принятыми в компании правилами форматирования кода

Автор: limonte

Источник ^[10]