- Рабочий процесс Gitflow Workflow
- Что собой представляет Git-flow?
- Начало работы
- Порядок действий
- Ветка разработки и главная ветка
- Функциональные ветки (feature)
- Создание функциональной ветки
- Окончание работы с функциональной веткой
- Ветки выпуска (release)
- Ветки исправления (hotfix)
- Пример
- Резюме
- Git flow mac os
- Шпаргалка по git-flow
- Введение
- Общие замечания
- Установка
- macOS
- Linux
- Windows (Cygwin)
- Приступая к работе
- Инициализация
- Начало новой фичи
- Завершение фичи
- Публикация фичи
- Получение опубликованной фичи
- Создание релиза
- Начало релиза
- Завершение релиза
- Исправления
- git flow hotfix start
- Завершение исправления
- Команды
- Последние замечания
Рабочий процесс 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:
- Данная модель отлично подходит для организации рабочего процесса на основе релизов.
- Работа по модели Gitflow предусматривает создание специальной ветки для исправления ошибок в рабочем релизе.
Последовательность действий при работе по модели Gitflow:
- Из ветки main создается ветка develop .
- Из ветки develop создается ветка release .
- Из ветки develop создаются ветки feature .
- Когда работа над веткой feature завершается, она сливается в ветку develop .
- Когда работа над веткой release завершается, она сливается с ветками develop и main .
- Если в ветке main обнаруживается проблема, из main создается ветка hotfix .
- Когда работа над веткой hotfix завершается, она сливается с ветками develop и main .
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
Источник
Git flow mac os
A collection of Git extensions to provide high-level repository operations for Vincent Driessen’s branching model.
For the best introduction to get started with git flow , please read Jeff Kreeftmeijer’s blog post:
Or have a look at one of these screen casts:
If you’re on a Mac and use homebrew, it’s simple:
If you’re on a Mac and use MacPorts, it’s simple:
Another easy way to install git-flow is using Rick Osborne’s excellent git-flow installer, which can be run using the following command:
For Windows users who wish to use the automated install, it is suggested that you install Cygwin first to install tools like git , util-linux and wget (with those three being packages that can be selected during installation). Then simply run this command from a Cygwin shell:
This is much like the manual installation below, but there are additional steps required to install some extra tools that are not distributed with msysgit.
Clone the git-flow sources from Github:
Copy git-flow’s relevant files to your msysgit installation directory:
Next up we need to borrow a couple of binaries from Cygwin. If you don’t have Cygwin installed, please install it including the util-linux package. Apart from util-linux ‘s dependencies, no other packages are required. When you finished installation, copy the following files using msysgit’s Git Bash. We assume the Cygwin’s default installation path in C:\cygwin.
After copying the files above, you can safely uninstall your Cygwin installation by deleting the C:\cygwin directory.
If you prefer a manual installation, please use the following instructions:
Then, you can install git-flow , using:
By default, git-flow will be installed in /usr/local. To change the prefix where git-flow will be installed, simply specify it explicitly, using:
Or simply point your PATH environment variable to your git-flow checkout directory.
Installation note:
git-flow depends on the availability of the command line utility getopt , which may not be available in your Unix/Linux environment. Please use your favorite package manager to install getopt . For Cygwin, install the util-linux package to get getopt . If you use apt-get as your install manager, the package name is opt .
Integration with your shell
For those who use the Bash or ZSH shell, please check out the excellent work on the git-flow-completion project by bobthecow. It offers tab-completion for all git-flow subcommands and branch names.
For Windows users, msysgit is a good starting place for installing git.
See the FAQ section of the project Wiki.
Please help out
This project is still under development. Feedback and suggestions are very welcome and I encourage you to use the Issues list on Github to provide that feedback.
Feel free to fork this repo and to commit your additions. For a list of all contributors, please see the AUTHORS file.
Any questions, tips, or general discussion can be posted to our Google group: http://groups.google.com/group/gitflow-users
git-flow is published under the liberal terms of the BSD License, see the LICENSE file. Although the BSD License does not require you to share any modifications you make to the source code, you are very much encouraged and invited to contribute back your modifications to the community, preferably in a Github fork, of course.
To initialize a new repo with the basic branch structure, use:
This will then interactively prompt you with some questions on which branches you would like to use as development and production branches, and how you would like your prefixes be named. You may simply press Return on any of those questions to accept the (sane) default suggestions.
Creating feature/release/hotfix/support branches
To list/start/finish feature branches, use:
For feature branches, the arg must be a commit on develop .
To list/start/finish release branches, use:
For release branches, the arg must be a commit on develop .
To list/start/finish hotfix branches, use:
For hotfix branches, the arg must be a commit on master .
To list/start support branches, use:
For support branches, the arg must be a commit on master .
Showing your appreciation
A few people already requested it, so now it’s here: a Flattr button.
Of course, the best way to show your appreciation for the original blog post or the git-flow tool itself remains contributing to the community. If you’d like to show your appreciation in another way, however, consider Flattr’ing me:
Источник
Шпаргалка по 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-версии, использовать их не рекомендуется
Источник