full rest приложение на spring boot
Предлагаю разогнать воображение: представим, что у нас появилось требование для реализации определенной функциональности. Допустим, нам нужно реализовать full rest приложение на spring boot. Как мы поняли из текста выше ветку master для разработки использовать нельзя. Для этого существуют другие.
А вот основная ветка для разработки в Gitflow обычно так и называется — develop. Она содержит код, который находится в разработке и не готов к выпуску.
И если вы разработчик, который работает над новыми функциями или исправляет ошибки в проекте, она будет для вас основной. Такая ветка позволяет создавать новые изменения, тестировать их и интегрировать в проект постепенно.
Gitflow рекомендует использовать ветку develop для следующих целей:
- Разработка новых функций
- Исправление ошибок
- Тестирование и отладка кода
Когда изменения в ветке develop готовы к выпуску, они могут быть merge-ены в ветку master, чтобы обеспечить стабильность и надежность проекта.
Как создать ветку develop
Тут все просто, нужно выполнить следующую команду:
$ git checkout -b develop
Также вы можете создать ветку в одном из сервисов, описанных выше.
Для этого открываем ветки и нажимаем «+» напротив той ветки, из которой мы хотим создать ветку develop.
Вводим название ветки и нажимаем на кнопку создать:
Теперь у нас есть две ветки — основная master для стабильного продукта и develop для разработки:
Скриншоты сделаны на сайте https://gitverse.ru/ , но процесс создания через сервис идентичен и на других подобных сервисах, например на https://bitbucket.org/ .
Если вы ранее уже создавали ветку в сервисе, то вам следует локально в папке проекта переключиться на ветку develop. Для этого нужно выполнить команду:
$ git fetch && git checkout develop
Впрочем, для простого сервиса, если им занимается один разработчик Иван, этих двух веток будет достаточно.
Вносим изменения в проект
Представим, что у нас новое требование: необходимо реализовать эндпоинт GET /api/hello, который будет возвращать ответ в JSON:
```json
{
“answer”: “Hello, world”
}
```
Реализовав текущую функциональность, мы должны зафиксировать все изменения и залить их в удаленный репозиторий. Для этого последовательно выполняем следующие команды:
Индексируем изменения, которые были внесены
$ git add
Коммитим
$ git commit -m “add /api/hello endpoint”
Заливаем в удаленный репозиторий
$ git push
Когда зальем код в репозиторий, у нас получится следующая картинка в IDE IDEA:
Эти изменения можно увидеть в веб-браузере при использовании одного из удаленных репозиториев (на скрине https://gitverse.ru/):
Далее перенесем все изменения в master. Это можно сделать путем создания запроса на слияние. По-другому он называется merge request или pull request:
И этот запрос на слияние можно подтверждать, в итоге получится такой результат:
Теперь все изменения находятся в ветке master.
Разработчиков много, изменений тоже. Что делать?
Когда в команде несколько разработчиков, и каждый из них вносит какое-либо изменение, применять их все в одной ветке становится неудобно. Например, изменения из ветки develop должны попадать на сервер тестирования и в этой ветке не должно быть изменений, которые еще не завершены либо находятся в разработке. Для этого в Gitflow принят стандарт веток под названием feature.
Ветка feature — временная ветка в Gitflow, которая используется для следующих целей:
- Разработка новой функции
- Исправление ошибок
- Тестирование и отладка кода
Иными словами, ветка feature используется для разработки конкретной функции или исправления ошибки. Она позволяет работать над функцией независимо от других изменений в проекте и содержит только те изменения, которые связаны с конкретно функцией или исправлением ошибки.
А вот после, когда вы закончите разработку функции или исправления ошибки, эти изменения попадают в ветку develop, чтобы они были включены в основной поток разработки и были доступны другим участникам команды.
Как использовать ветку feature
- Gitflow рекомендует использовать ветку feature следующим образом:
- Создание временной ветки для разработки новой функции или исправления ошибки.
- Разработка и тестирование изменений в этой ветке.
- Merge изменений в ветку develop, чтобы они были включены в основной поток разработки.
Hello, Маша, или Как работать над разными фичами
Теперь представим, что к нашей команде присоединилась разработчик Маша. Вместе с Иваном они должны одновременно работать над двумя разными фичами. Каждый из них создал для себя по ветке:
$ git checkout -b feature/ivan_feature develop
У Маши пока нет локального репозитория, поэтому она клонирует его себе. Сделать это можно командой, которая указана в самом Git-сервисе:
А дальше создает новую ветку:
$ git checkout -b feature/masha_feature develop
Этой командой можно создать ветку из develop и сразу на нее переключиться.
Аналогичное можно сделать через веб-интерфейс Git-сервиса, который вы используете как описано выше, когда мы создавали ветку develop из master.
Но тут выясняется, что Ивану требуется доработать сервис так, чтобы по созданному им эндпоинту /api/hello отдавать имя пользователя, которое передается в параметре URL “name”.
При этом Маше нужно создать вторую версию эндпоинта /api/v2/hello, который должен отдавать приветствие и вопрос в JSON.
```json
{
“answer”: “Hello my name is bot”
“question”: “How can I help you?”
}
```
Когда код готов, разработчики заливают его в git-репозиторий и создают merge request в ветку develop по аналогии с запросом на слияние, который мы делали выше, когда создавали запрос на слияние из develop в master. После слияния код попадает в основной поток разработки — он доступен остальным участникам проекта.
Когда оба разработчика закончат свои задачи и их код попадет в ветку develop, он будет доступен каждому из разработчиков. Но если же код Ивана попадет в ветку develop раньше, тестировщики могут начать тестировать этот код, не дожидаясь доработок, которые выпустит Маша. Доработки Маши находятся в отдельной ветке и на стабильность кода, который находится в ветке develop, не повлияют.
На этом у меня все. В этой части мы погрузились в командную разработку. В следующей статье научимся выводить код, состоящий из доработок всех наших разработчиков, разберемся в релизах, а также поймем, что делать, если разработчики внесли доработки в один и тот же файл и при слиянии поймали конфликт.
