git flow что такое
Шпаргалка по 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
Команды
Последние замечания
Рабочий процесс 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 — наиболее популярная методология разработки проектов с использованием git.
Зачем нам вообще нужны какие-то методологии для работы с git?
Дело в том, что сам git не привязывает нас к какому-либо определённому способу разработки, и каждый разработчик, в теории, может работать с контролем версий так, как он хочет. Чтобы в таких условиях не погрузить наш репозиторий в хаос, нам нужно придумать и донести до всех разработчиков некий единый стандарт для работы с контролем версий в проекте.
Git-flow даёт нам готовый стандарт проверенный временем и уже известный многим разработчикам.
В то же время, нужно понимать, что методология git-flow не является единственно верной и на 100% универсальной. В Вашем проекте может существовать собственный подход к работе с git. Однако, если вы работаете или собираетесь работать с git в команде, то стоит знать о том, что такое git-flow и в чём его особенности.
И так, что же нам стоит знать о git-flow?
Суть ветвления в git-flow
Всего в git-flow существует 5 типов веток, каждый из которых несёт определённую функциональную нагрузку.
Ветка develop
Ветка существует на протяжении всего процесса разработки. В данную ветку попадает стабильный код новых фич и багфиксов.
Тривиальные фичи, разработка которых умещается в один полноценный коммит, обычно идут прямо в эту ветку. Но те фичи, для реализации которых нужно уже несколько коммитов, выделяются в отдельные ветки feature-*.
Ветки feature-*
Временные ветки, которые создаются для каждой нетривиальной фичи.
Каждая ветка feature отделяется от develop и мержится обратно в него. После завершения работы над фичей и финального мержа в develop, ветка удаляется. При мерже ветки в develop не должен использоваться fast-forward (флаг –no-ff).
Имя ветки должно соответствовать имени разрабатываемой фичи, например “feature-gamecenter-integration”. В некоторых проектах префикс “feature-” опускается (тогда любая ветка без префикса — это ветка feature).
Ветка master
Ветка, куда поступают самые стабильные изменения, которые идут в релиз. Существует на протяжении всего процесса разработки.
В ветку master мержатся только изменения из веток release и hotfix. На каждый такой мерж создаётся тег с именем версии. Полный запрет использования fast-forward при мерже в ветку (флаг –no-ff).
По сути, в самой ветке не должно быть никаких коммитов, кроме коммитов мержей, каждый из которых должен быть отмечен тегом версии.
Ветки release-*
Временные ветки, создаваемые для подготовки новой версии к релизу. В эти ветки попадают правки багов и настройки перед релизом.
Ветка выходит из develop и может мержится в develop по ходу подготовки версии. Как только работа над версией заканчивается, происходит финальный мерж ветки в master и develop, после чего ветка удаляется, а коммиту мержа в master присваивается тег новой версии.
Имя ветки должно соответствовать выпускаемой версии, например “release-1.4”.
Ветки hotfix-*
Временные ветки hotfix-* создаются для правки критических проблем в релизной версии.
Ветка отходит от master и по завершению правок багов мержится обратно. Сама ветка после этого удаляется, а коммиту мержа в master присваивается тег новой версии.
Именем ветки обычно является новая версия с учётом версии фикса, например “hotfix-1.4.1” (первый хотфикс версии 1.4).
Подробнее про ветвление в git-flow можно узнать из оригинальной статьи автора методологии или из её перевода на русский язык.
Инстументы с поддержкой git-flow
По сути нам нет необходимости в каких-то особенных инструментах для поддержания процессов разработки, все действия могут быть выполнены из практически любой графической оболочки над git, либо из командной строки.
Однако, есть удобное расширение для git, которое позволяет немного ускорить ежедневную работу по данной методологиии за счёт уменьшения количества вводимых команд в консоли и работы непосредственно на уровне абстракций git-flow.
Так же, git-flow поддерживается из коробки некоторыми популярными графическими оболочками такими как SourceTree и SmartGit.
Как в случае консольного расширения, так и в случае графических клиентов, мы работаем с более понятными командами вроде “Start Feature” и “Finish Feature”, что позволяет проще смотреть на процесс разработки.
Git-flow и непрерывная интеграция
При разработке с использованием git-flow, одновременно существует две стабильные ветки, которые можно использовать для сборки билдов или выкладки кода на сервер: это ветки master и develop.
Сборки из ветки master можно собирать сразу по поступлении новых изменений. Любые новые правки в этой ветке — это стабильный production-код, который можно выкладывать на сервер (в случае разработки веб-ресурса) либо собирать в релизный бинарник.
Версии собранные из ветки master должны в обязательном порядке подвергаться всем существующим в проекте автоматизированным тестам.
Из ветки develop можно собирать ночные сборки (для тестирования) либо, по мере разработки, можно выкладывать код из этой ветки на тестовый сервер (в случае разработки веб-ресурса).
На версиях собранных из ветки develop следует прогонять unit-тесты.
Когда не стоит применять git-flow
Во первых, git-flow достаточно сложная методология, расчитанная на большие проекты. Если проект относительно небольшой и над ним работает команда всего из 3-4 человек, то применение git-flow может только усложнить процесс разработки.
Во вторых, git-flow в чистом виде применим только в тех случаях, когда в процессе разработки присутствует такое понятие как “релиз”. Если изменения публикуются в продакшн по мере разработки, то смысла применять git-flow тоже нет.
В обоих случаях, можно либо взять git-flow, отказавшись от некоторых типов веток (master, release, hotfix), либо выбрать другую методологию.
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-ветки живут дольше, чем несколько дней, стоит подумать об уменьшении масштаба ваших фич.
Мерж чужого кода в ваш код