Флоу что это в разработке
Пожалуйста, перестаньте рекомендовать 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 лет). В этом случае рекомендую обратиться к оригинальной статье.
В заключение хочу напомнить вам, что панацеи не существует. Учитывайте свои условия, контекст и думайте своей головой!
Полное руководство по User Flow: как сделать, примеры и советы
Расскажу о ценности User Flow, а также покажу, как создать User Flow по шагам. Чек-лист с примерами и рекомендациями в конце статьи.
Продуктовый дизайнер (UX/UI), веб-дизайнер и бренд-дизайнер. Опыт проектов в международных компаниях Omega-R (агентство), iSpring Solutions (продуктовая) и со стартапами по всему миру. Преподаватель курсов «UI-дизайн и анимация интерфейсов» и «Веб-дизайн» в Институте программных систем и godesign.school.
Июн 11 · 8 мин читать
User flow — это наглядное представление последовательности действий, которые выполняет пользователь для достижения значимой для себя цели на сайте или в приложении. Может охватывать как какую-то отдельную функцию, так и весь продукт. Рассказываем на примерах, как построить карту и с помощью каких инструментов это удобнее сделать. 👩💻👇
Фактически концепцию потока в UX-дизайне впервые предложил психолог Михай Чиксентмихайи. Поток (англ. flow) — это психическое состояние, в котором человек полностью включён в то, чем он занимается, что характеризуется деятельным сосредоточением, полным вовлечением в процесс деятельности. Поэтому при проектировании User Flow мы будем опираться на эти фундаментальные концепции психологии восприятия.
Руководство призвано помочь вам сориентироваться в любом User Flow, независимо от формата, контекста и целей.
Содержание:
Что такое User Flow и для чего он нужен?
User Flows (в переводе — диаграмма пользовательского пути), также известны как User flow, UX flow, user flow charts, interaction flows, activity flows, user interface flows, navigation flows, user flow diagrams, task flow diagrams или блок-схемы. Представляют собой диаграммы, отображающие полный путь, по которому движется пользователь при использовании продукта. User flow описывает продвижение пользователя по продукту, отображает каждый шаг, который делает пользователь — от точки входа (начало) до финального взаимодействия (значимая цель достигнута, ценность получена).
Шаблон User Flow (UX Flow) крупным планом.
Говоря простыми словами, User Flow — это маршрут путешествия пользователя через экраны приложения к важной цели. А каждое приложение — это целая карта таких маршрутов (User Flow Map).
Использовать User Flow в команде следует по следующим причинам:
User Flow — это наглядный инструмент для донесения идей в четком, запоминающемся виде. А еще User Flow помогает создать единое видение по сценарию работы в определенной жизненной ситуации.
Инструкция по разработке User Flow
В самом простом варианте построение диаграммы пользовательского пути происходит следующим образом:
Что важно учесть при построении User Flow: 8 советов для дизайнеров
User Flow может выглядеть совершенно по-разному, но вне зависимости от этого, каждая диаграмма пользовательского пути должна иметь 8 следующих ключевых элементов:
1. Название с полезным действием
Дайте вашему User Flow содержательное имя, с сутью в корне. Например, вы можете назвать так «Вызов такси к дому до офиса» или «Заказ пиццы и других ништяков на компанию из 7 человек ко дню рождения друга».
2. Все движутся только в одном направлении
При таком подходе у вас будет ясный маршрут из (A) → (B). Стремитесь к балансу функциональности и лаконичности. Избегайте превращения простой прямой в запутанный клубок разнонаправленных сценариев.
3. Одна цель на Flow
Чтобы понять эту концепцию, то просто представьте, что вас просят обновить фото вашего профиля во время публикации сообщения!
Пользователь ныряет в продукт, чтобы достичь одной конкретной цели. Поэтому постарайтесь организовать его работу таким образом, чтобы пользователь двигался этап за этапом, шаг за шагом к этой цели. Помогайте пользователям достичь цель и не отвлекайте их на пути к цели.
4. Добавьте легенду
Каждому в команде схема станет понятнее, если вы сделаете классическую легенду по краю карты, как в играх. Так каждый сможет разобраться что здесь к чему. Например, укажите в легенде, что кружки — это точки входа, прямоугольники — экраны, ромбы — развилки принятия решений и т. д. Вы также можете обратиться к легенде BPMN-нотации, чтобы как с UI-китом уже опираться на некий стандарт компонентов и иконок известных многим специалистам.
5. Определитесь с точкой входа
У каждой диаграммы должна быть ясная точка входа. Тогда каждый в команде сможет однозначно читать диаграмму путешествия из (A) → (B) и вовлекаться в развитие продукта.
6. Ясные подписи
Обозначьте ключевые действия, добавьте подписи с предназначениями экранов.
7. Цвета со смыслом
User Flow обычно выполняют в функциональном минималистичном монохроме. Такой подход помогает сосредоточиться на функции и цели и концентрирует внимание только на важных вещах.
8. Проверьте достижение цели
Всегда проверяйте, что ваши User Flow действительно помогают достигать значимых для пользователей целей. Минимизируйте неопределенность и, если требуется, проведите дополнительные исследования.
Что еще нужно знать: связь User flow Map и User Story Mapping
Если вы применяете User Flow, то вы следуете международному подходу к разработке интерфейсов. Такой подход называют User Centered Design и Goal Oriented Design.
User Centered Design — клиент нанимает продукт, чтобы тот помог сделать значимую для клиента работу.
Goal Oriented Design — пользователь понимает, как достичь цели, открыв приложение.
Продакт-менеджеры тоже живут в той же парадигме — они наращивают ситуации, в которых приложение дает больше пользы, чем конкуренты. Один из инструментов управления продуктов у продакт-менеджера — это User Story Mapping
User Story Mapping
User Story Mapping — инструмент управления продуктом, полезен продакт-менеджеру — это вся карта задач, которые можно попросить сделать продукт. Представляют в виде двумерной сетки. Рекомендую на эту тему статью User Story Mapping – инструкция по применению →
User flow Map
User flow Map — инструмент дизайнера — развернутое представление User Story Mapping в формате диаграммы потоков. Два инструмента логично дополняют друг друга.
Если приложение как ваш цифровой помощник, которому можно поручить дело, то User Story Mapping — это книга дел, которые ему можно поручить, а User flow Map — это карта всех инструкций, как он будет действовать по шагам.
Итак, мы разработки параметры сборки одного User Flow, а сейчас разберем подход к подаче всей карты маршрутов вашего приложения.
Для сборки User Flow Map мы берем весь комплект User Flow и скрепляем их навигацией.
Пример User Flow мобильного приложения
В примере интересный вариант оформления User flow на примере приложения Toronto Zoo.
Пример User Flow для веб-сайта и веб-приложения
Пример от digital-агенства Focus Lab. Ребята проанализировали выполненные проекты и создали библиотеку для проектирования User Flow (User Flow Kit). В основе алфавита проектирования у ребят прослеживаются черты BPMN-нотации.
Вывод и рекомендация
User Flow помогают сосредоточиться на человекоцентричном дизайне и добиться максимально комфортного и эффективного маршрута до цели. А еще они добавляют согласованности в работе команды и экономят время и деньги.
User Flow также направляют принятие решений в дизайне и подсвечивают недочеты еще до того, как начнется фаза детальной работы над компонентами и визуальной проработкой. И самое главное — они побуждают искать самый простой способ достижения цели пользователем и вовлекают в поиски алтернатив. Попробуйте их в вашим следующем проекте.
Напомню, что прокачать навыки в создании User Flow вы можете на платформе Breezzly. На Breezzly вы тренируетесь в контексте сайтов, мобильных и веб-приложений и даже на примере приложений для смарт-часов.
Как тестировать user flow: четыре метода и лайфхак для бесплатного UI тестирования
Работа над User flow, пользовательским сценарием — важный этап создания интерфейса. User flow принимает различные формы в зависимости от этапа развития продукта. Расскажу, как тестировать сценарии в разных ситуациях и как это можно делать бесплатно. Пригодится людям, задействованным в создании интерфейсов: UI дизайнерам, менеджерам продуктов, UX исследователям.
User Flow — пользовательский сценарий иллюстрирует порядок действий, который пользователь выполняет для решения задачи. Сценарий — это скелет интерфейса, состоит из шагов — отдельных экранов. Удобный для пользователя интерфейс начинается именно с проработки user flow, структуры.
В оригинале пользовательский сценарий представляет собой блок-схему с логическими связями и пересечениями. Но тестировать сценарий в таком виде затруднительно и бессмысленно.
Интерфейс — это подход к решению задачи. Для проверки логики смотрим, насколько интерфейс выполняет свою функцию.
Для теста User Flow достаточно последовательных экранов или даже нарисованных от руки черновиков. Большинство дизайнеров, продактов и исследователей имеют дело уже с работающим цифровым продуктом, поэтому начнем именно с этой ситуации.
Тестировании User Flow продукта — это гигиеническая норма. Для оценки общего уровня удобства важны количественные метрики. Подход к сбору данных зависит от исследовательской культуры и возможностей.
Для проверки сценариев достаточно провести онлайн опрос. Даем респондентам ссылку на продукт и задание. По итогу прохождения задаем вопросы из стандартной анкеты по оценке юзабилити (SUS). Полезно наравне с собственным продуктом тестировать прямых и косвенных конкурентов. В разнице оценок и содержится наиболее полезная информация.
Пример: летом 2019 года провели сравнительное исследование трех онлайн супермаркетов. За несколько часов получили общие метрики по удобству интерфейса, а из открытых ответов почерпнули информацию о разрывах в пользовательском сценарии.
Fastuna Task Flow Click (UX Benchmark) Ссылка на отчет
Я не смогла добавить все товары в корзину. При добавлении только 1 товара мне сразу предлагают оформить доставку, а я хотела добавить другие товары.
Опрос дает количественные оценки и прямую речь. Фиксируем показатели, которые отклоняются от нормы или результатов конкурентов. Изучаем упомянутые в открытых ответах проблемы. Полученных данных бывает достаточно для принятия бизнес решения. Если вопросы остались, то обращаемся к более глубоким методам исследований.
Предположим ситуацию: продукт функционирует без багов, но люди не доходят до выполнения целевого действия. Точного понимания причин нет. Поиск проблемы — это качественная, а не количественная задача, предполагает погружение в опыт отдельных людей. Здесь подходят два метода: модерируемые и немодерируемые юзабилити тесты. Первый метод быстр, доступен почти всем. Модерируемый тест способен дать более глубокие данные, но требует времени и специальных навыков.
Немодерируемые тестирования занимают от одного до нескольких дней. Люди под запись экрана делают попытку выполнения задания, а потом дают обратную связь. Изучаем видеозаписи и пониманием, в чем заключена проблема: в логике user flow, в функциональных элементах или в оформлении интерфейса.
В статье “Смотрим видео и страдаем. Как я анализировал записи UX-исследования” рассказываю о том, как выглядит анализ немодерируемого юзабилити теста и с какими неожиданными трудностями сталкиваются люди при использовании привычных элементов.
Применимо, когда есть потребность в большей детализации и погружении. Респондент получает задание, а интервьюер очно или онлайн наблюдает за человеком в режиме реального времени, задает уточняющие вопросы. Личные интервью с людьми — более трудоемкий и времязатратный метод, требует особых компетенций, но при правильном проведении дает ценную информацию. Модерируемые юзабилити интервью рекомендуем по возможности проводить с привлечением штатных сотрудников, погруженных в продукт.
При тестировании User Flow путем модерируемых и немодерируемых юзабилити тестирований важно помнить, что эти методы относятся к качественной методологии, служат для формулировки предположений, а не для проверки гипотез. На нескольких интервью вы найдете проблему, но не ее распространенность.
Предположим, мы нашли проблему в пользовательском сценарии и работаем над улучшением User Flow. Новый пользовательский сценарий обретает плоть. Сначала в виде последовательных макетов. Мы не палим ресурсы разработки впустую, поэтому удостоверяемся, что новый вариант работает, люди понимают, куда нажимать на каждом шаге для выполнения задания, дойдут до конца маршрута.
Для количественной проверки гипотез, при оценке сценария на интуитивность подходит тест первого клика
Как это работает: даем 100-400 людям задание и последовательно показываем экраны интерфейса. На каждом экране человек делает только один клик, который приблизит к выполнению задания. По итогу получаем тепловую карту кликов на каждом шаге. Видим, на каком этапе пользовательского сценария возникает больше всего затруднений.
Пример: я тестировал пользовательский сценарий по поиску дверной ручки на сайте строительного гипермаркета. На втором шаге сценария, при попадании в каталог 71% ищут дверные ручки в разделе двери и окна. И лишь 6% в скобяных изделиях, где они и находятся. Вывод: интерфейс не решает задачу для сценария по поиску этого товара.
Если задача — общая оценка то из исследований наиболее релевантен опрос с применением классической шкалы SUS или ее разновидностей.
Если на этапе готового продукта ищем проблему в User Flow, то в зависимости от требуемой детализации и ресурсов используем немодерируемое или модерируемое юзабилити тестирование.
На этапе разработки, когда user flow представлен в виде последовательных экранов рекомендую тест первого клика — он покажет, на каком шаге люди теряются, поможет при размещении кнопок.
Обещанный лайфхак: перечисленные решения доступны бесплатно. Fastuna специализируется на готовых решениях на базе онлайн панели. Но при использовании собственной базы все решения можно использовать бесплатно. Каждой компании доступно 500 интервью в месяц. Да, это касается даже немодерируемых юзабилити тестирований с записью экрана.
GitLab Flow
Это перевод достаточно важной статьи про GitLab Flow, альтернативе Git flow и GitHub flow. Статья была написана в 2014, так что скриншоты успели устареть. Тем не менее сама статья более чем актуальна:
Ветвление и слияние веток в git устроено гораздо проще, чем в более ранних системах контроля версий, таких как SVN. Поэтому есть много способов организации командной работы над кодом, и большинство из них достаточно хороши. По крайней мере, они дают много преимуществ по сравнению с тем, что было до git. Но сам по себе git — не серебряная пуля, и во многих командах организация рабочего процесса с git имеет ряд проблем:
Мы хотим представить вам GitLab flow — чётко определённый набор практик, решающий эти проблемы. Он объединяет в одну систему:
Эта статья описывает все аспекты GitLab flow, включая работу с ветками, интеграцию с задачами, непрерывную интеграцию и развёртывание. Её цель — помочь новым командам перейти на git и сразу внедрить простые, прозрачные и эффективные правила работы с ним.
В большинстве систем контроля версий, чтобы поделиться кодом с коллегами, нужно сделать одно действие — коммит в репозиторий. В git то же самое происходит в три этапа:
Освоение этих действий — первый шаг в изучении git. Следом идет работа с ветками.
Если не устанавливать никаких правил работы с ветками, в репозитории начинает расти энтропия:
Для решения этих проблем обычно внедряется некая стандартная модель работы, например git flow или GitHub flow. Мы считаем, что у всех этих моделей есть потенциал для улучшения, поэтому мы разработали GitLab flow.
Git flow и его ограничения
Во-вторых, лишняя сложность появляется из-за веток релизов и хотфиксов. Большинство команд, особенно небольших, может легко обойтись без них. Сегодня большинство организаций придерживается практики непрерывной доставки (continuous delivery), которая предполагает, что код из основной ветки можно развёртывать на продакшен (production, то, что предоставляется пользователям).
GitHub flow – более простой вариант
Мерж всех изменений в master и частое развёртывание позволяют не писать код «в стол», а сразу выпускать изменения. Это соответствует идеям бережливого (lean) производства и непрерывной доставки. Но множество вопросов остаются без ответа: когда именно нужно развёртывать и в каких окружениях, как выпускать релизы, как связать всё это с трекером задач. GitLab flow отвечает на все эти вопросы.
GitLab flow: ветка production
GitLab flow: ветки для нескольких сред
GitLab flow: релизные ветки
GitLab flow: мерж/пулл-реквесты
Мерж-реквест или пулл-реквест создаётся в системе управления git-репозиториями. Это запрос на мерж одной ветки в другую, подобно задаче, назначаемый на какого-либо исполнителя. GitHub и Bitbucket используют термин «пулл-реквевст», потому что первое необходимое действие — сделать пулл предлагаемой ветки. GitLab и Gitorious используют термин «мерж-реквест», потому что заключительное действие — собственно, мерж ветки. Далее в этой статье мы будем называть это мерж-реквестом.
Когда фича готова, и ветку можно мержить, назначьте реквест на того, кто хорошо знает код проекта (и у кого есть права на мерж в master ). Этот человек несёт ответственность за окончательное ревью и принимает решение: замержить результат или закрыть реквест без мержа.
В GitLab есть стандартная практика — «защищать» долгоживущие ветки (такие как master или production ). Защита ветки не позволяет участникам с уровнем доступа «Developer» пушить в неё любые изменения.
Поэтому для мержа в защищённую ветку нужно открывать мерж-реквест, назначаемый на участника с более высоким уровнем доступа.
GitLab flow: интеграция с задачами (issues)
GitLab flow позволяет вам явным образом связывать код и задачи из трекера.
Любые значимые изменения в коде должны сопровождаться задачей, в которой сформулированы требования и смысл изменений. Это помогает оставаться в рамках задачи, а также даёт команде представление о том, чем вы заняты. В GitLab каждое изменение кодовой базы начинается c оформления задачи в трекере. Если предполагаемые изменения хоть сколько-нибудь серьёзны (например, требуют более часа работы), то работу нужно начинать с оформления задачи. Многие команды уже следуют этому правилу, потому что всегда оценивают время выполнения задачи, прежде чем взять её в спринт.
Заголовки задач желательно формулировать так, чтобы они описывали желаемое состояние системы.
Хороший пример: «Как администратор, я хочу иметь возможность удалить пользователя без ошибок».
Плохой пример: «Админ не может удалять пользователей».
Feature-ветка обычно больше не нужна после мержа, поэтому интерфейс реквеста позволяет удалить её. Предположим, что ветка была замержена, после чего вы обнаружили какие-то недоработки и переоткрыли задачу. Если старая ветка удалена, можно создать новую ветку с тем же именем и продолжить разработку в ней. Как правило, одной задаче соответствует не более одной ветки, но в одной ветке может решаться несколько задач.
Связывание задач и мерж-реквестов
Если вы хотите создать ссылку на задачу, но не закрывать её, напишите просто её номер: «Duck typing is preferred. #12».
Если некоторая задача охватывает несколько репозиториев, лучше всего создать основную задачу в одном репозитории и привязать к ней отдельные задачи в других репозиториях.
Rebase и объединение коммитов
Помните, что коммиты, которые уже попали в удалённый репозиторий и, тем более, в стабильную ветку, ребейзить нельзя. Причина этого в том, что-нибудь мог оставить ссылку на них или вытащить (cherry-pick) в свою ветку. Ребейз меняет идентификаторы (SHA-1) коммитов, потому что фактически создаёт из них новые коммиты. В результате ваши изменения появляются в истории git с несколькими разными идентификаторами, что приводит к путанице и ошибкам. Ребейз также затрудняет ревью кода, так как теряется информация о том, какие изменения были внесены после ревью. Если объединяются коммиты разных авторов, то информация об авторстве тоже будет потеряна. Это лишает авторов указания на их авторство, а ещё мешает работе git blame (показывает, в каком коммите и кем изменялась каждая строка).
Регулярно делать коммиты и пушить их в удалённый репозиторий — хорошая практика, позволяющая коллегам видеть, над чем вы работаете. Но при таком подходе одна задача размазывается на много коммитов, так что историю разработки становится довольно сложно просматривать. Эти небольшие коммиты можно было бы объединить в один, но это приведёт к потере идентификаторов. Вместо этого можно просматривать историю по мерж-коммитам: они всегда объясняют суть изменения и обозначают момент мержа целой ветки.
Не меняйте порядок коммитов с помощью rebase
Использование rebase вынуждает вас многократно разрешать одни и те же конфликты. В некоторых случах это можно сделать командой git rerere (reuse recorded resolutions). Но ещё проще — вовсе не ребейзить и разрешать конфликты всего один раз, при мерже. Чем с меньшим количеством мерж-конфликтов вы сталкиваетесь — тем лучше.
Чтобы избежать лишних конфликтов, нужно не слишком часто мержить master в feature-ветки. Давайте разберём три возможных причины мержа master куда-либо ещё: «подтягивание кода» (leveraging code), мерж-конфликты и долгоживущие ветки.
Если вам нужно «подтянуть» изменения из master в feature-ветку — обычно можно обойтись вытаскиванием (cherry-pick) одного нужного коммита.
Последняя ситуация, когда необходимо мержить master куда-то ещё — это использование долгоживущих веток, которые периодически нужно обновлять до актуального состояния. Мартин Фаулер в своей статье о feature-ветках рассуждает о практике непрерывной интеграции (continuous integration, CI). Мы в GitLab немного путаем CI с тестированием веток.
Цитируя Фаулера: «Я знаю людей, которые утверждают, что практикуют CI, потому что выполняют сборку каждой ветки и каждого коммита, и даже могут при этом использовать CI-сервер. То, что они делают, называется непрерывной сборкой (continuous building). Это тоже благородное дело, но интеграции-то нет, а значит, нет и «непрерывной интеграции».»
Решение заключается в том, что feature-ветки должны существовать недолго и быстро мержиться. Можно ориентироваться на срок в один рабочий день. Если разработчик держит ветку для реализации задачи более одного дня, подумайте о том, чтобы раздробить задачу на более мелкие части. В качестве альтернативы можно использовать «переключатели фич» (feature toggles).
Для работы с долгоживущими ветками есть две стратегии:
GitLab попытается сделать rebase перед мержем. Если rebase без конфликтов невозможен, будет выполнен обычный мерж.
В заключение хотелось бы сказать следующее: старайтесь делать меньше мерж-коммитов, но не исключайте их вовсе. Ваш код должен быть чистым, но его история должна быть достоверной. Разработка ПО происходит небольшими и не всегда красивыми шагами. То, что они сохранятся в истории кода — нормально. А ребейз делает историю недостоверной, после чего никакие инструменты не покажут вам действительную историю, потому что они не могут узнать идентификаторы коммитов, которые были до ребейза.
Используйте эмодзи в задачах и мерж-реквестах
Пуш и удаление веток
Мы рекомендуем регулярно пушить локальные ветки в удалённый репозиторий, даже если код ещё не готов к ревью. Таким образом вы страхуетесь от ситуации, в которой кто-то другой начал работу над той же задачей. Разумеется, более правильный способ — назначить этой задаче исполнителя с помощью трекера задач. Но иногда этот способ даёт сбой, просто потому что никто об этом не вспомнил.
Делайте коммиты часто и пишите к ним корректные сообщения
Мы рекомендуем начать коммитить код как можно раньше и делать это регулярно. Каждый раз, когда у вас есть работающий набор из кода и тестов к нему, можно сделать коммит. Преимущество этого способа в том, что если следующий этап работы зайдёт в тупик, вы всегда сможете вернуться к рабочей версии кода. Это кардинально отличается от работы с SVN, где код можно коммитить только тогда, когда он полностью готов. Когда ваша работа завершена, используйте мерж/пулл-реквест, чтобы поделиться ей.
Сообщение коммита должно описывать ваши намерения, а не пересказывать содержимое кода — его и так несложно посмотреть. Важно то, зачем вы сделали этот коммит.
Пример хорошего сообщения: «Скобминировать шаблоны, чтобы разгрузить интерфейс пользователя».
Некоторые слова портят сообщение, потому что ничего конкретного не значат: «поменять», «улучшить», «отрефакторить» и т.п. Слова «чинит», «исправляет» тоже лучше не использовать, только если вы не пишете «fix» (только на английском) в конце сообщения и вместе с номером задачи. Если вы хотите больше подробностей, рекомендуем прочитать отличную статью из блога Tim Pope.
Тестирование перед мержем
Если ветки мержатся быстро и конфликтов при мерже нет, то обычно можно рискнуть и замержить, не тестируя результат. Если конфликты всё-таки есть, то можно замержить master в feature-ветку (т.е. наоборот), после чего ваш сервер CI запустит тесты на полученном коммите. Если feature-ветки живут дольше, чем несколько дней, стоит подумать об уменьшении масштаба ваших фич.
Мерж чужого кода в ваш код