Для чего нужен gitflow

Шпаргалка по git-flow

Эта шпаргалка показывает основные способы использования операций git-flow.

Общие замечания

• Git flow предоставляет превосходную командную строку со справкой и улучшенными выводом. Внимательно читайте его, чтобы знать, что происходит.
• Клиент для macOS/Windows Sourcetree — отличный GUI для Git — также поддерживает git-flow
• Git-flow основан на слиянии. Для слияния веток фич не используется rebase.

Установка

• В первую очередь вам нужна рабочая установка git
• Git flow работает на macOS, Linux и Windows

macOS

$ brew install git-flow-avh

$ port install git-flow-avh

Linux

$ apt-get install git-flow

Windows (Cygwin)

$ wget -q -O — —no-check-certificate https://raw.github.com/petervanderdoes/gitflow-avh/develop/contrib/gitflow-installer.sh install stable | bash

Вам потребуется wget и util-linux для установки git-flow.

Подробные инструкции по установке git flow смотрите на git flow wiki.

Приступая к работе

Git flow нужно инициализировать, чтобы настроить его для работы с вашим проектом.

Инициализация

Для начала использования git-flow проинициализируйте его внутри существующего git-репозитория:

git flow init

Вам придётся ответить на несколько вопросов о способах именования ваших веток.
Рекомендуется оставить значения по умолчанию.

Фичи

• Разработка новых фич для последующих релизов
• Обычно присутствует только в репозиториях разработчиков

Начало новой фичи

Разработка новых фич начинается из ветки «develop».

Для начала разработки фичи выполните:

git flow feature start MYFEATURE

Это действие создаёт новую ветку фичи, основанную на ветке «develop», и переключается на неё.

Завершение фичи

Окончание разработки фичи. Это действие выполняется так:

• Слияние ветки MYFEATURE в «develop»
• Удаление ветки фичи
• Переключение обратно на ветку «develop»

git flow feature finish MYFEATURE

Публикация фичи

Вы разрабатываете фичу совместно с коллегами?
Опубликуйте фичу на удалённом сервере, чтобы её могли использовать другие пользователи.

git flow feature publish MYFEATURE

Получение опубликованной фичи

Получение фичи, опубликованной другим пользователем.

git flow feature pull origin MYFEATURE

Вы можете отслеживать фичу в репозитории origin с помощью команды git flow feature track MYFEATURE

Создание релиза

• Поддержка подготовки нового релиза продукта
• Позволяет устранять мелкие баги и подготавливать различные метаданные для релиза

Начало релиза

Для начала работы над релизом используйте команду git flow release Она создаёт ветку релиза, ответляя от ветки «develop».

git flow release start RELEASE [BASE]

При желании вы можете указать [BASE] -коммит в виде его хеша sha-1, чтобы начать релиз с него. Этот коммит должен принадлежать ветке «develop».

Желательно сразу публиковать ветку релиза после создания, чтобы позволить другим разработчиками выполнять коммиты в ветку релиза. Это делается так же, как и при публикации фичи, с помощью команды:

git flow release publish RELEASE

Вы также можете отслеживать удалённый релиз с помощью команды
git flow release track RELEASE

Завершение релиза

Завершение релиза — один из самых больших шагов в git-ветвлени. При этом происходит несколько действий:

• Ветка релиза сливается в ветку «master»
• Релиз помечается тегом равным его имени
• Ветка релиза сливается обратно в ветку «develop»
• Ветка релиза удаляется

git flow release finish RELEASE

Не забудьте отправить изменения в тегах с помощью команды git push —tags

Исправления

• Исправления нужны в том случае, когда нужно незамедлительно устранить нежелательное состояние продакшн-версии продукта
• Может ответвляться от соответствующего тега на ветке «master», который отмечает выпуск продакшн-версии

git flow hotfix start

Как и в случае с другими командами git flow, работа над исправлением начинается так:

git flow hotfix start VERSION [BASENAME]

Аргумент VERSION определяет имя нового, исправленного релиза.

При желании можно указать BASENAME-коммит, от которого произойдёт ответвление.

Завершение исправления

Когда исправление готово, оно сливается обратно в ветки «develop» и «master». Кроме того, коммит в ветке «master» помечается тегом с версией исправления.

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

git branch develop git push -u origin develop 

В этой ветке будет находиться вся история проекта, в то время как master содержит частичную историю. Остальные разработчики теперь должны клонировать центральный репозиторий и создать отслеживающую ветку для ветки develop .

При использовании библиотеки расширений git-flow, для создания ветки develop можно выполнить git flow init в существующем репозитории:

$ git flow init Initialized empty Git repository in ~/project/.git/ No branches exist yet. Base branches must be created now. Branch name for production releases: [master] Branch name for "next release" development: [develop] How to name your supporting branch prefixes? Feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix? [] $ git branch * develop master 

Ветки для функций (feature branches)

Каждая новая функциональность должна разрабатываться в отдельной ветке, которую можно отправлять в центральный репозиторий для создания резервной копии/для совместной работы команды. Ветки функций создаются не на основе master , a на основе develop . Когда работа над новой функциональностью завершена, она вливается назад в develop. Новый код не должен отправляться напрямую в master.

Обратите внимание, что ветки функций объединяются с веткой develop как в модели Feature Branch Workflow. Но на этом работа по схеме Gitflow не заканчивается.

Создание ветки функции

Без использования расширений git-flow:

git checkout develop git checkout -b feature_branch 

При использовании git-flow:

git flow feature start feature_branch 

Далее, продолжайте работу c Git как обычно.

Окончание работы с веткой

По окончании разработки новой функциональности следующим шагом следует объединить ветку feature_branch c develop. Используйте команды:

Без использования расширений git-flow:

git checkout develop git merge feature_branch 

При использовании git-flow:

git flow feature finish feature_branch 

Ветки релиза

Когда в ветку develop уже слито достаточно нового кода для релиза (или подходит установленная дата предрелиза), от ветки develop создается ветка release . Создание данной ветки означает начало следующего цикла релиза, в ходе которой новая функциональность уже не добавляется, а производится только отладка багов, создание документации и решение других задач, связанных с релизом. Когда все готово, ветка release сливается в master , и ей присваивается тег с версией. Кроме этого, она должна быть также слита обратно в ветку develop , в которой с момента создания ветки релиза могли добавляться изменения с момента создания ветки релиза.

Использование отдельной ветки для подготовки релиза позволяет одной команде дорабатывать текущий релиз пока другая команда уже работает над функциональностью для следующего релиза. Это также позволяет разграничить этапы разработки (например, легко сказать: «На этой неделе мы готовимся к версии 4.0» и фактически увидеть это в структуре репозитория).

Создание веток релиза – это еще одна простая операция ветвления. Как и ветки функций, ветки релизов основаны на ветке develop . Новая ветка release может быть создана с использованием следующих команд:

Без использования расширений git-flow:

git checkout develop git checkout -b release/0.1.0 

При использовании git-flow:

$ git flow release start 0.1.0 Switched to a new branch 'release/0.1.0' 

Когда релиз готов к отправке, он сливается в master и develop , а ветка релиза удаляется. Важно влить ее обратно в develop , поскольку в ветку release могут быть добавлены критические обновления, и они должны быть доступны для новых функций. Если ваша команда делает акцент на проверку кода, этот момент идеален для пул-реквеста.

Для завершения работы на ветке релиза, используйте следующие команды:

Без использования расширений git-flow:

git checkout develop git merge release/0.1.0 

Или при использовании git-flow:

git checkout master git checkout merge release/0.1.0 git flow release finish '0.1.0' 

Ветки hotfix

Ветки hotfix используются для быстрого внесения исправлений в рабочую версию кода. Ветки hotfix очень похожи на ветки release и feature , за исключением того, что они созданы от master , а не от develop . Это единственная ветка, которая должна быть создана непосредственно от master . Как только исправление завершено, ветка hotfix должна быть объединена как с master , так и с develop (или с веткой текущего релиза), а master должен быть помечен обновленным номером версии.

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

Без использования расширений git-flow:

git checkout master git checkout -b hotfix_branch 

Или при использовании git-flow:

$ git flow hotfix start hotfix_branch 

Как и в работе с веткой release, ветка hotfix объединяется как с master , так и с develop .

git checkout master git merge hotfix_branch git checkout develop git merge hotfix_branch git branch -D hotfix_branch $ git flow hotfix finish hotfix_branch 

Пример

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

git checkout master git checkout -b develop git checkout -b feature_branch # работа ведется на ветке feature git checkout develop git merge feature_branch git checkout master git merge develop git branch -d feature_branch 

Помимо ветки функции и release , приведем пример создания ветки hotfix :

git checkout master git checkout -b hotfix_branch # работа сделана, коммиты добавлены в hotfix_branch git checkout develop git merge hotfix_branch git checkout master git merge hotfix_branch 

Заключение

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

Ключевые идеи, которые нужно запомнить о Gitflow:

• Данная модель отлично подходит для организации рабочего процесса на основе релизов.
• Gitflow предлагает создание отдельной ветки для исправлений ошибок в продуктовой среде.

Последовательность работы при использовании модели Gitflow:

1. Из master создается ветка develop .
2. Из develop создаются ветки feature .
3. Когда разработка новой функциональности завершена, она объединяется с веткой develop .
4. Из develop создается ветка release .
5. Когда ветка релиза готова, она объединяется с develop и master .
6. Если в master обнаружена проблема, из нее создается ветка hotfix .
7. Как только исправление на ветке hotfix завершено, она объединяется с develop и master .

Если статья вам понравилась и была для вас полезной, поделитесь ей с друзьями.

GIT FLOW ЧТО ЭТО И ЗАЧЕМ ��

Итак многие из нас используют Git но зачем нам следовать Git Flow, все просто мы не можем заливать все изменения в master, это не безопасно, поэтому нам нужен более безопасный способ, для этого нам нужен регламент Git Flow.

Поэтому все новые фичи делают в новых ветках (new_feature ), но перед тем как их залить в master их же нужно протестировать.

Для этого их отправляют в ветку dev, где они происходит первичное тестирование и далее ожидают создание ближайшей релизной ветки (release_202201) куда будут отправлены все новые фичи-ветку прошедшие тестирование включая нашу.

Собрав все новые фичи ветки release ветке, их начинают детально тестировать в среде похожей на основной сервер ( так как release ветка создавалось от master ветке ) и если там все хорошо, её сливают уже с master веткой.

Вот такой круговорот проходят наша новая фича чтобы оказаться доступных для конечных пользователей по Git Flow.

���� Зачем нужен git flow?

Git Flow используется для управления рабочим процессом разработки в Git. Он предоставляет набор правил и хорошо определенные ветки, которые упрощают совместную работу над проектом. Git Flow включает в себя две основные ветки: master и develop. Ветка master содержит стабильный и готовый к внедрению код. Ветка develop является основной веткой разработки, где добавляются новые функциональности. В Git Flow также предусмотрены специальные ветки для разработки новых функций (feature), исправления ошибок (bugfix), подготовки к релизу (release) и т.д. Вот примеры команд Git Flow:

git flow feature start new-feature

git flow feature finish new-feature

git flow release start 1.0

git flow release finish 1.0

Детальный ответ

Зачем нужен git flow

Git flow — это гибкая методология для организации рабочего процесса с Git репозиторием. Она предлагает определенную структуру и набор правил для эффективного управления версиями кода в больших командах разработчиков. Git flow помогает в поддержке стабильности, управлении ошибками и новыми функциональностями, а также в упрощении процесса разработки, релиза и поддержки продукта.

Ключевые особенности Git flow

• Feature branches — ветви для добавления новых функциональностей. Каждая новая функциональность разрабатывается в отдельной ветви, которая ветвится от ветви develop. После завершения работы над функциональностью, она интегрируется обратно в ветвь develop.
• Release branches — ветви для подготовки к выпуску новой версии продукта. Каждый новый релиз создается в отдельной ветви, которая ветвится от ветви develop. В ветви релиза производятся окончательные тесты и исправление ошибок перед выпуском стабильной версии.
• Hotfix branches — ветви для исправления ошибок в стабильной версии продукта. Если обнаруживается критическая ошибка, создается отдельная ветвь, которая ветвится от ветви master. После исправления ошибки, изменения интегрируются и в ветвь develop, и в ветвь master.

Преимущества использования Git flow

Использование Git flow принесет несколько преимуществ разработчикам и командам:

• Четкая организация работы: Упорядоченная структура ветвей позволяет разработчикам ясно видеть, какие изменения находятся в процессе разработки, какие уже готовы для релиза и какие исправления ошибок требуют внимания.
• Стабильные релизы: Использование отдельных ветвей для подготовки релизов позволяет проводить окончательные тесты и релизы без вмешательства изменений, которые еще находятся в разработке.
• Исправление ошибок: Ветви для исправления ошибок делают процесс их решения структурированным и контролируемым. Исправления могут быть легко интегрированы в стабильную и разрабатываемую версии кода.
• Эффективная разработка функциональностей: Создание отдельных ветвей для разработки новых функциональностей позволяет командам работать над различными возможностями независимо друг от друга. Разрыв между ветвями позволяет командам легко контролировать и интегрировать изменения.
• История изменений: Git сохраняет информацию о всех ветвях и слияниях, делая историю изменений прозрачной и отслеживаемой. Это полезно для отслеживания разработки и управления кодом.
• Легкая масштабируемость: Git flow позволяет разработчикам масштабировать процесс разработки и выпускать новые версии продукта с минимальными проблемами интеграции изменений.

Пример использования Git flow:

git flow feature start my-feature git flow feature finish my-feature git flow release start 1.0.0 git flow release finish 1.0.0 git flow hotfix start hotfix-1.0.1 git flow hotfix finish hotfix-1.0.1

Git flow — это мощный инструмент для эффективного управления версиями кода. Он помогает организовать рабочий процесс, повысить стабильность и упростить разработку, релиз и поддержку продукта. При использовании Git flow разработчики могут более эффективно работать в больших командах и достичь успешного выполнения проекта.