Шпаргалка по git-flow
Эта шпаргалка показывает основные способы использования операций git-flow.
Общие замечания
- Git flow предоставляет превосходную командную строку со справкой и улучшенными выводом. Внимательно читайте его, чтобы знать, что происходит.
- Клиент для macOS/Windows Sourcetree — отличный GUI для Git — также поддерживает git-flow
- Git-flow основан на слиянии. Для слияния веток фич не используется rebase.
Установка
- В первую очередь вам нужна рабочая установка git
- Git flow работает на macOS, Linux и Windows
macOS
Linux
Windows (Cygwin)
Вам потребуется wget и util-linux для установки git-flow.
Подробные инструкции по установке git flow смотрите на git flow wiki.
Приступая к работе
Git flow нужно инициализировать, чтобы настроить его для работы с вашим проектом.
Инициализация
Для начала использования git-flow проинициализируйте его внутри существующего git-репозитория:
Вам придётся ответить на несколько вопросов о способах именования ваших веток.
Рекомендуется оставить значения по умолчанию.
- Разработка новых фич для последующих релизов
- Обычно присутствует только в репозиториях разработчиков
Начало новой фичи
Разработка новых фич начинается из ветки «develop».
Для начала разработки фичи выполните:
Это действие создаёт новую ветку фичи, основанную на ветке «develop», и переключается на неё.
Завершение фичи
Окончание разработки фичи. Это действие выполняется так:
- Слияние ветки MYFEATURE в «develop»
- Удаление ветки фичи
- Переключение обратно на ветку «develop»
Публикация фичи
Вы разрабатываете фичу совместно с коллегами?
Опубликуйте фичу на удалённом сервере, чтобы её могли использовать другие пользователи.
Получение опубликованной фичи
Получение фичи, опубликованной другим пользователем.
Вы можете отслеживать фичу в репозитории origin с помощью команды git flow feature track MYFEATURE
Создание релиза
- Поддержка подготовки нового релиза продукта
- Позволяет устранять мелкие баги и подготавливать различные метаданные для релиза
Начало релиза
Для начала работы над релизом используйте команду git flow release Она создаёт ветку релиза, ответляя от ветки «develop».
При желании вы можете указать [BASE] -коммит в виде его хеша sha-1, чтобы начать релиз с него. Этот коммит должен принадлежать ветке «develop».
Желательно сразу публиковать ветку релиза после создания, чтобы позволить другим разработчиками выполнять коммиты в ветку релиза. Это делается так же, как и при публикации фичи, с помощью команды:
Вы также можете отслеживать удалённый релиз с помощью команды
git flow release track RELEASE
Завершение релиза
Завершение релиза — один из самых больших шагов в git-ветвлени. При этом происходит несколько действий:
- Ветка релиза сливается в ветку «master»
- Релиз помечается тегом равным его имени
- Ветка релиза сливается обратно в ветку «develop»
- Ветка релиза удаляется
Не забудьте отправить изменения в тегах с помощью команды git push —tags
Исправления
- Исправления нужны в том случае, когда нужно незамедлительно устранить нежелательное состояние продакшн-версии продукта
- Может ответвляться от соответствующего тега на ветке «master», который отмечает выпуск продакшн-версии
git flow hotfix start
Как и в случае с другими командами git flow, работа над исправлением начинается так:
Аргумент VERSION определяет имя нового, исправленного релиза.
При желании можно указать BASENAME-коммит, от которого произойдёт ответвление.
Завершение исправления
Когда исправление готово, оно сливается обратно в ветки «develop» и «master». Кроме того, коммит в ветке «master» помечается тегом с версией исправления.
asqd / git-flow.md
Главный репозиторий всегда содержит две главные ветки:
- master — главная ветка для продакшена. Содержит только готовые релизы.
- develop — главная ветка для разработки.
Когда код в ветке develop готов к релизу, то все изменения вливаются в ветку master и помечаются номером релиза.
- featured branches содержат новый функционал приложения
- release branches для подготовки релизов
- hotfix brances для быстрого исправления ошибок в продакшене
Featured branches (Фичи)
Порождаются от develop
Вливаются в develop
Название веток любое, кроме master , develop , release-* или hotfix-*
Featured branches используют для разработки новых функций, которые войдут в текущий или будущие релизы приложения. В начале работы над веткой мы можем не знать в какой релиз она войдет.
Когда разработка фичи завершена, ветка вливается в develop или удаляется, если фича была неудачной.
Обычно ветки с фичами создаются и живут в локальном репозитории разработчика.
Как это работает
В начале работы над новой фичей создается ветка от develop .
Когда фича завершена, ветка вливается обратно в develop и попадает в следующий релиз.
Порождаются от develop
Вливаются в develop и master
Название ветки release-*
Ветки релизов нужны для подготовки к выпуску новых версий программы. Они позволяют протестировать и исправить ошибки в ветке перед слиянем в master .
Новая ветка релиза созается, когда функционал develop ветки почти соответствует новому релизу. Функционал для следующих релизов в неё не включается.
Номер версии определяется в момент создания релизной ветки.
Как это работает
Ветка релиза создается от develop и живет пока релиз не будет готов к выпуску. После создания релизной ветки все ветки исправлений вливаются в неё, а не в develop . Все новые фичи ждут нового релиза и не попадают в текущий.
Когда мы решили, что ветка релиза готова и все ошибки исправлены, то она сливается в master . Коммит помечается версией релиза. Все изменения в ветке релиза также добавляются в develop , чтобы она содержала исправления ошибок.
Hotfix branches (Ветки правок)
Порождаются от master
Вливаются в develop и master
Название ветки hotfix-*
Ветки правок нужны для быстрого исправления ошибок в продакшене. Когда в продакшен версии возникают критические ошибки, от master ветки создается новая ветвь и в ней идет работа над исправлением ошибки.
Как это работает
Ветка правок создается от master ветки. Когда ошибки исправлены, изменения вливаются в master и develop , чтобы правки попали в следующий релиз. Правка отмечается новой версией в главной ветке.
Примечание: Если в момент обнаружения ошибки существует ветвь релиза , то ветка с исправлениями должна вливаться в неё, а не в develop . Правки войдут в develop позже, вместе с веткой релиза.
OSX
Внутри своего git репозитория выполнить
Новая фича начинается с ветки develop .
* — номер задачи в JIRA
Команда создает новую ветку фичи и переключается на неё.
После завершения фичи выполняем
Происходит слияние ветки в develop , удаляется ветка с фичей, переключаемся на develop .
Публикуем фичу в репозитории, чтобы её смогли забрать коллеги:
Получить фичу из origin
Создает ветку релиза от develop .
Публикуем ветку в origin git flow release publish ###
- Сливает ветку релиза в master
- Отмечает релиз тегом по его имени
- Сливает ветку в develop
- Удаляет ветку релиза
VERSION — имя нового, исправленного релиза BASENAME — опционально, коммит, от которого создаем ветку
Сливаем ветку в develop и master . Коммит в master отмечается тегом с версией исправления.
Рабочий процесс Gitflow Workflow
Git-flow — это устаревшая версия рабочего процесса Git, в свое время ставшая принципиально новой стратегией управления ветками в Git. Популярность Git-flow стала снижаться под влиянием магистральных рабочих процессов, которые на сегодня считаются предпочтительными для современных схем непрерывной разработки ПО и применения DevOps. Кроме того, Git-flow не слишком удобно применять в процессах CI/CD. В этой публикации приводится описание Git-flow для истории.
Что собой представляет Git-flow?
Git-flow — альтернативная модель ветвления Git, в которой используются функциональные ветки и несколько основных веток. Эта модель была впервые опубликована и популяризована Винсентом Дриссеном на сайте nvie. По сравнению с моделью магистральной разработки, в Git-flow используется больше веток, каждая из которых существует дольше, а коммиты обычно крупнее. В соответствии с этой моделью разработчики создают функциональную ветку и откладывают ее слияние с главной магистральной веткой до завершения работы над функцией. Такие долгосрочные функциональные ветки требуют тесного взаимодействия разработчиков при слиянии и создают повышенный риск отклонения от магистральной ветки. В них также могут присутствовать конфликтующие обновления.
Git-flow можно использовать для проектов, в которых запланирован цикл релизов и реализуется характерная для DevOps методика непрерывной поставки. В этом рабочем процессе используются понятия и команды, которые были предложены в рамках рабочего процесса с функциональными ветками. Однако Git-flow привносит новые специфические роли для разных веток и определяет характер и частоту взаимодействия между ними. Помимо функциональных веток в рамках этого рабочего процесса используются отдельные ветки для подготовки, поддержки и регистрации релизов. При этом вы по-прежнему можете пользоваться преимуществами рабочего процесса с функциональными ветками, такими как запросы pull, изолированные эксперименты и эффективное командное взаимодействие.
Начало работы
Gitflow — это лишь методика работы с Git; в ней определяется, какие виды веток необходимы проекту и как выполнять слияние между ними. Ниже мы познакомимся с назначением веток. Набор инструментов git-flow представляет собой отдельную утилиту командной строки, которая требует установки. Процесс установки прост. Пакеты команд git-flow доступны для многих операционных систем. В системах OS X можно выполнить команду brew install git-flow . Если вы используете Windows, вам нужно загрузить и установить git-flow. После установки решения git-flow необходимо выполнить команду git flow init , чтобы использовать его в проекте. Этот набор инструментов играет роль обертки Git. Команда git flow init является расширением стандартной команды git init и не вносит изменений в репозиторий помимо создания веток.
Порядок действий
Ветка разработки и главная ветка
В этом рабочем процессе для регистрации истории проекта вместо одной ветки main используются две ветки. В главной ветке main хранится официальная история релиза, а ветка разработки develop предназначена для объединения всех функций. Кроме того, для удобства рекомендуется присваивать всем коммитам в ветке main номер версии.
Первый шаг рабочего процесса заключается в создании ветки develop от стандартной ветки main . Разработчику будет проще создать пустую ветку develop локально и отправить ее на сервер.
В этой ветке будет храниться полная история проекта, а в ветке main — сокращенная. Теперь другим разработчикам следует клонировать центральный репозиторий и создать отслеживающую ветку для ветки develop .
При использовании библиотеки расширений git-flow, для создания ветки develop можно выполнить команду git flow init в существующем репозитории:
Функциональные ветки (feature)
Под каждую новую функцию нужно выделить собственную ветку, которую можно отправить в центральный репозиторий для создания резервной копии или совместной работы команды. Ветки feature создаются не на основе main , а на основе develop . Когда работа над функцией завершается, соответствующая ветка сливается с веткой develop. Функции не следует отправлять напрямую в ветку main .
Обратите внимание, что комбинация веток feature с веткой develop фактически представляет собой рабочий процесс с функциональными ветками. Но рабочий процесс Gitflow на этом не заканчивается.
Как правило, ветки feature создаются на основе последней ветки develop .
Создание функциональной ветки
Без использования расширений git-flow:
С использованием расширений git-flow:
Продолжайте работу с Git как обычно.
Окончание работы с функциональной веткой
После завершения работы над функцией следует объединить ветку feature_branch с develop .
Без использования расширений git-flow:
С использованием расширений git-flow:
Ветки выпуска (release)
Когда в ветке develop оказывается достаточно функций для выпуска (или приближается назначенная дата релиза), от ветки develop создается ветка release . Создание этой ветки запускает следующий цикл релиза, и с этого момента новые функции добавить больше нельзя — допускается лишь исправление багов, создание документации и решение других задач, связанных с релизом. Когда подготовка к поставке завершается, ветка release сливается с main и ей присваивается номер версии. Кроме того, нужно выполнить ее слияние с веткой develop , в которой с момента создания ветки релиза могли возникнуть изменения.
Благодаря тому, что для подготовки выпусков используется специальная ветка, одна команда может дорабатывать текущий выпуск, в то время как другая команда продолжает работу над функциями для следующего. Это также позволяет разграничить этапы разработки (например, можно без труда посвятить неделю подготовке к версии 4.0 и действительно увидеть это в структуре репозитория).
Создание веток release — это еще одна простая операция ветвления. Как и ветки feature , ветки release основаны на ветке develop . Создать новую ветку release можно с помощью следующих команд.
Без использования расширений git-flow:
При использовании расширений git-flow:
Когда подготовка к поставке завершается, релиз сливается с ветками main и develop , а ветка release удаляется. Важно слить ее с веткой develop , поскольку в ветку release могли добавить критические обновления, которые должны быть доступны для новых функций. Если в вашей организации уделяют повышенное внимание проверке кода, это идеальное место для выполнения запроса pull.
Для завершения работы в ветке release используйте следующие команды:
Без использования расширений git-flow:
Или при использовании расширений git-flow:
Ветки исправления (hotfix)
Ветки сопровождения или исправления ( hotfix ) используются для быстрого внесения исправлений в рабочие релизы. Ветки hotfix очень похожи на ветки release и feature . Отличие заключается в том, что они создаются на основе main , а не develop . Это единственная ветка, которую нужно обязательно создавать напрямую от main . Как только исправление завершено, эту ветку следует слить с main и develop (или текущей веткой release ), а ветке main присвоить обновленный номер версии.
Благодаря специальной ветке для исправления ошибок команда может устранять проблемы, не прерывая остальную часть рабочего процесса и не дожидаясь следующего цикла релиза. Ветки сопровождения можно рассматривать как специальные ветки release , которые работают непосредственно с main . Ветку hotfix можно создать с помощью следующих команд.
Без использования расширений git-flow:
При использовании расширений git-flow:
По завершении работы с веткой hotfix ее сливают с main и develop (как и в случае с веткой release ).
Пример
Далее показан полный цикл работы с функциональной веткой (предполагается, что у нас есть репозиторий с веткой main ).
Помимо работы с ветками feature и release , продемонстрируем работу с веткой hotfix :
Резюме
В этой статье мы рассмотрели модель работы Gitflow. Gitflow — лишь одна из многих методологий работы с Git, доступных вам и вашей команде.
Модель ветвления Gitflow
В предыдущей статье мы начали говорить о моделях ветвления при работе с Git и рассмотрели модель Feature Branch Workflow. В данной статье мы рассмотрим еще одну популярную модель ветвления – Gitflow.
Данная статья является переводом англоязычной статьи из обучающих материалов Atlassian.
Модель ветвления Gitflow была впервые опубликована и стала популярной, благодаря статье Vincent Driessen. Она предполагает выстраивание строгой модели ветвления вокруг релиза проекта, которая дает надежную схему управления крупными проектами.
Gitflow отлично подходит для проектов, которые имеют спланированный цикл релиза. Эта модель не предполагает дополнительных понятий, кроме тех, что описаны для модели Feature Branch Workflow. Вместо этого она приписывает особые роли разным веткам и определяет, как и когда они должны взаимодействовать. Кроме feature-веток в ней используются отдельные ветки для подготовки, поддержки и записи релиза. Конечно, также необходимо эффективно использовать все преимущества Feature Branch Workflow: пул-реквесты, изоляция для изменений и эффективное сотрудничество внутри команды.
Gitflow использует собственный набор инструментов git-flow, который легко интегрируется с Git, добавляя новые команды Git.
Начало работы
Gitflow является методологией работы с Git. Это значит, она определяет, какие ветки нужно создать и как производить их слияние. Далее мы рассмотрим назначение веток. Набор инструментов git-flow нужно установить отдельно. Процесс его установки довольно понятный. Пакеты команд git-flow доступны во многих операционных системах. Для системы OSX можно выполнить brew install git-flow . Для Windows необходимо скачать и установить git-flow. После установки git-flow необходимо выполнить команду git flow init . Git-flow является оберткой для Git. Команда git flow init является расширением стандартной команды git init и ничего не меняет в вашем репозитории, кроме того, что создает ветки.
Как это работает
Ветки master и develop
Вместо использования одной ветки master, в этой модели используется две ветки для записи истории проекта. В ветке master хранится официальная история релиза, а ветка develop служит в качестве интеграционной ветки для новых функций. Также, удобно тегировать все коммиты в ветке master номером версии.
Первым шагом является создание ветки develop от ветки master. Проще всего это сделать одному разработчику, локально создав пустую ветку и отправив ее в центральный репозиторий:
В этой ветке будет находиться вся история проекта, в то время как master содержит частичную историю. Остальные разработчики теперь должны клонировать центральный репозиторий и создать отслеживающую ветку для ветки develop .
При использовании библиотеки расширений git-flow, для создания ветки develop можно выполнить git flow init в существующем репозитории:
Ветки для функций (feature branches)
Каждая новая функциональность должна разрабатываться в отдельной ветке, которую можно отправлять в центральный репозиторий для создания резервной копии/для совместной работы команды. Ветки функций создаются не на основе master , a на основе develop . Когда работа над новой функциональностью завершена, она вливается назад в develop. Новый код не должен отправляться напрямую в master.
Обратите внимание, что ветки функций объединяются с веткой develop как в модели Feature Branch Workflow. Но на этом работа по схеме Gitflow не заканчивается.
Создание ветки функции
Без использования расширений git-flow:
При использовании git-flow:
Далее, продолжайте работу c Git как обычно.
Окончание работы с веткой
По окончании разработки новой функциональности следующим шагом следует объединить ветку feature_branch c develop. Используйте команды:
Без использования расширений git-flow:
При использовании git-flow:
Ветки релиза
Когда в ветку develop уже слито достаточно нового кода для релиза (или подходит установленная дата предрелиза), от ветки develop создается ветка release . Создание данной ветки означает начало следующего цикла релиза, в ходе которой новая функциональность уже не добавляется, а производится только отладка багов, создание документации и решение других задач, связанных с релизом. Когда все готово, ветка release сливается в master , и ей присваивается тег с версией. Кроме этого, она должна быть также слита обратно в ветку develop , в которой с момента создания ветки релиза могли добавляться изменения с момента создания ветки релиза.
Использование отдельной ветки для подготовки релиза позволяет одной команде дорабатывать текущий релиз пока другая команда уже работает над функциональностью для следующего релиза. Это также позволяет разграничить этапы разработки (например, легко сказать: «На этой неделе мы готовимся к версии 4.0» и фактически увидеть это в структуре репозитория).
Создание веток релиза – это еще одна простая операция ветвления. Как и ветки функций, ветки релизов основаны на ветке develop . Новая ветка release может быть создана с использованием следующих команд:
Без использования расширений git-flow:
При использовании git-flow:
Когда релиз готов к отправке, он сливается в master и develop , а ветка релиза удаляется. Важно влить ее обратно в develop , поскольку в ветку release могут быть добавлены критические обновления, и они должны быть доступны для новых функций. Если ваша команда делает акцент на проверку кода, этот момент идеален для пул-реквеста.
Для завершения работы на ветке релиза, используйте следующие команды:
Без использования расширений git-flow:
Или при использовании git-flow:
Ветки hotfix
Ветки hotfix используются для быстрого внесения исправлений в рабочую версию кода. Ветки hotfix очень похожи на ветки release и feature , за исключением того, что они созданы от master , а не от develop . Это единственная ветка, которая должна быть создана непосредственно от master . Как только исправление завершено, ветка hotfix должна быть объединена как с master , так и с develop (или с веткой текущего релиза), а master должен быть помечен обновленным номером версии.
Наличие специальной ветки для исправления ошибок позволяет команде решать проблемы, не прерывая остальную часть рабочего процесса и не ожидая следующего цикла подготовки к релизу. Можно говорить о ветках hotfix как об особых ветках relese , которые работают напрямую с master . Ветка hotfix может быть создана с помощью следующих методов:
Без использования расширений git-flow:
Или при использовании git-flow:
Как и в работе с веткой release, ветка hotfix объединяется как с master , так и с develop .
Пример
Пример команд, демонстрирующий полный цикл работы с веткой функции, выглядит следующим образом. Предположим, что у нас есть репозиторий с веткой master .
Помимо ветки функции и release , приведем пример создания ветки hotfix :
Заключение
В этой статье мы рассмотрели модель работы Gitflow. Gitflow – это одна из многих моделей ветвления Git, которую можете использовать вы и ваша команда.
Ключевые идеи, которые нужно запомнить о Gitflow:
- Данная модель отлично подходит для организации рабочего процесса на основе релизов.
- Gitflow предлагает создание отдельной ветки для исправлений ошибок в продуктовой среде.
Последовательность работы при использовании модели Gitflow:
- Из master создается ветка develop .
- Из develop создаются ветки feature .
- Когда разработка новой функциональности завершена, она объединяется с веткой develop .
- Из develop создается ветка release .
- Когда ветка релиза готова, она объединяется с develop и master .
- Если в master обнаружена проблема, из нее создается ветка hotfix .
- Как только исправление на ветке hotfix завершено, она объединяется с develop и master .
Если статья вам понравилась и была для вас полезной, поделитесь ей с друзьями.