Git, Gitflow и ветка develop. Продолжаем разбираться в основах программирования

Привет, Хабр! В блоге beeline cloud я делюсь личным опытом разработки. Сегодня продолжу знакомить вас с Git, Gitflow и веткой develop.

Предлагаю разогнать воображение: представим, что у нас появилось требование для реализации определенной функциональности. Допустим, нам нужно реализовать full rest приложение на spring boot. Как мы поняли из текста выше ветку master для разработки использовать нельзя. Для этого существуют другие.

А вот основная ветка для разработки в Gitflow обычно так и называется — develop. Она содержит код, который находится в разработке и не готов к выпуску.

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

Gitflow рекомендует использовать ветку develop для следующих целей:

Когда изменения в ветке develop готовы к выпуску, они могут быть merge-ены в ветку master, чтобы обеспечить стабильность и надежность проекта.

ут все просто, нужно выполнить следующую команду:

Также вы можете создать ветку в одном из сервисов, описанных выше.

Для этого открываем ветки и нажимаем «+» напротив той ветки, из которой мы хотим создать ветку develop.

Вводим название ветки и нажимаем на кнопку создать:

Теперь у нас есть две ветки — основная master для стабильного продукта и develop для разработки:

Скриншоты сделаны на сайте https://gitverse.ru/ , но процесс создания через сервис идентичен и на других подобных сервисах, например на https://bitbucket.org/ .

Если вы ранее уже создавали ветку в сервисе, то вам следует локально в папке проекта переключиться на ветку develop. Для этого нужно выполнить команду:

Впрочем, для простого сервиса, если им занимается один разработчик Иван, этих двух веток будет достаточно.

Представим, что у нас новое требование: необходимо реализовать эндпоинт GET /api/hello, который будет возвращать ответ в JSON:

Реализовав текущую функциональность, мы должны зафиксировать все изменения и залить их в удаленный репозиторий. Для этого последовательно выполняем следующие команды:

Индексируем изменения, которые были внесены

Коммитим

Заливем в удаленный репозиторий

Когда зальем код в репозиторий, у нас получится следующая картинка в IDE IDEA:

Эти изменения можно увидеть в веб-браузере при использовании одного из удаленных репозиториев (на скрине https://gitverse.ru/):

Далее перенесем все изменения в master. Это можно сделать путем создания запроса на слияние. По-другому он называется merge request или pull request:

И этот запрос на слияние можно подтверждать, в итоге получится такой результат:

Теперь все изменения находятся в ветке master.

Когда в команде несколько разработчиков, и каждый из них вносит какое-либо изменение, применять их все в одной ветке становится неудобно. Например, изменения из ветки develop должны попадать на сервер тестирования и в этой ветке не должно быть изменений, которые еще не завершены либо находятся в разработке. Для этого в Gitflow принят стандарт веток под названием feature.

Ветка feature — временная ветка в Gitflow, которая используется для следующих целей:

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

А вот после, когда вы закончите разработку функции или исправления ошибки, эти изменения попадают в ветку develop, чтобы они были включены в основной поток разработки и были доступны другим участникам команды.

Gitflow рекомендует использовать ветку feature следующим образом:

Теперь представим, что к нашей команде присоединилась разработчик Маша. Вместе с Иваном они должны одновременно работать над двумя разными фичами. Каждый из них создал для себя по ветке:

У Маши пока нет локального репозитория, поэтому она клонирует его себе. Сделать это можно командой, которая указана в самом Git-сервисе:

А дальше создает новую ветку:

Этой командой можно создать ветку из develop и сразу на нее переключиться.

Аналогичное можно сделать через веб-интерфейс Git-сервиса, который вы используете как описано выше, когда мы создавали ветку develop из master.

Но тут выясняется, что Ивану требуется доработать сервис так, чтобы по созданному им эндпоинту /api/hello отдавать имя пользователя, которое передается в параметре URL “name”.

При этом Маше нужно создать вторую версию эндпоинта /api/v2/hello, который должен отдавать приветствие и вопрос в JSON.

Когда код готов, разработчики заливают его в git-репозиторий и создают merge request в ветку develop по аналогии с запросом на слияние, который мы делали выше, когда создавали запрос на слияние из develop в master. После слияния код попадает в основной поток разработки — он доступен остальным участникам проекта.

Когда оба разработчика закончат свои задачи и их код попадет в ветку develop, он будет доступен каждому из разработчиков. Но если же код Ивана попадет в ветку develop раньше, тестировщики могут начать тестировать этот код, не дожидаясь доработок, которые выпустит Маша. Доработки Маши находятся в отдельной ветке и на стабильность кода, который находится в ветке develop, не повлияют.

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