что такое гит флоу
Шпаргалка по git-flow
эффективное ветвление с помощью git-flow от Vincent Driessen
Введение
git-flow — это набор расширений git предоставляющий высокоуровневые операции над репозиторием для поддержки модели ветвления Vincent Driessen. узнать больше
Эта шпаргалка показывает основные способы использования операций git-flow.
Общие замечания
Установка
macOS
Linux
Windows (Cygwin)
Вам потребуется wget и util-linux для установки git-flow.
Подробные инструкции по установке git flow смотрите на git flow wiki.
Приступая к работе
Git flow нужно инициализировать, чтобы настроить его для работы с вашим проектом.
Инициализация
Для начала использования git-flow проинициализируйте его внутри существующего git-репозитория:
Вам придётся ответить на несколько вопросов о способах именования ваших веток.
Рекомендуется оставить значения по умолчанию.
Начало новой фичи
Разработка новых фич начинается из ветки «develop».
Для начала разработки фичи выполните:
git flow feature start MYFEATURE
Это действие создаёт новую ветку фичи, основанную на ветке «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]
Желательно сразу публиковать ветку релиза после создания, чтобы позволить другим разработчиками выполнять коммиты в ветку релиза. Это делается так же, как и при публикации фичи, с помощью команды:
git flow release publish RELEASE
Вы также можете отслеживать удалённый релиз с помощью команды
git flow release track RELEASE
Завершение релиза
Завершение релиза — один из самых больших шагов в git-ветвлени. При этом происходит несколько действий:
git flow release finish RELEASE
Исправления
git flow hotfix start
Как и в случае с другими командами git flow, работа над исправлением начинается так:
git flow hotfix start VERSION [BASENAME]
Аргумент VERSION определяет имя нового, исправленного релиза.
При желании можно указать BASENAME-коммит, от которого произойдёт ответвление.
Завершение исправления
Когда исправление готово, оно сливается обратно в ветки «develop» и «master». Кроме того, коммит в ветке «master» помечается тегом с версией исправления.
git flow hotfix finish VERSION
Команды
Последние замечания
Кратко о git-flow
Git-flow — наиболее популярная методология разработки проектов с использованием git.
Зачем нам вообще нужны какие-то методологии для работы с git?
Дело в том, что сам git не привязывает нас к какому-либо определённому способу разработки, и каждый разработчик, в теории, может работать с контролем версий так, как он хочет. Чтобы в таких условиях не погрузить наш репозиторий в хаос, нам нужно придумать и донести до всех разработчиков некий единый стандарт для работы с контролем версий в проекте.
Git-flow даёт нам готовый стандарт проверенный временем и уже известный многим разработчикам.
В то же время, нужно понимать, что методология git-flow не является единственно верной и на 100% универсальной. В Вашем проекте может существовать собственный подход к работе с git. Однако, если вы работаете или собираетесь работать с git в команде, то стоит знать о том, что такое git-flow и в чём его особенности.
И так, что же нам стоит знать о git-flow?
Суть ветвления в git-flow
Всего в git-flow существует 5 типов веток, каждый из которых несёт определённую функциональную нагрузку.
Ветка develop
Ветка существует на протяжении всего процесса разработки. В данную ветку попадает стабильный код новых фич и багфиксов.
Тривиальные фичи, разработка которых умещается в один полноценный коммит, обычно идут прямо в эту ветку. Но те фичи, для реализации которых нужно уже несколько коммитов, выделяются в отдельные ветки feature-*.
Ветки feature-*
Временные ветки, которые создаются для каждой нетривиальной фичи.
Каждая ветка feature отделяется от develop и мержится обратно в него. После завершения работы над фичей и финального мержа в develop, ветка удаляется. При мерже ветки в develop не должен использоваться fast-forward (флаг –no-ff).
Имя ветки должно соответствовать имени разрабатываемой фичи, например “feature-gamecenter-integration”. В некоторых проектах префикс “feature-” опускается (тогда любая ветка без префикса — это ветка feature).
Ветка master
Ветка, куда поступают самые стабильные изменения, которые идут в релиз. Существует на протяжении всего процесса разработки.
В ветку master мержатся только изменения из веток release и hotfix. На каждый такой мерж создаётся тег с именем версии. Полный запрет использования fast-forward при мерже в ветку (флаг –no-ff).
По сути, в самой ветке не должно быть никаких коммитов, кроме коммитов мержей, каждый из которых должен быть отмечен тегом версии.
Ветки release-*
Временные ветки, создаваемые для подготовки новой версии к релизу. В эти ветки попадают правки багов и настройки перед релизом.
Ветка выходит из develop и может мержится в develop по ходу подготовки версии. Как только работа над версией заканчивается, происходит финальный мерж ветки в master и develop, после чего ветка удаляется, а коммиту мержа в master присваивается тег новой версии.
Имя ветки должно соответствовать выпускаемой версии, например “release-1.4”.
Ветки hotfix-*
Временные ветки hotfix-* создаются для правки критических проблем в релизной версии.
Ветка отходит от master и по завершению правок багов мержится обратно. Сама ветка после этого удаляется, а коммиту мержа в master присваивается тег новой версии.
Именем ветки обычно является новая версия с учётом версии фикса, например “hotfix-1.4.1” (первый хотфикс версии 1.4).
Подробнее про ветвление в git-flow можно узнать из оригинальной статьи автора методологии или из её перевода на русский язык.
Инстументы с поддержкой git-flow
По сути нам нет необходимости в каких-то особенных инструментах для поддержания процессов разработки, все действия могут быть выполнены из практически любой графической оболочки над git, либо из командной строки.
Однако, есть удобное расширение для git, которое позволяет немного ускорить ежедневную работу по данной методологиии за счёт уменьшения количества вводимых команд в консоли и работы непосредственно на уровне абстракций git-flow.
Так же, git-flow поддерживается из коробки некоторыми популярными графическими оболочками такими как SourceTree и SmartGit.
Как в случае консольного расширения, так и в случае графических клиентов, мы работаем с более понятными командами вроде “Start Feature” и “Finish Feature”, что позволяет проще смотреть на процесс разработки.
Git-flow и непрерывная интеграция
При разработке с использованием git-flow, одновременно существует две стабильные ветки, которые можно использовать для сборки билдов или выкладки кода на сервер: это ветки master и develop.
Сборки из ветки master можно собирать сразу по поступлении новых изменений. Любые новые правки в этой ветке — это стабильный production-код, который можно выкладывать на сервер (в случае разработки веб-ресурса) либо собирать в релизный бинарник.
Версии собранные из ветки master должны в обязательном порядке подвергаться всем существующим в проекте автоматизированным тестам.
Из ветки develop можно собирать ночные сборки (для тестирования) либо, по мере разработки, можно выкладывать код из этой ветки на тестовый сервер (в случае разработки веб-ресурса).
На версиях собранных из ветки develop следует прогонять unit-тесты.
Когда не стоит применять git-flow
Во первых, git-flow достаточно сложная методология, расчитанная на большие проекты. Если проект относительно небольшой и над ним работает команда всего из 3-4 человек, то применение git-flow может только усложнить процесс разработки.
Во вторых, git-flow в чистом виде применим только в тех случаях, когда в процессе разработки присутствует такое понятие как “релиз”. Если изменения публикуются в продакшн по мере разработки, то смысла применять git-flow тоже нет.
В обоих случаях, можно либо взять git-flow, отказавшись от некоторых типов веток (master, release, hotfix), либо выбрать другую методологию.
Рабочий процесс 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, изолированные эксперименты и эффективное командное взаимодействие.
Начало работы
Порядок действий
Ветка разработки и главная ветка
В этом рабочем процессе для регистрации истории проекта вместо одной ветки main используются две ветки. В главной ветке main хранится официальная история релиза, а ветка разработки develop предназначена для объединения всех функций. Кроме того, для удобства рекомендуется присваивать всем коммитам в ветке main номер версии.
При использовании библиотеки расширений git-flow, для создания ветки develop можно выполнить команду git flow init в существующем репозитории:
Функциональные ветки (feature)
Обратите внимание, что комбинация веток feature с веткой develop фактически представляет собой рабочий процесс с функциональными ветками. Но рабочий процесс Gitflow на этом не заканчивается.
Создание функциональной ветки
Без использования расширений git-flow:
С использованием расширений git-flow:
Продолжайте работу с Git как обычно.
Окончание работы с функциональной веткой
Без использования расширений git-flow:
С использованием расширений git-flow:
Ветки выпуска (release)
Благодаря тому, что для подготовки выпусков используется специальная ветка, одна команда может дорабатывать текущий выпуск, в то время как другая команда продолжает работу над функциями для следующего. Это также позволяет разграничить этапы разработки (например, можно без труда посвятить неделю подготовке к версии 4.0 и действительно увидеть это в структуре репозитория).
Без использования расширений git-flow:
При использовании расширений git-flow:
Для завершения работы в ветке release используйте следующие команды:
Без использования расширений git-flow:
Или при использовании расширений git-flow:
Ветки исправления (hotfix)
Без использования расширений git-flow:
При использовании расширений git-flow:
По завершении работы с веткой hotfix ее сливают с main и develop (как и в случае с веткой release ).
Пример
Далее показан полный цикл работы с функциональной веткой (предполагается, что у нас есть репозиторий с веткой main ).
Резюме
В этой статье мы рассмотрели модель работы Gitflow. Gitflow — лишь одна из многих методологий работы с Git, доступных вам и вашей команде.
Ключевые идеи, которые нужно запомнить о Gitflow:
Последовательность действий при работе по модели Gitflow:
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
Про Git, Github и Gitflow простыми словами
Не самое исчерпывающее, но точно вполне доходчивое руководство по Git, Github и Gitflow – для тех, кого эти слова смущают, хотя не должны.
Если вы не поняли Боромира, значит, зашли по адресу. С системами контроля версий должен уметь работать любой программист, даже если вы только учитесь.
Контроль версий помогает не только избежать досадных косяков при внесении изменений, но и необходим для командной работы над проектом. В этом материале мы рассмотрим основные команды для консоли и разберем самую популярную модель управления ветками проекта. И про ветки тоже поговорим.
Git – это распределенная система контроля версий (version control system – VCS).
Контроль версий означает что вы храните все версии редактируемых документов и можете вернуться к любой сохраненной версии в любой момент времени. Кажется, будто такой подход популярен только среди программистов, но на деле им пользуются, например, дизайнеры и другие люди, несколько более подкованные технически, чтобы контролировать изменения в работе.
Распределенность git’а отличает его от прочих vcs. Под распределенностью следует понимать, буквально, возможность использования одной системы контроля на проекте множеством разработчиков.
К слову, Git создал вот этот обходительный джентельмен:
Линус Торвальдс, создатель Git и Linux, передает привет Nvidia
С чего начнем?
Для начала, убедитесь, что у вас установлен Git.
Теперь, все что нам понадобится, чтобы создать репозиторий, это команда git init в нужном каталоге.
Откройте командную строку, и перейдите в Desktop (да, будем оригинальны), а там создайте каталог (например, proglib).
Теперь, проходим в новый каталог и выполняем git init.
Все, у нас есть пустой репозиторий.
Добавление файлов
Давайте создадим простой README.md файл, что-то вроде:
git status – простая команда, которая будет регулярно использоваться. Она показывает информацию о статусе проекта в git. Если вы выполните ее в каталоге proglib, будет видно, что файл README.md не отслеживается git’ом.
Если выпонить git status еще раз, мы увидим, что теперь в системе появился новый файл, который мы добавили.
Коммитим изменения
Чтобы закомминтить изменения в локальный репозиторий, просто напишите в командной строке:
Разумеется, в сообщении можно указать что угодно. Но пожалуйста, сделайте себе одолжение, и пишите вразумительные и ясные комментарии.
Пушим в удаленный репозиторий
Мы будем пушить изменения на Github, так что если у вас вдруг нет аккаунта, создайте его.
Нажмите кнопку Start a project и задайте проекту имя, остальные настройки можно оставить по умолчанию.
Ветки
Git делает ветвление очень простым. Допустим, мы находимся в мастер-ветке и хотим дописать функционал, основываясь на коде из этой ветки. Для этого нужно всего лишь написать команду для создания дополнительной ветки и провести всю работу там. А как закончите, замерджить (то есть, слить ветки) все обратно в мастер.
Внесите изменения в ваш README.md, сохраните их и используйте следующие команды, чтобы закоммитить изменения и замерджить их в мастер:
Теперь, когда вы знаете насколько просто работать с ветвлением, вас не удивит, что у многих людей своеобразный подход к управлению ветками.
Но есть один подход, который популярен в сообществе. Знакомьтесь, популярная модуль управления ветками Gitflow:
Схема выглядит беспорядочно, когда видишь ее впервые, так что пойдем по порядку. У нас есть две основные ветки: master и develop.
В ветке master содержится ровно тот же код, что и в рабочей (читай, продакт) версии проекта. А вся работа делается в ветке develop.
Во время работы на основе develop создаются так называемые feature-ветки. Их может быть неограниченное количество.
Далее, у нас есть ветка release, которая используется для подготовки к новому релизу проекта.
Наконец, есть ветка hotfix, которая служит для срочного исправления багов, найденных, например, на продакте.
Вот как в теории, происходит рабочий процесс в Gitflow:
1. Создается репозиторий
2. Репозиторий инициализируется
3. Начинается работа на ветке develop
4. Возникает необходимость опробовать новую штуку – создается feature-ветка и делаются коммиты
5. Закончив работу на feature-ветке, вы сливаете ее с develop
6. Если вы довольны текущей версией, но хотите продолжить работу, создается ветка release, куда перемещается текущая версия. Правка багов будет происходить на этой же ветке.
7. Когда с веткой release покончено, время слить ее в master и продолжить работу с develop
8. Кроме того, этот момент можно отметить на master-ветке
Gitflow как инструмент
Проделаем описанное выше шаг за шагом, но для начала убедитесь, что у вас есть gitflow-avh – инструмент для работы с Gitflow. На маке его можно установить с помощью homebrew:
gitflow-avh – это коллекция расширений для git, которая помогает избежать многих повторяющихся операций и вообще делает жизнь проще (это не точно). К примеру, при работе с feature-веткой, утилита проверит, слилась ли она в develop и удалит ее, если все прошло хорошо. Конечно, можно следовать модели Gitflow и самостоятельно, делая операции руками, но ведь проще же использовать готовое решение, так?
Как условие для начала работы, нам нужен git репозиторий. Если вы не начали читать статью с этого места, то у вас один уже есть. Теперь выполним команду git-flow init, как для git.
Далее будет несколько вопросов, но если оставить опции по умолчанию, эта команда просто создаст и назовет ветки в соответствие с моделью Gtiflow.
Когда все закончится, вы увидите, что находитесь на ветке develop. Теперь, создадим новую feature-ветку:
Затем, откроем README.md и внесем изменения. После, сделаем коммит:
Теперь, если мы всем довольны, закончим с этой веткой:
Как можно видеть в выводе в консоли, эта команда сделала следующее:
1. Слила ветки new_docs и develop
2. Удалила new_docs
3. Выполнила переход на ветку develop, чтобы можно было продолжать работу
Допустим, новая фича нас устраивает, она оттестирована и работает исправно. Теперь нам нужно сделать релиз.
Для начала, необходимо выполнить команду:
Здесь можно внести любые последние потенциальные исправления, обновить версию (имеет значение при разработке мобильных приложений) и так далее.
Когда работа закончена, просто напишем:
Вам нужно будет добавить несколько сообщений и меток, а потом утилита сделает следующее:
1. Сольет release и master
2. Пометит release как 2.0
3. Сольет release и develop
4. Удалит release
5. Выполнит переход на develop
Совместная работа
Иногда совместная работа напоминает классику:
На гитхабе вы можете добавить кого-то, кого вы знаете в сотрудники в настройках Settings-Collaborators. Приглашенные таким образом участники получат разрешение пушить в ваш репозиторий или вы можете создать команду разработчиков и регулировать уровни доступа от проекта к проекту.
Но даже если вы хорошо знаете человека, вам не всегда может понравится, что кто-то делает коммиты в мастер без вашего ведома. Для таких случаев в github сущестуют pull-request’ы и code review.
Работает это следующим образом: вы делаете какое-то улучшение или фикс на featire-ветке, делаете pull request, кто-то из старших разработчиков, курирующих проект смотрит ваш код (читай, делает code review), возможно, делает какие-то замечания и, в конечном итоге добавляет ваш код в мастер-ветку (или куда-то еще).
Выглядит неплохо, НО
На деле отношение к код ревью может быть разным. Буквально, от
И как же к относится к code review? Кончено, это очень важная штука и нужно иметь терпение и делать ревью всех пул реквестов, если речь идет о вашем проекте, например. В долгосрочной перспективе это окупится. И, конечно, легко сказать «just do it», но в некоторых случаях сложившиеся традиции в команде разработчиков могут заставить пересмотреть свое отношение к некоторым вещам.
Проверяем на практике
Создадим новую feature-ветку:
Повторим процесс изменения документа и создания коммита.
А теперь сделаем кое-что новенькое:
То есть, отправим пул-реквест. Если зайти на гитхаб, можно его увидеть.
Теперь, нажмите кнопку Compare & pull request:
Здесь можно добавить комментарий к пул-реквесту.
На этом моменте, кто-то из вашей команды должен прийти и проверить ваш код. Вы даже можете дать об этом знать кому следует через инструмент управления проектом, которым ваша команда пользуется (JIRA, Trello, Leankit, Kanbanflow, etc) добавив таск/карточку в соответствующую колонку.
Когда пул-реквест будет подтвержден, вы как автор, должны сделать следующее:
Вы увидите, что Github закрыл пул-реквест и удалил ветку.
И как бы то ни было, не стесняйтесь делать пул реквесты, если вам кажется, что ваш код недостаточно хорош: идеального кода не бывает.