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

эффективное ветвление с помощью git-flow от Vincent Driessen

Введение

git-flow — это набор расширений git предоставляющий высокоуровневые операции над репозиторием для поддержки модели ветвления Vincent Driessen. узнать больше

Эта шпаргалка показывает основные способы использования операций 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 -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-репозитория:

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

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

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

Разработка новых фич начинается из ветки «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» помечается тегом с версией исправления.

git flow hotfix finish VERSION

Команды

Последние замечания

• Здесь описаны не все доступные команды, только наиболее важные
• Вы можете продолжать использовать git и все его команды, как обычно, git flow — это просто набор дополнительных инструментов
• Возможности «support»-веток пока в beta-версии, использовать их не рекомендуется

Дмитрий [KP0H] Пелевин

Сохраняю тишину в голове

Про git flow в разработке

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

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

В качестве исторической справки отмечу, что git это распределенная система управления версиями, а была она изначально создана ни кем иным, как самим Линусом Торвальдсом (по ссылке можно посмотреть как старина Торвальдс фигачит код в ядро, как видно понедельники самые продуктивные дни Линуса) с целью управления разработкой ядра Linux и произошло это в уже не близком 2005 году.

Хватит лирики

В общем-то давайте к практике.

.gitignore

Git по умолчанию пытается отслеживать все файлы появляющиеся в папке (и подпапках) репозитория. Очевидно, что нет никакого смысла складывать в Git библиотеки, которые вероятно вы подтягиваете каким-нибудь менеджером пакетов или например всяческие obj, bin и прочие директории и файлы которые внезапно возникают вокруг вашего кода, но для самого кода ценности никакой не несут.

Именно для таких файлов существует такая штука как .gitignore, позволяющая объяснить git’у, что именно не нужно отслеживать. И, например, ваши Gui сразу же перестанут предлагать вам включить ненужные файлы в индекс, если вы пользуетесь не чистой консолью.

Типичные файлы .gitignore в зависимости от языка или среды разработки вы сможете найти на GitHub в соответствующем проекте.

Git Flow

«Си» позволяет очень просто выстрелить себе в ногу. На «Си++» сделать это сложнее, но, когда вам это удается, ногу отрывает полностью .

Фраза отца С++ в мире разработки характеризует многое. Собственно git это такая штука, которой стрелять в ногу можно бесконечно огромным количеством способом, зависящим в основном от вашей фантазии и психических отклонений.

Но умные люди в принципе уже придумали и описали наиболее типичные и простые в использовании с точки зрения владения кодом и управления способы.

Если кратко, то зовется это все Git Flow, и описано множество раз на просторах безграничного интернета.

Git-flow — это набор расширений git предоставляющий высокоуровневые операции над репозиторием для поддержки модели ветвления Vincent Driessen.

Установка Git flow

Для начала нужно иметь установленный git;

Если с Git все хорошо, то в зависимости от используемой операционной системы можно использовать следующие способы установить git flow.

OS X — Homebrew

OS X — Macports

Linux

Windows

Windows SourceTree

Данный клиент поддерживает Git Flow и позволяет весьма просто управлять им из Gui-интерфейса «из коробки».

Начало работы

Для начала git flow необходимо инициализировать, настроить его для работы с конкретным проектом, причем это нужно объяснить вашему локальному git, поэтому подобные махинации необходимо повторить на каждой машине разработчика (поправьте меня, если я не прав).

В общем для инициализации нужно использовать команду

В случае использования SourceTree все можно сделать из интерфейса (больше не буду отдельно упоминать SourceTree, по ссылке все достаточно подробно и полно).

Feature

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

Ветка типа Feature создается из основной ветки разработки (по умолчанию develop).

В наименовании фичи можно исходить из потребностей конкретно вашего процесса разработки. Может быть вам будет удобно использовать какой-нибудь идентификатор пользовательской истории из вашего трекера, а может краткое текстовое название. В итоге вы получите такую ветку feature/featurename.

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

• Выполнить слияние ветки фичи в ветку разработки (feature/featurename в develop в моем примере).
• Переключиться обратно в ветку разработки.
• Удалить ветки фичи.

Если работа над фичей идет совместно с коллегами — опубликуйте ёё на удаленном севере.

Соответственно чтобы получить кем-то опубликованную фичу необходимо выполнить

Можно отслеживать фичу в репозитории origin выполнив

Release

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

Для начала релиза

Где [BASE] вы можете указать при желании в виде sha-1 хеша коммита из которого нужно начать релиз. Этот коммит должен обязательно принадлежать ветки разработки.

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

И так же по аналогии для отслеживания нужно использовать

Завершение релиза один из наиболее сложных и важных шагов всего процесса ветвления в ходе которого происходят следующие действия:

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

Чтобы опубликовать тэги

Исправления

Исправления нам необходимы в том случае, когда требуется срочное изменение состояния продакшн-версии разрабатываемого продукта. Как вы понимаете она у нас находится в ветке master и помечена тэгом версии, соответственно мы ветвим hotfix от тега на ветке мастер.

Version — определяет имя нового исправленного релиза.

[Basename] — не обязательный аргумент, указывающий на коммит, от которого произойдет ветвление.

Завершение исправления выглядит так:

В этот момент оно сливается в ветки develop и master, коммит в ветке master помечается тегом с версией исправления.

Резюме

Выше приведены не все возможности и не все команды git-flow, кроме того использовать git со всеми его командами возможно и далее, т.к. git flow это просто набор инструментов упрощающих ветвление.

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

Думаю в ближайшее время подготовлю перевод этой статьи.

Если Вы нашли ошибку, пожалуйcта выделите ее и нажмите Shift + E или нажмите здесь чтобы информировать меня. Спасибо.

Рабочий процесс Gitflow Workflow

Gitflow Workflow — это модель рабочего процесса Git, которая была впервые опубликована и популяризована Винсентом Дриссеном из компании nvie. Gitflow Workflow предполагает выстраивание строгой модели ветвления с учетом выпуска проекта. Такая модель обеспечивает надежную основу для управления крупными проектами.

Gitflow идеально подходит для проектов, в которых цикл релиза протекает по графику. В этом рабочем процессе используются понятия и команды, которые были предложены в рамках процесса Feature Branch Workflow. Однако Gitflow привносит новые специфические роли для разных веток и определяет характер и частоту взаимодействия между ними. Помимо веток feature в рамках этого рабочего процесса используются отдельные ветки для подготовки, поддержки и регистрации выпусков. При этом вы по-прежнему можете пользоваться преимуществами процесса Feature Branch Workflow, такими как запросы pull, изолированные эксперименты и более эффективное командное взаимодействие.

Начало работы

Gitflow — это лишь методология работы с Git, то есть в ней определяется, какие виды веток необходимы проекту и как выполнять слияние между ними. Ниже мы познакомимся с назначением веток. Набор инструментов git-flow представляет собой отдельную командную строку, которая требует установки. Процесс установки прост. Пакеты команд git-flow доступны для многих операционных систем. В системах OSX можно выполнить команду brew install git-flow . Если вы используете Windows, вам нужно загрузить и установить git-flow. После установки git-flow необходимо выполнить команду git flow init , чтобы использовать его в проекте. Этот набор играет роль оболочки Git. Команда git flow init является расширением стандартной команды git init и не вносит изменений в ваш репозиторий помимо создания веток.

Порядок действий

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

Для фиксации истории проекта в рамках этого процесса вместо одной ветки master используются две ветки. В ветке master хранится официальная история релиза, а ветка develop предназначена для объединения всех функций. Кроме того, для удобства рекомендуется присваивать всем коммитам в ветке master номер версии.

Первый шаг рабочего процесса заключается в создании ветки develop от стандартной ветки master . Разработчику будет проще создать пустую ветку develop локально и отправить ее на сервер:

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

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

Функциональные ветки (feature)

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

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

Как правило, ветки feature создаются на основе последней ветки develop .

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

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

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

Продолжайте работу с Git как обычно.

Окончание работы с функциональной веткой

По завершении работы над функцией следует объединить ветку feature_branch с develop .

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

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

Ветки выпуска (release)

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

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

Создание веток release — это еще одна простая операция ветвления. Как и ветки feature , ветки release основаны на ветке develop . Создать новую ветку release можно с помощью следующих команд.

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

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

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

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

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

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

Ветки исправления (hotfix)

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

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

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

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

По завершении работы ветка hotfix , так же как и в случае с веткой release , объединяется с master и develop.

Пример

Далее продемонстрирован полный цикл работы с функциональной веткой (предположим, что у нас есть репозиторий с веткой master ).

Помимо работы с ветками feature и release , продемонстрируем работу с веткой hotfix :

Резюме

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

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

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

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

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

Рекомендуем продолжить обучение знакомством с моделью Forking Workflow. Или посетите нашу страницу сравнения рабочих процессов.

Готовы изучить Git?

Попробуйте это интерактивное учебное руководство.