Как работать с GitHub в большой команде
- 24 января 2018
Почти вся команда, за небольшим исключением, работает в Гитхабе. На текущий момент существует 131 репозиторий.
Когда работа с Гитхабом так разрастается, появляется необходимость ввести общий порядок использования. Делимся тем, как мы её организовали.
Основные понятия, упомянутые здесь, можно найти в глоссарии терминов для Гита.
Репозитории
Создавая новый репозиторий важно предоставить необходимый минимум информации о содержимом. Это позволит быстро разобраться что к чему.
Поэтому при создании указываем:
- Описание, короткое и отражающее суть.
- Ссылка, если есть.
- Инструкцию как запустить контент репозитория в
Readme.md. - Специфические требования, если они есть.
Ветки
Произойти может всё что угодно, поэтому коммиты сразу в master под запретом, а сама ветка master по умолчанию защищена от удаления и форс пуша. Любые изменения предлагаются через пулреквесты.
Чтобы сохранить единообразие и не путаться, было решено, что ветки будут двух видов: feature/%feature_name% и bugfix/%issue_number%. Понять, какого вида ветку создавать, просто: если это не исправление ошибки, значит новая функциональность.
В master попадают только пулреквесты, хотя иногда происходят паранормальные события.
Ишьи
В репозитории скопилось 100 ишьев.
Завёл вчера ишью на Гитхабе.
До майлстоуна осталась одна ишья.
Уф-ф, одной ишьей меньше.
Опыт показывает, что задача, назначенная на всех — всё равно, что ни на кого. А это в свою очередь значит, что шансы что она будет выполнена, стремятся к нулю.
Поэтому, заводя новую ишью, следует назначить ответственного и убедиться, что он один.
Если есть желание подключить других участников к вопросу, их можно позвать упоминанием в обсуждениях через @ или привлечь сразу команду. Ответственный при этом останется один, а в ходе обсуждения можно выяснить все необходимые нюансы.
Система лейблов
Поддерживать репозитории в порядке помогает настроенная система лейблов.
Работа с кодом
Коммиты
Так как в команде нет иностранцев, все коммиты пишем по-русски. Они должны отвечать на вопрос: «Что делает коммит?».
Один коммит решает одну небольшую задачу, а не объединяет под собой несколько. Так гораздо проще следить за изменениями и восстановить ход работы при необходимости.
Если работа идёт над несколькими изменениями, то к сообщению коммита нужно прикрепить номер ишьи. Если условия поставленной задачи выполнены в сообщение коммита добавляется [fix #%issue_number%].
Пулреквесты
Мы столкнулись с проблемой, что разработчики хотят показывать только законченный результат. Но для рабочего процесса это неудобно, так как неясно что происходит с задачей в конкретный момент, возможно нужна помощь или корректировка курса. Поэтому мы договорились создавать пулреквесты как можно раньше, добавляя к ним лейбл status:wip.
При оформлении пулреквеста указываются:
- Cписок ишей, над которыми ведётся работа, используя
- [ ] %issue_name% - Лейблы.
- Один ответственный.
При принятии пулреквеста все ишьи с коммитами [fix #%issue_number%] закрываются автоматически, отдельно их закрывать не нужно.
Ревью кода
Нас много, работа идёт активно, поэтому пулреквесты обязательно проходят через лейбл status:review needed. А через внутренний механизм Гитхаба можно легко позвать енотов для ревью.
Есть важное правило ревью: комментировать код в изменениях пулреквеста, но не коммиты. Дело в том, что комментарии коммитов легко теряются и отследить что-либо по ним почти невозможно. Это порождает хаос в работе, поэтому мы никогда не комментируем коммиты — только пулреквесты.
Как следить за изменениями
Чтобы не путаться в большом количестве репозиториев можно подписываться на отдельные дискуссии.
Не забываем указывать ответственных и расставлять правильные лейблы. Мы настроили Гитхаб таким образом, что нужные лейблы сразу добавляются к репозиториям при создании.
Благодаря единообразию, все ишьи можно легко увидеть сквозь все репозитории по общим лейблам.
Что дальше?
Мы вывели общие для всех правила, навели порядок в репозиториях и поддерживаем его — это позволяет команде работать эффективнее. Но всегда можно лучше.
В планах внедрить автоматический линтинг, запрет мёржа в master, если не пройдены тесты и автодеплой, там, где это уместно.