Строгая модель ветвления, разработанная вокруг выпуска проекта с использованием 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, но их задачи будут включены после текущего релиза.