Пожалуйста, перестаньте рекомендовать 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, разместил ответ:
Эта модель родилась в 2010 году — более 10 лет назад — практически сразу после того, как появился Git. За эти 10 лет Git-flow (модель ветвления, описанная в оригинальной статье) приобрела настолько высокую популярность у разработчиков, что ее начали рассматривать как своего рода стандарт — но, к сожалению, и как некую догму или панацею.
За эти 10 лет сам Git покорил весь мир, а наиболее распространенный тип программного обеспечения, разрабатываемого с помощью Git, все сильнее смещается в сторону веб-приложений — по крайней мере, таковы мои наблюдения. Как правило, веб-приложения разрабатываются в рамках подхода CD, не откатываются и не требуют поддержки нескольких одновременно запущенных версий ПО.
Это вовсе не тот класс ПО, который я имел в виду, когда писал свою статью десять лет назад. Командам, занимающимся непрерывной доставкой ПО, я бы рекомендовал использовать гораздо более простой рабочий процесс (вроде GitHub flow) вместо того, чтобы пытаться интегрировать Git-flow в свою работу.
В свою очередь, Git-flow может подойти командам, которые разрабатывают ПО с жестким версионированием или занимаются поддержкой нескольких версий приложения параллельно (Git-flow неплохо себя зарекомендовал на этом поприще за последние 10 лет). В этом случае рекомендую обратиться к оригинальной статье.
В заключение хочу напомнить вам, что панацеи не существует. Учитывайте свои условия, контекст и думайте своей головой!
GitHub Flow
Увидев в очередной раз базворд GitFlow я психанул и решил перевести описание более простой и менее проблемной схемы работы с ветками под названием GitHub Flow. Именно её имеет смысл использовать по умолчанию, переходя к какой-то другой лишь в случае непреодолимых обстоятельств.
Создайте ветвь
Пока вы работаете над одним проектом, у вас может быть куча различных реализуемых параллельно улучшений. Некоторые из них готовы к работе, а другие — нет. Ветвление позволяет вам управлять этим рабочим процессом.
Ветвление — это основное понятие в git. Весь GitHub Flow основан именно на нем и согласно ему есть только одно правило: всё, что находится в стволе — гарантированно стабильно и готово к деплою в любой момент.
Фиксируйте изменения
Создав ветвь, начинайте вносить в неё изменения. Добавляя, редактируя или удаляя файлы, не забывайте делать новые фиксации (commits) в ветви. Последовательность фиксаций образует в конечном счёте прозрачную историю работы над вашей задачей, по которой остальные смогут понять что вы делали и почему.
У каждой фиксации есть связанное сообщение, являющееся объяснением, почему было сделано то или иное изменение. Также каждая фиксация считается отдельной единицей изменения. Это позволяет откатить изменения, если обнаружилась ошибка, или если вы решите пойти в другом направлении.
Внятное описание фиксации очень важно, так как позволяет остальным разработчикам сразу понять ваши намерения и оценить насколько внесённые изменения им соответствуют. А значит обратная связь от них придёт быстрее и окажется полезней.
Вливайте изменения из ствола в свою ветвь как можно чаще, чтобы она всегда оставалась актуальной и готовой к обратному слиянию. Разрешение возможных конфликтов слияния — право и обязанность разработчика ветви, так как именно он лучше всего знает зафиксированные в ней изменения.
Откройте запрос на слияние
Вы можете открыть запрос на слияние в любой момент процесса разработки:
Используя систему @упоминаний GitHub в сообщении запроса на слияние, вы можете запросить обратную связь от конкретных людей или целых команд, будь то сосед по офису или кто-то в десяти часовых поясах от вас.
Запросы на слияние полезны не только в рамках одного репозитория, но и как инструмент переноса кода между форками. Просто создайте запрос на слияние ветви из одного репозитория в ветвь из другого и действуйте дальше.
Проверьте и обсудите код
После открытия запроса на слияние команда рассматривает изменения, задавая вопросы и оставляя комментарии. Возможно стиль кодирования не соответствует принятому соглашению. Возможно отсутствуют модульные тесты. А возможно все выглядит хорошо и не вызывает нареканий. Запросы предназначены фокусировки обсуждения именно на предлагаемых изменениях и группировки вместе с ними.
Конечно вы можете продолжать пополнять ветку обновлениями в свете возникшего обсуждения. Если вам указывают, что вы забыли что-то сделать или в коде есть ошибка, вы можете исправить это в своей ветке и протолкнуть (push) на сервер. GitHub покажет ваши новые фиксации и любую дополнительную обратную связь на них всё в том же унифицированном представлении запроса на слияние.
В комментариях к запросу на слияние можно использовать markdown размету, что позволяет вставлять изображения и смайлики, использовать предварительно отформатированные текстовые блоки и другое облегченное форматирование.
Проверьте в бою
Вливайте
При слиянии в стволе создаётся фиксация со всеми изменениями из ветки. Как и любые другие фиксации, она доступна для поиска и «перемещения во времени».
А если частые релизы невозможны?
Если вы не практикуете непрерывную поставку (Continous Delivery), то вам может быть сложно доводить до ствола каждую ветвь по отдельности. В этом случае просто создавайте интеграционный ветви, куда вливайте лишь те ветви, что считаете готовыми. Если изменения одной из ветвей вызовут проблемы, то интеграционную ветвь всегда можно будет пересобрать заново, но уже не включая проблемную. Это позволит вам не срывать график релизов, даже если какие-либо из планируемых задач оказались не до конца готовы к запланированной дате.
В чём отличие от GitFlow?
В GitFlow у вас есть дополнительная ветвь develop куда сливаются все разрабатываемые в текущий момент ветви. develop необходимо «стабилизировать» перед релизом, что часто приводит либо к переносу релиза, либо «релизу с замечаниями».
В чём отличие от GitLab Flow?
Про 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 закрыл пул-реквест и удалил ветку.
И как бы то ни было, не стесняйтесь делать пул реквесты, если вам кажется, что ваш код недостаточно хорош: идеального кода не бывает.
