Webdevkin
Онлайн-курсы, статьи по веб-разработке и интернет-магазинам, уроки vue.js

Изучаем Git. Урок 24.
Мердж-реквесты и код-ревью

Урок, в котором мы познакомимся с мердж-реквестами,
узнаем, зачем они нужны и как работать с ними в команде

Видеоурок

Конспект урока

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Что такое мердж-реквест?

Это запрос на вливание одной ветки в другую. Чаще всего вливается ваша ветка в мастер - основную ветку разработки

Зачем нужны мердж-реквесты?

В первую очередь они нужны при работе в команде для проведения код-ревью. Чтобы коллеги увидели новый код и как минимум его просмотрели и оставили замечания или вопросы

Как правильно: merge request или pull request?

Это одно и то же. В github и bitbucket используется понятие pull request, в gitlab - merge request. Я буду использовать мердж реквест, думаю, так звучит точнее. Вы же говорите как угодно, все поймут, о чем речь

Как проходит процедура мердж-реквеста

  • 1. Мы готовим ветку с новым функционалом/правкой бага/рефакторингом
  • 2. Пушим ветку на github
  • 3. В интерфейсе github открываем мердж-реквест, выбираем, какую ветку и куда хотим смерджить (чаще всего в мастер), при необходимости указываем описание мердж-реквеста и ревьюеров - тех, кто будет смотреть наш код
  • 4. Сообщаем коллегам о новом мердж-реквесте
  • 5. Коллеги смотрят код, оставляют замечания или вопросы
  • 6. Обсуждение: мы смотрим замечания, соглашаемся на правки или возражаем, объясняем, почему мы сделали именно так
  • 7. Делаем правки, пушим в ту же ветку новые коммиты
  • 8. Резолвим все вопросы, чтобы все замечания были закрыты или поправлены
  • 9. Принимаем мердж-реквест, при этом ветка сливается в мастер
  • 10. Удаляем ветку разработки, при необходимости деплоим в продакшен

Немного о markdown

Markdown - это специальная разметка для форматирования текста. Очень удобна в комментариях на github в описаниях к мердж-реквесту или в комментариях к коду

Markdown позволяет форматировать текст: задавать заголовки, списки, цитаты, вставлять ссылки и картинки и даже форматировать код. Насчет кода, возможно, для приграммиста это самая удобная фишка markdown, так как используется достаточно часто

Изучается markdown быстро, разметка очень простая. Вот пример оформления списка, используются звездочки

А вот пример оформления кода, используются апострофы

После этого ваш текст красиво отформатируется, можете попробовать в любом markdown онлайн-редакторе, например, dillinger.io/

Совет от автора

Потратьте немного времени на изучение markdown. Уйдет полчаса-час, но знание очень пригодится в дальнейшем. Markdown много где используется, комментарии на github - это просто одна из сфер его применения. Также с помощью markdown создают readme и даже пишут целые статьи для блогов

Немного о код ревью

Это отдельная большая тема и git она не касается. Поэтому приведу только кратко причины проводить код ревью

Что это даст:

  • Коллеги узнают о новом коде, попадающем в master
  • Подскажут, как лучше организовать код
  • Возможно, найдут ошибки
  • Предложат лучшее решение или алгоритм
  • Проверят соглашения, принятые при оформлении кода

Вопросы на код ревью могут быть совершенно разные и на разные темы. Это всего лишь краткий перечень плюсов от код ревью

2 года назад я написал статью о код-ревью: Две истории про Фёдора и Лёху
И я до сих пор не изменил своего мнения относительно код-ревью :-)

Как оповестить коллег о новом мердж-реквесте

Здесь разные варианты, зависит от договоренностей в команде.

  • Одни предпочитают автоматизировать все что можно и настраивают уведомления в корпоративные мессенджеры или на почту.
  • Вторые пишут в личку нужным людям
  • Третьи кричат на весь офис "Ребят, гляньте мой мердж-реквест срочна!"
  • Четвертые совмещают все способы

Главное договориться как будет удобнее всем в вашей команде

Кто принимает мердж-реквесты

Здесь тоже могут быть разные варианты:

  • Принимает автор кода, он же сразу после мерджа деплоит мастер в прод
  • Принимает один из ревьюеров, так как за ним окончательное решение - мерджить ветку или нет
  • Принимает тимлид, потому что он биг босс
  • Принимает тестировщик, например, потому что только он умеет деплоить в прод

Немного о работе в команде

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

Поэтому делайте так, как удобнее вам, а не так, как пишут эксперты из айти-тусовки. Брать за основу опыт умных людей - да. Слепо копировать чужие подходы - нет. Пробуйте, экспериментируйте, договаривайтесь в своей команде, находите варианты, которые устраивают всех. И так, постепенно, вы придете к лучшим практикам, найдете оптимальные решения для вашей команды

Нет оптимальных решений, которые подходят всем.
Есть оптимальные для ваших условий и вашей команды. И эти решения вам придется выбирать самим

Полезные ссылки

Документация по markdown от github
Онлайн-редактор markdown - dillinger.io/

Спасибо за внимание и до встречи!

Следующий урок ⇨
Урок 25. Форки

⇦ Предыдущий урок
Урок 23. Псевдонимы в git

Все уроки курса

* платные уроки

список обновляется...

Понравилось? Поделись с другими :-)