Пожалуйста, перестаньте рекомендовать Git Flow
Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.
Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).
За последние десять лет бесчисленное множество команд пали жертвой этого громкого названия и оказались — не побоюсь этого слова — откровенно облапошены. В своей заметке автор утверждает, что они успешно внедрили эту модель в проекты, но умышленно не раскрывает подробности проектов, которые привели к этой «успешности».
И это главная ошибка тех, кто верит данной публикации. Общеизвестен факт, что не все стратегии работают во всех ситуациях, со всеми людьми, во всех контекстах. И я утверждаю, что та же логика применима и к этой модели ветвления.
На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне.
Git-flow изначально сложна и запутана
Модель Git-flow сложна даже в том случае, если на минуту забыть о микросервисах и непрерывной доставке (continuous delivery, CD). Посмотрите-ка на эту схему и рискните сказать, что она интуитивно понятна:
(источник)
Итак, мы имеем ветви функциональностей (feature), ветви релизов, master, develop, ветви исправлений (hotfix) и теги git. За всеми этими элементами необходимо следить, держать их в уме, учитывать в процессе сборки и выпуска.
Кроме того, нужно постоянно заострять внимание на том, что это за ветка и для чего она предназначена. Ментальная модель, которая требуется для реализации этого подхода, несет в себе высокую когнитивную нагрузку. Я пользуюсь git’ом уже 10 лет, но до сих пор не уверен, что смогу удержать в уме все нюансы происходящего.
Git-flow нарушает правило «короткоживущих» ветвей
В git’е число merge-конфликтов в ветке растет пропорционально числу людей, делающих коммиты в эту ветку. В случае Git-flow это число растет еще быстрее, потому что есть три других ветки (с разной продолжительностью жизни), которые сливаются в develop: ветви функциональностей, релизов и исправлений. Таким образом, потенциальное количество merge-конфликтов теперь минимум в три раза выше.
Я не склонен утверждать, что переживания по поводу merge-конфликтов являются веской причиной отказаться от стратегии ветвления вроде Git-flow, однако потенциальную сложность, связанную с появлением всех этих ветвей, невозможно игнорировать. Такой подход подошел бы для организации с низкой частотой коммитов, но для любой динамично развивающейся компании или стартапа он не пригоден.
С Git-flow придется забыть о rebase’ах
Признаю, что перебазирование — это многогранный вопрос, однако он важен для целей моего повествования. Сторонникам Git-flow придется отказаться от перебазирования: ведь оно происходит вместе со слиянием, в результате которого две ветви объединяются. А учитывая проблемы Git-flow с наглядностью, вам будет необходим способ визуально отслеживать ветви. Чтобы этим не заниматься, придется навсегда забыть о rebase.
Git-flow сильно усложняет непрерывную поставку
Continuous delivery — это практика, при которой разработчики выпускают обновления непосредственно в production (на самом деле, путем слияний с мастером) в автоматическом режиме. А теперь посмотрите на бардак, который творится в Git-flow, и объясните мне, как вы собираетесь проводить непрерывную доставку всего этого?
Вся модель ветвления основана на предсказуемом, долгосрочном цикле релиза новых версий, а не на выпуске нового кода каждые несколько минут или часов. Реализовать это слишком сложно, не говоря уже о принятой в CD практике накатывать исправления «на месте», в то время как Git-flow рассматривает исправления как отдельную сущность, которую необходимо бережно хранить, контролировать ее, держа отдельно от остальной работы.
В Git-flow невозможно работать с несколькими репозиториями
С появлением микросервисов начала набирать популярность и идея микрорепозиториев («Они ортогональны друг другу», — кричит мне суфлер). В ней отдельные команды контролируют свои репозитории и рабочие процессы, а также следят за тем, кто публикует код в их репозитории и как функционируют их workflows.
Вы когда-нибудь пробовали воспользоваться сложной моделью ветвления вроде Git-flow в условиях совместной работы нескольких команд? Получилось ли у вас добиться согласованности их действий? Сомневаюсь. Очень скоро система превращается в манифест различных ревизий разных репозиториев, и единственные, кто знают, где все лежит — это люди, которые пишут YAML-файлы для обновления манифестов. Если не соблюдать должную осторожность, то вопрос «Что у нас в production?» становится экзистенциальным.
Git-flow также не приспособлен для работы с единственным репозиторием
Если микрорепозитории не подходят из-за сложности с координацией релизов, почему бы не реализовать единый глобальный процесс ветвления, который все микросервисные команды будут использовать для релизов?
Увы, он просуществует всего несколько секунд — ровно столько, сколько требуется команде, чтобы сказать: «Это необходимо выпустить прямо сейчас» (хотя остальные команды вовсе не готовы к выпуску своих продуктов). В случае, когда команды работают независимо друг от друга, микросервисы также развертываются независимо, невозможно привязать рабочий процесс к централизованной модели ветвления, организованной в монорепе.
Кому подходит (и не подходит) Git-flow?
Если ваша компания придерживается месячного или квартального цикла выпуска ПО, а команда параллельно работает над несколькими релизами, то Git-flow может стать неплохим выбором. Для стартапа, сайта или веб-приложения со множеством релизов каждый день Git-flow не подходит. Если команда разработчиков невелика (менее 10 человек), то Git-flow вносит в ее работу слишком много церемоний и лишних движений.
С другой стороны, если команда насчитывает 20+ человек, работающих над параллельными релизами, то Gitflow обеспечивает достаточную структурированность, помогающую избежать путаницы.
Окей, моей команде Git-flow не подходит. Что нам использовать?
Я не могу ответить на этот вопрос. Каждая модель ветвления подходит для соответствующих команд, культур и условий. Сторонникам CD подходит модель, максимально упрощающая процесс. Кто-то обожает разработку на основе trunk’ов (trunk-based development) и переключатели функциональности (feature flags). Однако эти подходы до чертиков пугают меня сложностью тестирования.
Основная идея в том, чтобы подробно обсудить эту проблему со своей командой. Задайте ей следующие вопросы:
- Какие проблемы данная модель ветвления поможет нам решить?
- Какие проблемы она создаст?
- Какие подходы к разработке она стимулирует?
- Хотим ли мы этого?
В заключение хочу сказать, что изначально намеревался использовать в названии устойчивое выражение «considered harmful», столь привычное для публикаций подобного рода. Однако поиск в google показал, что кто-то уже использовал его для своей статьи о вредности Gitflow. Рекомендую ее почитать.
Бонус. Ответ nvie (Vincent Driessen)
На следующий день после этой публикации автор оригинала «A Successful Git branching model» (Vincent Driessen), на которую ссылается George Stocker, разместил ответ:
Несколько соображений (5 марта 2020)
Эта модель родилась в 2010 году — более 10 лет назад — практически сразу после того, как появился Git. За эти 10 лет Git-flow (модель ветвления, описанная в оригинальной статье) приобрела настолько высокую популярность у разработчиков, что ее начали рассматривать как своего рода стандарт — но, к сожалению, и как некую догму или панацею.
За эти 10 лет сам Git покорил весь мир, а наиболее распространенный тип программного обеспечения, разрабатываемого с помощью Git, все сильнее смещается в сторону веб-приложений — по крайней мере, таковы мои наблюдения. Как правило, веб-приложения разрабатываются в рамках подхода CD, не откатываются и не требуют поддержки нескольких одновременно запущенных версий ПО.
Это вовсе не тот класс ПО, который я имел в виду, когда писал свою статью десять лет назад. Командам, занимающимся непрерывной доставкой ПО, я бы рекомендовал использовать гораздо более простой рабочий процесс (вроде GitHub flow) вместо того, чтобы пытаться интегрировать Git-flow в свою работу.
В свою очередь, Git-flow может подойти командам, которые разрабатывают ПО с жестким версионированием или занимаются поддержкой нескольких версий приложения параллельно (Git-flow неплохо себя зарекомендовал на этом поприще за последние 10 лет). В этом случае рекомендую обратиться к оригинальной статье.
В заключение хочу напомнить вам, что панацеи не существует. Учитывайте свои условия, контекст и думайте своей головой!
P.S. Больше мнений по этой теме, конечно, можно найти на Hacker News и Reddit.
P.P.S. от переводчика
Читайте также в нашем блоге:
- «Мой любимый Git-коммит»;
- «Git happens! 6 типичных ошибок Git и как их исправить»;
- «Микросервисы: размер имеет значение, даже если у вас Kubernetes»;
- «Что же такое GitOps?»
Модель ветвления 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:
- Из master создается ветка develop .
- Из develop создаются ветки feature .
- Когда разработка новой функциональности завершена, она объединяется с веткой develop .
- Из develop создается ветка release .
- Когда ветка релиза готова, она объединяется с develop и master .
- Если в master обнаружена проблема, из нее создается ветка hotfix .
- Как только исправление на ветке hotfix завершено, она объединяется с develop и master .
Если статья вам понравилась и была для вас полезной, поделитесь ей с друзьями.
GitFlow процесс
В этой статье я хотел бы затронуть тему хранения кода в Git, контроля версий, релизов и в целом как этим всем управлять в команде.
Существует множество моделей хранения кода, но многие из них не имели место на существование заранее, так как решали довольно конкретные задачи, или не масштабировались, или были слишком неудобными, или вообще состояли из одной ветки. Судя из названия статьи, я хочу рассмотреть GitFlow модель в контексте того, как мы применяем ее на практике в нашем проекте.
GitFlow Workflow подробно описал еще в 2010 году Vincent Driessen в своем блоге. С тех пор прошло много времени, созданы более модные «магистральные» модели доставки. Их принято считать более простыми с точки зрения простоты доставки на прод, но я уверен — они подойдут не для всех проектов.
Что бы не быть просто «диванным специалистом» из интернета немного расскажу о себе. Я.Net программист, немного касающийся React, TypeScript (сейчас фронтовая разработка мне нравится больше), а так же тим лид команды в одной из федеральных фармацевтических компаний. У меня 14 лет коммерческого опыта разработки, в том числе создание облачных сервисов и программных продуктов для федеральных банков, фарм компаний, фондового рынка, иностранных компаний, гос органов и тд.
На этапе проектирования абсолютно нового проекта у нас, как раз, возник вопрос хранения кода. В такие моменты хочется сделать все идеально и поэтому мы погрузились в этот вопрос. Входные данные были не очень — в других проектах компании был Svn, мы были первой командой которая перетащит всю кодовую базу в Git (пора бы, как никак 2020 год был уже =)) и по началу мы решили сами выдумать модель версионирования (ее я рисовал в этой статье), но выдумка была сложной.
Почему GitFlow?
… выдумка была сложной. » — поэтому мы обратились к интернету — он все знает и ведает. GitFlow Workflow стал для нас оптимальной моделью.
- У нас было 12 разработчиков и мы часто пересекались в задачах друг с другом. Одной большой задачей могли заниматься до 3х человек, и без комита от каждого из них мы не могли заливать задачу в целом на тестирование — это попросту не имело смысла.
- У нас была не потоковая сдача функционала, а итеративная — двух‑трех недельная.
- У нас были задачи очень привязанные к сроку релиза в гос органах, то есть фича ветки могли просто лежать по месяцу без движения в прод.
- У нас попросту не была реализована эта потоковая доставка функционала на последующих этапах.
Что же такое GitFlow?
GitFlow — это определенная надстройка над моделью ветвления Git, которая включает в себя использование фича веток и несколько основных веток. По сравнению с разработкой на основе «магистрали», GitFlow имеет многочисленные, более долгоживущие ветки и более крупные фиксации. В рамках этой модели разработчики создают фича ветку и откладывают ее слияние с основной веткой до тех пор, пока функционал не будет завершен. Эти долгоживущие фича ветки требуют большего сотрудничества для слияния и имеют более высокий риск отклонения от ветви магистрали. Они также могут вводить противоречивые обновления.
Давайте рассмотрим схему веток и их взаимодействие межде друг другом из самого первоисточника, как это представлял сам автор.
В нашей версии модели начинают фигурировать еще и разработческие ветки, созданные от фича веток, то есть у фича веток может быть много разработческих ветвлений и существовать они будут до тех пор пока фича не сольется куда-то дальше по процессу.
feature/task-1 => dev/task-1/buzakov Но по сути, если отбросить все условности, то модель разработки GitFlow заключается между 2х постоянных веток:
- master (стабильно работающая или продакшен версия кода)
- develop (последняя или «nightly»-версия кода)
master branch (main branch)
После определенных событий в мире — ветку master переименовали в main.
main — это основная ветка кода, продакшен версия кода, то есть все сборки для реальных клиентов собирают как раз из этой ветки. Ветка может быть помечена тегами, в которых есть информация о версии и часто к тегу еще привязываются релизы. Любая новая задача взятая в работу начинается с мастер ветки. Немного позже, я раскрою наши поведенческие паттерны работы с веткой main.
Суть этой ветки хранить самую последнюю работоспособную версию кода.
develop branch
Я бы назвал эту ветку, как основная ветка кода для тестировщиков, но меня закидают камнями.
Исходя из практического опыта программисты не часто работают с этой веткой, а большую часть времени с ней проводят, как раз тестировщики анализирую функционал на работоспособность и наличие багов, а программеры просто сливают в нее новый код.
Суть этой ветки просто хранить в себе самую последнюю кодовую базу проекта.
Работа с ветками
Сейчас я бы хотел рассмотреть некоторые стандартные кейсы в GitFlow процессе разработки:
- Разработка нового функционала
- Исправление ошибки в новом функционале после тестирования
- Создание новой версии релиза
- Исправление критической ошибки на продакшене
Разработка нового функционала
Допустим у нас на проекте есть некая новая задача (MW-1234). Давайте рассмотрим этапы работы с этой задачей от взятия в работу и до релиза.
- Создаем фича ветку из main (main ⇒ feature/MW-1234). Если над этой задачей работают еще программисты, то я бы посоветовал от фича ветки создать еще разработческие ветки на каждого разраба (main ⇒ feature/MW-1234 ⇒ dev/MW-1234/buzakov). Это важно особенно в тех случая, когда ваш комит в фича ветку бесполезен без комитов других разработчиков.
- Разрабатываем функционал и заливаем комиты в фича ветку или разработческую ветку, созданную от фича ветки.
- Проверяем код и тестируем функционал в фича ветке.
- Создаем pull‑request в develop ветку.
- Когда тестировщики проверили функционал в дев ветке создаем релиз и мержим в мастер
- Выпускаем новую версию кода
main(tag: 0.1.0) => feature/mw-1234 => dev/mw-1234/buzakov => feature/mw-1234 => dev => release/0.1.1 => master(tag: 0.1.1) Исправление ошибки
Если тестировщик в процессе проверки задачи находит ошибки, то программист исправляет их в dev/mw-1234/buzakov ветке и заливает дальше по веткам, как при мерже веток в предыдущем варианте, то есть бранч менеджмент у нас такой:
dev/feature/mw-1234/buzakov => feature/mw-1234 => develop => дальше по процессу. Исправление критической ошибки
Ну вот мы и выпустили новую версию, посидели порадовались и поехали домой, но звонит начальник и говорит, что нашли критичную ошибку, а последний код уже в main ветке.
Мы создаем из main ветки hotfix («быстрофикс») ветку, то есть main ⇒ hotfix/error-123. Исправляем ее и заливаем комит в эту «быстрофикс ветку», тестируем еще раз, что не наломали еще больше дров и сливаем в main. Получается следующая схема:
main(tag: 0.1.1) => hotfix/error-123 => main (tag: 0.1.2)Хотфикс — залит в мастер.
Выводы
«GitFlow процесс очень трудоемкий и местами запутанный» — я соглашусь с многочисленными хейтерами оного, но он позволяет закрыть 2 пунка стабильности: 1. продакшен версия кода более стабильна, чем при водопадных слитиях; 2. тестовый стенд работает стабильнее, так как программисты сливают свой код в фича ветки, и случаев типа «Ой, я думал ты слил, а Я думал ты не слил уже» практически не бывает. При магистральных поставках осознанность и компетентность команды должна быть на высоком уровне, что в текущих реалиях вообще не возможно. За последний год у меня было 90 собеседований с программистами разного уровня паршивости — и я уже давно не встречал трушных программистов, которые имеют знания на высоком уровне.
В заключении этой статьи еще хочется напомнить поговорку «научи дурака молиться — он себе лоб расшибет». К чему это я? GitFlow, или магистралая доставка, или GitHub Flow, или еще тысяча другая подобных схем разработки и доставки кода на прод — все хорошо работают, не надо усложнять там где можно сделать проще и всегда думайте перед началом работы над новой задачей, но не упарывайтесь в бессоные ночи и поиски идеала.
В любой из перечисленных моделей разработки есть, как плюсы, так и минусы. Идеальная модель для большого проекта может совсем на подойти маленькому стартапу.
return 1; >
Шпаргалка по 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» помечается тегом с версией исправления.