Новости программы Industrial Software Engineering
Укажите свой email для того чтобы получать полезные материалы по индустриальной разработке программного обеспечения
Новости программы Industrial Software Engineering
Укажите свой email для того чтобы получать полезные материалы по индустриальной разработке программного обеспечения

Как отключить мержи в master
и включить Code Review для github в IntellijiIdea


"Git и совместная работа" для кружка "Разработка Android-приложений на Kotlin" с помощью Git и Github.

Сейчас я вам покажу пару вещей, связанных с тем, как настроить репозиторий, чтобы работать было удобнее. Есть две базовые настройки, которые я рекомендую сделать. Я буду показывать на нашем репозитории. Все настройки находятся в Settings, интересующие нас настройки "живут" в секции "ветки". Скорее всего, когда вы проделаете то же самое дома или сейчас в репозитории, вы увидите то, что сейчас на экране. Во-первых, дефолтная ветка, если по каким-то причинам вам не нравится название master, то здесь вы можете выбрать другое название, которая у вас будет веткой по умолчанию.

Как я сказал, что ветка master - это ветка, в которой лежит супер стабильный код, где все точно работает. Ваши ветки, ветки ваших коллег - там "фарш", там все "взрывается", "свистит", но master остается неизменным сквозь года. Чтобы так было подольше, вам необходимо устанавливать защиту на master, которая предотвращает поступление туда прямых коммитов. Как только вы это сделаете, выберете master, нажмете Protect Branch - и, если у вас стоит эта галочка, то уже нельзя будет просто закоммитить в master. Это будет запрещено github. Это нужно, для того чтобы в master попадал только проверенный код. С такой настройкой туда будут попадать мержи только из пулл-реквестов, которые, как минимум кто-то просмотрел, которые можно восстановить и понять, то есть это управляемое расширение master.

Помимо этого, также является полезной настройка обязательного Code Review. Это вторая галочка. Она подразумевает то, что в master нельзя закоммитить, нельзя смержить пулл-реквест. Его обязательно должен кто-то посмотреть и сказать: "Да, этот пулл-реквест хороший, в нем все отлично". Это дополнительная защита, которая позволяет всем участникам репозитория друг за другом смотреть, проверять исходники, которые вы пишите, и быть в курсе того, что делают коллеги. Вот, я лично, в своей профессиональной жизни много видел проектов, которые гибли, из-за того что люди были не в курсе того, что происходит, каждый "зарылся" в свою ветку, в свою функциональную часть системы. Чтобы такой ситуации избегать, необходимо поддерживать какую-то информированность о том, что у вас в коде. Такой способ - это Code Review. Мы включили обязательный Code Review и запретили прямые коммиты в master. Теперь, чтобы что-то попало в master - это должно быть в пулл-реквесте и должно быть кем-то проверенно.

Чтобы увидеть что же это означает и как это работает, мы создадим новую ветку и назовем её master1. Добавим туда неправильный код, закоммитим. Если появляется новая ветка, то она должна сразу появится в github. Master1 - не появилась. Давайте попробуем на существующих ветках. Создадим какой-нибудь пулл-реквест. И мы видим такую картину, которую видят коллеги по команде. Code Review представляет собой процедуру просматривания и комментирования пулл-реквеста. Если я хочу начать Review, я должен, во-первых, просмотреть код и оставить свои замечания. Если код мне не нравится, я пишу замечания и нажимаю Start Review. То есть вы добавили какой-то комментарий, посмотрели чужой исходник, предположим, что он вам не понравился (видите пропущенный оператор). После всего этого вы должны указать итоговый результат вашего Review.

  • Вы просто комментируете (Comment) и отказываетесь от какого-то решения,

  • не согласны, что это можно мержить, но вы хотите послушать мнение других,

  • можете выбрать Approve и этим показать, что изменения хорошие.

  • можете выбрать Request Changes и явно сказать, что необходимо по каждому отмеченному вами пункту добавить исправления.

Такой инструмент позволяет всем быть в курсе того, что происходит в репозитории, и таким человеческим способом не допускать того, чтобы плохой код попал в master.

Эту процедуру используют в большом количестве команд разработчиков. У неё есть свои минусы. Часто, при неумелом использовании, она может превратиться в борьбу двух разных стилей кодирования. Люди, которым нравится табуляция безжалостно воюют с людьми, которым нравится пробелы.

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