Рабочий процесс 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?
Ознакомьтесь с этим интерактивным обучающим руководством.
GitHub Flow
Увидев в очередной раз базворд GitFlow я психанул и решил перевести описание более простой и менее проблемной схемы работы с ветками под названием GitHub Flow. Именно её имеет смысл использовать по умолчанию, переходя к какой-то другой лишь в случае непреодолимых обстоятельств.
Создайте ветвь
Пока вы работаете над одним проектом, у вас может быть куча различных реализуемых параллельно улучшений. Некоторые из них готовы к работе, а другие — нет. Ветвление позволяет вам управлять этим рабочим процессом.
Ветвление — это основное понятие в git. Весь GitHub Flow основан именно на нем и согласно ему есть только одно правило: всё, что находится в стволе — гарантированно стабильно и готово к деплою в любой момент.
Фиксируйте изменения
Создав ветвь, начинайте вносить в неё изменения. Добавляя, редактируя или удаляя файлы, не забывайте делать новые фиксации (commits) в ветви. Последовательность фиксаций образует в конечном счёте прозрачную историю работы над вашей задачей, по которой остальные смогут понять что вы делали и почему.
У каждой фиксации есть связанное сообщение, являющееся объяснением, почему было сделано то или иное изменение. Также каждая фиксация считается отдельной единицей изменения. Это позволяет откатить изменения, если обнаружилась ошибка, или если вы решите пойти в другом направлении.
Внятное описание фиксации очень важно, так как позволяет остальным разработчикам сразу понять ваши намерения и оценить насколько внесённые изменения им соответствуют. А значит обратная связь от них придёт быстрее и окажется полезней.
Вливайте изменения из ствола в свою ветвь как можно чаще, чтобы она всегда оставалась актуальной и готовой к обратному слиянию. Разрешение возможных конфликтов слияния — право и обязанность разработчика ветви, так как именно он лучше всего знает зафиксированные в ней изменения.
Откройте запрос на слияние
Вы можете открыть запрос на слияние в любой момент процесса разработки:
Используя систему @упоминаний GitHub в сообщении запроса на слияние, вы можете запросить обратную связь от конкретных людей или целых команд, будь то сосед по офису или кто-то в десяти часовых поясах от вас.
Запросы на слияние полезны не только в рамках одного репозитория, но и как инструмент переноса кода между форками. Просто создайте запрос на слияние ветви из одного репозитория в ветвь из другого и действуйте дальше.
Проверьте и обсудите код
После открытия запроса на слияние команда рассматривает изменения, задавая вопросы и оставляя комментарии. Возможно стиль кодирования не соответствует принятому соглашению. Возможно отсутствуют модульные тесты. А возможно все выглядит хорошо и не вызывает нареканий. Запросы предназначены фокусировки обсуждения именно на предлагаемых изменениях и группировки вместе с ними.
Конечно вы можете продолжать пополнять ветку обновлениями в свете возникшего обсуждения. Если вам указывают, что вы забыли что-то сделать или в коде есть ошибка, вы можете исправить это в своей ветке и протолкнуть (push) на сервер. GitHub покажет ваши новые фиксации и любую дополнительную обратную связь на них всё в том же унифицированном представлении запроса на слияние.
В комментариях к запросу на слияние можно использовать markdown размету, что позволяет вставлять изображения и смайлики, использовать предварительно отформатированные текстовые блоки и другое облегченное форматирование.
Проверьте в бою
Вливайте
При слиянии в стволе создаётся фиксация со всеми изменениями из ветки. Как и любые другие фиксации, она доступна для поиска и «перемещения во времени».
А если частые релизы невозможны?
Если вы не практикуете непрерывную поставку (Continous Delivery), то вам может быть сложно доводить до ствола каждую ветвь по отдельности. В этом случае просто создавайте интеграционный ветви, куда вливайте лишь те ветви, что считаете готовыми. Если изменения одной из ветвей вызовут проблемы, то интеграционную ветвь всегда можно будет пересобрать заново, но уже не включая проблемную. Это позволит вам не срывать график релизов, даже если какие-либо из планируемых задач оказались не до конца готовы к запланированной дате.
В чём отличие от GitFlow?
В GitFlow у вас есть дополнительная ветвь develop куда сливаются все разрабатываемые в текущий момент ветви. develop необходимо «стабилизировать» перед релизом, что часто приводит либо к переносу релиза, либо «релизу с замечаниями».
В чём отличие от GitLab Flow?
Пожалуйста, перестаньте рекомендовать 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 лет). В этом случае рекомендую обратиться к оригинальной статье.
В заключение хочу напомнить вам, что панацеи не существует. Учитывайте свои условия, контекст и думайте своей головой!
Шпаргалка по 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
Команды
Последние замечания
GitHub Flow: рабочий процесс Гитхаба
Захватывающе интересная статья одного из разработчиков о принятом в компании рабочем процессе потребовала употребить пару специальных терминов при переводе.
То понятие, для которого на английском языке достаточно одного слóва на русский приходится переводить словосочетанием — Ничего лучше не знаю ни сам я, ни при помощи так что и мне, и читателям придётся с этим мириться, хотя бы и поневоле.
Другое понятие, «deploy», на русский часто переводят словом «развёртывание», но в моём переводе я решил вспомнить оборот из советского делопроизводства — «внедрение инноваций и стану говорить именно новых фич. Дело в том, что описанный ниже рабочий процесс не имеет «выпусков» (releases), что делает несколько неудобными и речи
К сожалению, некоторые переводчики бывают склонны грубо убивать сочную метафору «иньекции» (или даже «впрыскивания», если угодно), содержающуюся в термине так что и его также переводят словосочетанием Эта путаница огорчает меня, но ничего не могу поделать. Просто имейте в виду, что здесь «внедрением кода» я стану назвать внедрение его именно в производство (на продакшен), а не чужой код.
Я стремился употреблять словосочетание «в Гитхабе» в значении «в компании GitHub Inc.», в значении «на сайте Правда, иногда разделять их сложновато.
Проблемы git-flow
Повсюду путешествую, преподавая Git людям — и почти на каждом уроке и семинаре, недавно мною проведённом, меня спрашивали, что я думаю Я всегда отвечал, что думаю, что этот подход великолепен — он взял систему (Git), для которой могут существовать мириады возможных рабочих процессов, и задокументировал один проверенный и гибкий процесс, который для многих разработчиков годится при довольно простом употреблении. Подход этот также становится стандарта, так что разработчики могут переходить от проекта к проекту и из компании в компанию, оставаясь знакомыми с этим стандартизированным рабочим процессом.
Однако и у git-flow есть проблемы. Я не раз слыхал мнения людей, выражавших неприязнь к тому, что ветви фич отходят или к манере обращения с хотфиксами, но эти проблемы сравнительно невелики.
Для меня одной из более крупных проблем стала его сложность — бóльшая, чем на самом деле требуется большинству разработчиков и рабочих групп. Его сложность ужé привела к появлению для поддержания рабочего процесса. Само по себе это круто, но проблема в том, что помощник работает не из GUI Git, а из командной строки, и получается, что те самые люди, которым необходимо действительно хорошо выучить сложный рабочий процесс, потому что им вручную придётся пройти все шаги его — людей система и недостаточно удобна для того, чтобы использовать её из командной строки. Вот что становится крупною проблемою.
Все эти проблемы можно без труда преодолеть, следуя гораздо более простому рабочему процессу. Мы не пользуемся в Гитхабе. Наш рабочий процесс основан (и всегда был основан) на более простом подходе к Git.
Простота его имеет несколько достоинств. людям проще понять его, так что они быстрее начинают использовать его, реже (или вовсе никогда не) допускают ошибки, требующие отката. Кроме того, не требуется помогающий следовать процессу, так что употребление GUI не создаёт проблем.
Рабочий процесс Гитхаба
Итак, почему мы в Гитхабе не используем Главная проблема в том, что у нас принято беспрестанное внедрение изменений. Рабочий процесс создавался в основном в помощь «выпускам» нового кода. А у нас нет «выпусков», потому что код поступает (основной рабочий сервер) ежедневно — иногда по нескольку раз в день. Мы можем подавать для этого команды боту в той же в которой отображаются итоги CI (интеграционного тестирования). Мы стремимся сделать процесс тестирования кода и его внедрения как можно проще, чтобы каждому сотруднику он был удобен в работе.
У такого частого внедрения новинок есть ряд достоинств. Если оно случается каждые несколько часов, то почти невозможно возникнуть большому количеству крупных багов. Небольшие недочёты случаются, но они могут быть исправлены (а исправления, в свою очередь, внедрены) очень быстро. Обычно пришлось бы делать «хотфикс» отступать от нормального процесса, но для нас это становится просто частью нормального процесса: в рабочем процессе Гитхаба нет разницы между хотфиксом и небольшою фичею.
Другим достоинством беспрерывного внедрения изменений становится возможность быстро отреагивать на проблемы любого рода. Мы можем откликаться на сообщения о проблемах с безопасностью или исполнять небольшие (но интересные) просьбы о новых фичах — но тот же самый процесс работает и при внесении изменений, связанных с разработкою фичи нормального (или даже крупного) размера. Процесс один и тот же и он очень прост.
Как мы это делаем
Итак, каков рабочий процесс Гитхаба?
Итак, давайте по порядку рассмотрим каждый шаг.
Содержимое ветви master всегда работоспособно (deployable)
В общем-то это единственное жёсткое правило во всей системе. Есть только одна ветвь, имеющая всегда некоторое особенное значение, и её мы назвали master. Для нас это значит, что код этой ветви либо внедрён на продакшен, либо, в худшем случае, окажется внедрён в течение нескольких часов. Эта ветвь очень редко подвергается откручиванию на несколько коммитов назад (для отмены работы): если возникает проблема, то отменяются изменения из коммитов или совершенно новые коммиты исправляют проблему, но сама ветвь почти никогда назад не откручивается.
Ветвь master стабильна. Внедрение её кода на продакшен или создание новых ветвей на её основе — это всегда, всегда безопасно. Если от вас поступает неоттестированный код или он ломает сборку, то вы нарушили «общественный договор» команды разработчиков и у вас на душé должны кошки поскрести по этому поводу. Каждая ветвь подвергается у нас тестированию, а итоги поступают так что, если вы не тестировали её локально, то можете запушить ветвь (даже с единственным коммитом) на сервер и подождать, пока Jenkins не сообщит, все ли тесты успешно пройдены.
Ответвляйте новые ветви, имена которых соответствуют предназначению
Когда хотите поработать ответвляйте от стабильной новую ветвь, имя которой соответствует предназначению. (Например, в коде Гитхаба прямо сейчас есть ветви Такое наименование имеет несколько достоинств. Например, достаточно подать команду fetch, чтобы увидеть, над какими темами работают остальные. Кроме того, оставив ветвь время и возвратившись к ней позднее, по имени проще припомнить, о чём она была.
И это приятно, потому что, когда на Гитхабе заходим на страницу со списком ветвей, то легко видеть, над какими ветвями недавно поработали каков был объём работы).
Это почти как список будущих фич с грубою оценкою нынешнего состояния их. Если не пользуетесь этой страницею, то знайте — у ней классные возможности: она вам показывает только те ветви, в которых была проделана работа, уникальная по отношению к выбранной вами в настоящий момент ветви, да ещё и сортирует таким способом, чтобы ветви с наиболее недавнею работою были сверху. Если захочется полюбопытствовать, то я могу нажать на кнопку «Compare» и поглядеть на точный объединённый diff и на список коммитов, уникальных для этой ветви.
Сейчас, когда я это пишу, у нас в репозитории 44 ветви с невоссоединённым кодом, но также видно, что из них только в девять или в десять поступал код за последнюю неделю.
Постоянно отправляйте код именованных ветвей на сервер
Другое крупное отличие мы беспрерывно ветвей на сервер. С точки зрения внедрения приходится беспокоиться только о ветви master, так что push никого не озадачит и ничего не поломает: всё, что это просто код, над которым идёт работа.
Этим создаётся страховочная копия на случай утраты ноутбука или выхода жёсткого диска из строя. Этим поддерживается, что ещё важнее, постоянный обмен сведениями между разработчиками. Простой командою можно получить список тех TODO, над которыми все сейчас работают.
Также это позволяет всем видеть (на гитхабовской странице списка ветвей), над чем работают все остальные — можно проанализировать код и решить, не желаешь ли помочь разработчику.
В любое время создавайте запрос на слияние
GitHub снабжён поразительною системою обзора кода, которая называется запросами на слияние; боюсь, недостаточно разработчиков вполне знают о ней. Многие пользуются ею в обыкновенной работе над открытым исходным кодом: форкнул проект, обновил код, отправил запрос на слияние к хозяину проекта. Однако эта система также может употребляться как средство внутрикорпоративной проверки кода, и так её используем мы.
Её мы, собственно, скорее используем как средство просмотра и обсуждения ветвей, чем как запрос на слияние. GitHub поддерживает отсылку запроса на слияние из одной ветви в другую в одном и том же проекте (открытом или приватном), так что в запросе можно сказать «мне нужна подсказка или обзор этого кода», а не только «прошу принять этот код».
На этой иллюстрации вы можете видеть, как Джош просит Брайана взглянуть на код, и тот является с советом по поводу одной из строк кода. Ниже можно видеть, как Джош соглашается с соображениями Брайана и пополняет код, чтобы отреагировать на них.
Можно, наконец, видеть и то, что код находится ещё на стадии испытаний: это ещё не ветвь, подготовленная ко внедрению, мы используем запросы на слияние для рассмотрения кода задолго до того, как захотим действительно слить его и отправить на внедрение.
Если ваша работа над фичею или ветвью застревает и нужна помощь или совет, или если вы — разработчик, а на вашу работу надо бы посмотреть и дизайнеру (или наоборот), или даже если кода у вас мало (или вовсе нет), но есть композиция скриншотов и общих идей, то вы открываете запрос на слияние. Система Гитхаба позволяет добавлять людей к обсуждению так что если обзор или отклик нужен от конкретного человека, то можно в запросе упомянуть его (вы видели выше, как Джош сделал это).
И это круто, потому что в запросах на слияние можно комментировать отдельные строки объединённого диффа, или отдельные коммиты, или весь запрос в целом — и копии реплик сложатся в единое обсуждение. Также можно продолжать пополнение ветви кодом, так что если укажет на ошибку или на позабытую возможность в коде, то можно поместить исправление в ту же ветвь, и GitHub покажет новые коммиты в обсуждении, так что и вот так можно трудиться над ветвью.
Если ветвь существует слишком долго и вы ощущаете, что код в ней рассогласовывается с кодом ветви то можно код влить в вашу ветвь и продолжить работу. В обсуждении запроса на слияние или в списке коммитов без труда видно, когда ветвь последний раз обновляли кодом, взятым
Когда работа над ветвью целиком и полностью окончена и вы ощущаете её готовою ко внедрению, тогда можете переходить к следующему шагу.
Слияние только после обзора запроса
Мы не работаем непосредственно в ветви но и работу из именованной ветви мы не подвергаем слиянию сразу после того, как сочтём её оконченною — сперва мы стараемся получить одобрение от других сотрудников компании. Оно обычно имеет форму или комментария нам надо привести поглядеть на ветвь.
Когда одобрение получено, и ветвь прошла CI, мы можем слить её и на внедрение; в этот момент запрос на слияние будет закрыт автоматически.
Внедрение непосредственно после обзора
Наконец, ваш труд окончен, а плоды его — на ветви master. Это означает, что, даже если прямо сейчас вы не станете внедрять их, то они всё равно станут основою для ветвей других сотрудников, и что следующее внедрение (которое, скорее всего, случится через несколько часов) запустит новинку в дело. И так как бывает очень неприятно обнаружить, что запустил ваш код и пострадал от этого (если код поломал), то людям свойственно самим заботливо проверять стабильность итогов совершённого ими слияния, самостоятельно внедрять результаты.
Наш campfire-бот, по имени hubot, может внедрять код по указанию от любого из сотрудников. Достаточно подать в чате команду hubot deploy github to production, и код поступит на продакшен, где начнётся перезапуск (с нулевым даунтаймом) всех необходимых процессов. Можете сами судить о том, как часто это случается на Гитхабе:
Как видите, шесть разных человек (среди которых один саппорт и один дизайнер) внедряли код более двух дюжин раз за сутки.
Всё вышеописанное я совершал для ветвей с одним коммитом, содержащим однострочное изменение. Процесс прост, бесхитростен, масштабируем и силён. То же самое можно делать и с ветвью фичи, содержащей полсотни коммитов, потребовавших двухнедельной работы, и с одним коммитом, изготовленным минут за десять. Процесс настолько прост и настолько не тяготит, что его необходимость не раздражает даже в однокоммитном случае, так что люди редко пропускают или обходят отдельные шаги его — разве что речь идёт об изменении настолько малом и незначительном, что это никакого значения не имеет.
Наш рабочий процесс обладает и силою, и невероятною простотою. Думаю, многие согласятся, что GitHub — очень стабильная платформа, что на её проблемы мы реагируем быстро (если они вообще возникают), что новые фичи внедряются в быстром темпе. Там нет таких компромиссов в отношении качества или стабильности, которые могли бы увеличить скорость и простоту рабочего процесса или уменьшить число его шагов.
Заключение
Git сам по себе довольно сложен для понимания. Если его ещё и употреблять в рабочем процессе более сложном, чем это необходимо, то дело кончится ежедневным чрезмерным усилием рассудка. Я всегда буду отстаивать употребление простейшей из возможных систем, пригодных для работы вашей группы, и до тех пор, пока система эта не перестанет работать; только тогда добавляйте сложность, когда никак не удаётся избежать этого.
Для тех рабочих групп, которым необходимо подготавливать официальные выпуски кода через продолжительные интервалы (от нескольких недель до нескольких месяцев между выпусками), и создавать хотфиксы, и ветви поддержки прежних версий, и совершать другие дела, необходимость которых вызывается такими нечастыми выпусками кода, имеет смысл и я весьма рекомендовал бы его употребление.
Для групп, труд которых строится вокруг доставки кода, которые ежедневно обновляют продакшен, беспрерывно тестируют и внедряют фичи, я рекомендовал бы более простой рабочий процесс — такой,
