Шпаргалка по 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 или нажмите здесь чтобы информировать меня. Спасибо.

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 отмечается тегом с версией исправления.