Строгая модель ветвления, разработанная вокруг выпуска проекта с использованием Sourcetree с простым примером

В этом руководстве мы увидим, как следовать GitFlow в нашем проекте с помощью Sourcetree.

Мы создали новый репозиторий и наш проект будет называться Beers.

Как видите, первая ветка, которую вы увидите, — это master. Это должно быть вашей основной веткой, и там всегда будет последняя версия кода, которая есть у вас в магазине или на действующем веб-сайте.

В GitFlow есть 2 основных ветки, основная и разработка. Итакдавайте позже создадим ветку "Разработка", чтобы показать, зачем нам нужны эти две ветки.

Во-первых, проверьте основную ветку и нажмите кнопку Ветвь в исходном дереве. Должно появиться следующее всплывающее окно. Введите Разработка в качестве имени ветки и нажмите Создать ветку.

После создания ветки нажмите кнопку «Push» и переместите ветку в источник, чтобы она была видна и в удаленном репозитории.

Основные ветки (мастер/разработка)

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

Разработка – это ветка, в которой все разработчики объединят свои задачи перед выпуском, и это последняя версия (стабильная) перед запуском. Позже мы объясним, как мы должны работать/объединяться в ветке Develop.

Ветка функций

Теперь давайте предположим, что у вас есть новая задача, которую нужно выполнить для следующего релиза. Все новые задачи должны создаваться в папке под названием «feature» и всегда начинаться с ветки «Разработка». Чтобы создать новую ветку для задачи, выполните ту же процедуру, что и для ветки «Разработка», но на этот раз в качестве имени вы можете указать «feature/my_branch_name».

В этом примере мы назовем его «feature/example_task». Создайте его и отправьте в исходное положение, как и раньше. Теперь ветки вашего проекта должны выглядеть так:

Если в одной команде не много людей, разработчики могут создавать свои задачи в одной папке git (feature). Если разработчиков много и разных команд, то вместо «feature» можно использовать название своей команды.

Предположим, вы выполнили свою задачу. Следующим шагом будет объединение его с Develop. Перед этим вам нужно сделать обратное слияние Develop с вашей веткой, потому что, возможно, какой-то другой разработчик закончил свою задачу (и слился с development), и вам нужно взять последнюю версию.

Чтобы сделать обратное слияние, вы должны проверить свою ветку example_task и щелкнуть правой кнопкой мыши на «Разработать». Должен появиться диалог. Выберите «Объединить разработку с функцией/примером_задачи».

Теперь ваша ветка имеет последний код Develop. Пришло время объединить вашу ветку в Develop. Вы должны сделать то же самое, что и раньше, но теперь выберите «Разработка» и щелкните правой кнопкой мыши на «example_task».

После слияния рекомендуется удалить свою ветку, чтобы в папке функций не было такой путаницы.

Хорошо, теперь все разработчики выполнили свои задачи, они объединили свой код в Develop, и теперь пришло время подготовить версию, которая будет запущена.

Следующим шагом является создание ветки Release.

Как и раньше, создайте новую ветку, и на этот раз мы можем назвать ее «релиз/1.0.0», где релиз/ — это папка, а 1.0.0 — новая версия нашего проекта. Ваш репозиторий будет выглядеть так:

Давайте объясним ветку выпуска

Релизная ветвь

Эта ветвь будет использоваться, когда все команды объединят свой код в разработку и приложение будет готово к тестированию. Название должно быть таким: release/1.0.1, где 1.0.1 — наша версия приложения.

Все возможные исправления ошибок, найденные при тестировании, должны быть объединены в этой ветке.

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

Отделение исправлений

Этот будет использоваться только в том случае, если в предыдущей ветке (релизе) были какие-то проблемы при тестировании и нам нужно выполнить исправление ошибки. Обычно это создается, начиная с ветки релиза. Именование должно быть исправление/my_bug

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

  • объединить выпуск/1.0.0 с веткой Develop
  • объединить релиз/1.0.0 с основной веткой
  • удалить выпуск/1.0.0
  • кассовый мастер
  • создать тег версии

Последний шаг — просто отслеживать нашу версию, потому что иногда нам нужно исправить некоторые ошибки в конкретной версии. Чтобы создать тег, вы можете перейти в репозиторий в меню и затем нажать тег. Должен появиться такой диалог:

Отметьте также параметр Push-тег и нажмите Добавить.

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