для чего нужен git flow
Всем привет. В этом уроке мы рассмотрим как автоматизировать workflow, который мы с вами разобрали в прошлом уроке. Руками создавать фичи, хотфиксы и релизы каждый день достаточно долго, а действия всегда одни и те же. Поэтому существует много всяких возможностей сделать это более удобным.
Так как он у меня уже установлен, то я его устанавливать не буду. Про установку на других операционках можно почитать в оффициальной репе. В разделе Installation instruction написано как устанавливать его на все операционки.
Теперь нам нужно инициализировать gitflow в нашем репозитории.
И нам задают тут вопросы как мы хотим назвать мастер, девелоп, хотфикс и релиз ветки. Можно смело нажимать enter в ответ на все вопросы. Вопросы закончились и теперь у нас инициализирован gitflow.
Теперь давайте создадим новую фичу, как мы делали в прошлом уроке.
Как мы видим сразу произошло очень много. У нас создалась новая ветка feature/implement-registration. Нам не нужно указывать приставку feature, так как она добавляется автоматически. И оно нам перекинуло на созданую ветку. И когда мы закончим работать с этой веткой нам нужно написать git flow feature finish.
Теперь cделаем какие-то изменения. Создадим файл register.js и добавим туда какую-нибудь функцию.
Теперь закоммитим наши изменения.
И пишем, что хотим закончить фичу
Эта команда автоматически мерджит фичу в develop, удаляет старую ветку и переключается на develop. И все это в одну команду.
Если мы посмотрим git log, то мы увидим, что наш коммит добавился.
Теперь давайте создадим релиз, как мы делали в прошлом уроке.
Оно нам говорит, что у нас есть ветка релиза 1.0, которая не была нормально завершена. Это потому, что мы ее никак не закрыли и не удалили и она у нас висит с прошлого урока.
Если мы напишем git branch, то увидим, что у нас висит ветка release/1.0. Давайте ее просто удалим
Теперь если мы попробуем стартануть релиз, должно быть все нормально. Как мы видим, нас перебросило на ветку release/1.1. И оно нам говорит, сделайте необходимые изменения к релизу и когда закончите нажмите finish.
И так как нам не нужно делать никаких изменений пишем
Здесь у нас открывается редактор, который говорит «введите сообщение что вы здесь сделали». Потому что это мердж в мастер и девелоп одновременно. Я просто закрываю файл так как месседж уже написан. И вот у нас открылся еще раз редактор. И оно говорит: «Напишите пожалуйста месседж для тега». Давайте напишем просто 1.1. А я расскажу, что такое теги чуть позже.
Что сделала команда finish в этот раз? Она смерджила релиз в мастер и develop, поставил тег 1.1 и удалила ветку. То есть все, что мы делали в несколько команд в прошлом уроке она сделала в одну.
Если мы хотим сделать хотфикс для продакшена то мы пишем
Делаем наш хотфикс. Например удаляем пробелы в файле register.js. Делаем коммит и пишем finish
Это мерджит ветку одновременно в мастер и девелоп и удаляет ветку.
И теперь немного о том, что такое теги. Если мы напишем команду
Если мы сейчас напишем git tag, то увидим, что у нас добавился тег 1.2.
Это создало нам метку точно на тот коммит, который был на ветке в тот момент, когда мы написали команду. Теперь если мы напишем
Это создаст нам новую ветку с тега. И возьмет последним коммитом, тот, который был последним, когда мы написали эту команду. Теперь абсолютно всегда этот тег 1.2 будет существовать и мы всегда можем создать новую ветку с этого тега.
И последняя команда, которая может быть полезна. По умолчанию, если вы напишете git push, оно пушит только ветки и не пушит теги. Чтобы запушить теги напишем
Теперь мы запушили наши теги и видим сообщение, что у нас создалось 3 новых тега, нам они доступны на гитхабе, их можно клонить вместе с репозиторием и их могут использовать другие люди.
Про Git, Github и Gitflow простыми словами
Не самое исчерпывающее, но точно вполне доходчивое руководство по Git, Github и Gitflow – для тех, кого эти слова смущают, хотя не должны.
Если вы не поняли Боромира, значит, зашли по адресу. С системами контроля версий должен уметь работать любой программист, даже елси вы только учитесь.
Контроль версий помогает не только избежать досадных косяков при внесении изменений, но и необходим для командной работы над проектом. В этом материале мы рассмотрим основные команды для консоли и разберем самую популярную модель управления ветками проекта. И про ветки тоже поговорим.
Git – это распределенная система контроля версий (version control system – VCS).
Контроль версий означает что вы храните все версии редактируемых документов и можете вернуться к любой сохраненной версии в любой момент времени. Кажется, будто такой подход популярен только среди программистов, но на деле им пользуются, например, дизайнеры и другие люди, несколько более подкованные технически, чтобы контролировать изменения в работе.
Распределенность git’а отличает его от прочих vcs. Под распределенностью следует понимать, буквально, возможность использования одной системы контроля на проекте множеством разработчиков.
К слову, Git создал вот этот обходительный джентельмен:
Линус Торвальдс, создатель Git и Linux, передает привет Nvidia
С чего начнем?
Для начала, убедитесь, что у вас установлен Git.
Теперь, все что нам понадобится, чтобы создать репозиторий, это команда git init в нужном каталоге.
Откройте командную строку, и перейдите в Desctop (да, будем оригинальны), а там создайте каталог (например, proglib).
Теперь, проходим в новый каталог и выполняем git init.
Все, у нас есть пустой репозиторий.
Добавление файлов
Давайте создадим простой README.md файл, что-то вроде:
git status – простая команда, которая будет регулярно использоваться. Она показывает информацию о статусе проекта в git. Если вы выполните ее в каталоге proglib, будет видно, что файл README.md не отслеживается git’ом.
Если выпонить git status еще раз, мы увидим, что теперь в системе появился новый файл, который мы добавили.
Коммитим изменения
Чтобы закомминтить изменения в локальный репозиторий, просто напишите в командной строке:
Разумеется, в сообщении можно указать что угодно. Но пожалуйста, сделайте себе одолжение, и пишите вразумительные и ясные комментарии.
Пушим в удаленный репозиторий
Мы будем пушить изменения на Github, так что если у вас вдруг не аккаунта, создайте его.
Нажмите кнопку Start a project и задайте проекту имя, остальные настройки можно оставить по умолчанию.
Так как мы только что создали репозиторий, будем использовать вариант …or push an existing.
Ветки
Git делает ветвление очень простым. Допустим, мы находимся в мастер-ветке и хотим дописать функционал, основываясь на коде из этой ветки. Для этого нужно всего лишь написать команду для создания дополнительной ветки и провести всю работу там. А как закончите, замерджить (то есть, слить ветки) все обратно в мастер.
Внесите изменения в ваш README.md, сохраните их и используйте следующие команды, чтобы закоммитить изменения и замерджить их в мастер:
Теперь, когда вы знаете насколько просто работать с ветвлением, вас не удивит, что у многих людей своеобразный подход к управлению ветками.
Но есть один подход, который популярен в сообществе. Знакомьтесь, популярная модуль управления ветками Gitflow:
Схема выглядит беспорядочно, когда видишь ее впервые, так что пойдем по порядку. У нас есть две основные ветки: master и develop.
В ветке master содержится ровно тот же код, что и в рабочей (читай, продакт) версии проекта. А вся работа делается в ветке develop.
Во время работы на основе develop создаются так называемые feature-ветки. Их может быть неограниченное количество.
Далее, у нас есть ветка release, которая используется для подготовки к новому релизу проекта.
Наконец, есть ветка hotfix, которая служит для срочного исправления багов, найденных, например, на продакте.
Вот как в теории, происходит рабочий процесс в Gitflow:
1. Создается репозиторий
2. Репозиторий инициализируется
3. Начинается работа на ветке develop
4. Возникает необходимость опробовать новую штуку – создается feature-ветка и делаются коммиты
5. Закончив работу на feature-ветке, вы сливаете ее с develop
6. Если вы довольны текущей версией, но хотите продолжить работу, создается ветка release, куда перемещается текущая версия. Правка багов будет происходить на этой же ветке.
7. Когда с веткой release покончено, время слить ее в master и продолжить работу с develop
8. Кроме того, этот момент можно отметить на master-ветке
Gitflow как инструмент
Проделаем описанное выше шаг за шагом, но для начала убедитесь, что у вас есть gitflow-avh – инструмент для работы с Gitflow. На маке его можно установить с помощью homebrew:
gitflow-avh – это коллекция расширений для git, которая помогает избежать многих повторяющихся операций и вообще делает жизнь проще (это не точно). К примеру, при работе с feature-веткой, утилита проверит, слилась ли она в develop и удалит ее, если все прошло хорошо. Конечно, можно следовать модели Gitflow и самостоятельно, делая операции руками, но ведь проще же использовать готовое решение, так?
Как условие для начала работы, нам нужен git репозиторий. Если вы не начали читать статью с этого места, то у вас один уже есть. Теперь выполним команду git-flow init, как для git.
Далее будет несколько вопросов, но если оставить опции по умолчанию, эта команда просто создаст и назовет ветки в соответствие с моделью Gtiflow.
Когда все закончится, вы увидите, что находитесь на ветке develop. Теперь, создадим новую feature-ветку:
Урок № 3. Использование gitflow
Данная статья основывается на следующих материалах:
Gitflow Workflow — это модель рабочего процесса Git, которая была впервые опубликована и популяризована Винсентом Дриссеном из компании nvie. Gitflow Workflow предполагает выстраивание строгой модели ветвления с учетом выпуска проекта. Такая модель обеспечивает надежную основу для управления крупными проектами.
Gitflow идеально подходит для проектов, в которых цикл релиза протекает по графику. В этом рабочем процессе используются понятия и команды, которые были предложены в рамках процесса Feature Branch Workflow. Однако Gitflow привносит новые специфические роли для разных веток и определяет характер и частоту взаимодействия между ними. Помимо веток feature в рамках этого рабочего процесса используются отдельные ветки для подготовки, поддержки и регистрации выпусков. При этом вы по-прежнему можете пользоваться преимуществами процесса Feature Branch Workflow, такими как запросы pull, изолированные эксперименты и более эффективное командное взаимодействие.
Gitflow — это лишь методология работы с Git, то есть в ней определяется, какие виды веток необходимы проекту и как выполнять слияние между ними. Ниже мы познакомимся с назначением веток.
Содержание
Основные ветки (master) и ветки разработки (develop)
Для фиксации истории проекта в рамках этого процесса вместо одной ветки master используются две ветки. В ветке master хранится официальная история релиза, а ветка develop предназначена для объединения всех функций. Кроме того, для удобства рекомендуется присваивать всем коммитам в ветке master номер версии.
Отправка ветки develop выполняется в случае: если данная ветка отсутствует в удаленном репозитории или в нее были внесены изменения.
Для отправки ветки в удаленный репозиторий, необходимо выполнить команду:
Подготовка конфигурации к разработке
переключаемся на ветку develop
вариант 1, из данных git:
создаем пустую ИБ и собираем конфигурацию из файлов каталога src
создаем файл поставки конфигурации (*.cf) из собранной ИБ
вариант 2, из основного хранилища:
создаем поставку из основного хранилища, использованного ранее для начального коммита
Вариант 2 следует использовать, если получить сборку из основного хранилища возможно. Если схема с хранилищами более не используется, тогда используем вариант 1
сохраняем нашу текущую конфигурацию разработки в файл (если есть изменения относительно центрального хранилища)
отключаем поддержку и хранилище (если есть), полностью загружаем конфигурацию из созданного файла поставки
сравнением объединением вкатываем наши изменения из ранее сохраненного *.cf (если ранее сохраняли)
На текущем этапе мы можем приступить к разработке. Необходимо выполнить данные манипуляции для того чтобы гарантировать, что ваша конфигурация теперь имеет точное соответствие конфигурации репозитория.
Почему нельзя создавать файл поставки из центрального хранилища
Особое внимание уделяйте соответствию платформ. Разные версии выгружают по-разному.
Функциональные ветки (feature)
Обратите внимание, что объединение веток feature с веткой develop во всех отношениях совершается по модели Feature Branch Workflow. Но работа по Gitflow Workflow на этом не заканчивается.
Окончание работы с функциональной веткой
Вот тут стоит учесть один момент, за это время ветка develop могла уйти вперед, поэтому с учетом особенностей сравнения и объединения в 1С следует выполнить следующие действия:
получить все изменения ветки develop
выполнить сборку файла конфигурации из ветки develop (в виде файла поставки)
выполнить обновление конфигурации поддержки в вашей разработке (Конфигурация → Поддержка → Обновить конфигурацию)
после этого следует выполнить коммит в вашу ветку разработки
далее можно выполнять слияние веток
Отдельно стоит разобраться с применением rebase + сравнение объединение, возможно так будет правильнее.
Ветки выпуска (release)
Благодаря тому, что для подготовки выпусков используется специальная ветка, одна команда может дорабатывать текущий выпуск, в то время как другая команда продолжает работу над функциями для следующего. Это также позволяет разграничить этапы разработки (например, можно без труда посвятить неделю подготовке к версии 4.0 и действительно увидеть это в структуре репозитория).
Для завершения работы на ветке release используйте следующие команды:
Ветки исправления (hotfix)
Резюме
В этой статье мы рассмотрели модель работы Gitflow Workflow. Gitflow —это одна из многих методологий работы с Git, которые вы и ваша команда можете использовать.
Ключевые идеи, которые нужно запомнить о Gitflow:
Данная модель отлично подходит для организации рабочего процесса на основе релизов.
Работа по модели Gitflow включает создание отдельной ветки для исправлений ошибок в рабочей среде.
Последовательность действий при работе по модели Gitflow:
Когда работа над веткой релиза release завершена, она сливается в ветки develop и master после чего должна быть удалена.
Когда работа над веткой исправления hotfix завершена, она сливается в ветки develop и master после чего должна быть удалена.
Для чего нужен git flow
Прим.пер.: Перевод основан на статье из блога GitLab и является переработанной версией перевода на русский язык авторов Ivan Nemytchenko и pingusya.
Git значительно упрощает управление версиями по сравнению с более старыми системами контроля версий – такими, как SVN. Это дает широкий выбор стратегий ведения веток и вариаций рабочих процессов в репозитории. Почти любой вариант при этом более удачен по сравнению с методами до появления git. Однако многие организации используют рабочие процессы без четкой организации, излишне сложные или не интегрированные в системы отслеживания ошибок. Поэтому мы предлагаем рабочий процесс GitLab как четко определенную последовательность лучших практик. Он сочетает разработку, управляемую функциональностью и feature-ветки с инструментами отслеживания ошибок (issue tracking).
Компании, переходящие на git с других систем контроля версий, часто сталкиваются с проблемой разработки/выбора эффективного рабочего процесса. Данная статья описывает рабочий процесс GitLab, интегрирующий процесс разработки под git с системой отслеживания ошибок. Рабочий процесс предлагает простой, прозрачный и эффективный метод работы с git.
При переходе на работу с git вам нужно привыкнуть, что перед тем, как коммит поступит в общий доступ, необходимо пройти три шага. Обычные системы контроля версий используют только один шаг: отправка коммита из локальной копии на общий сервер.
Перейдя на git, вы вынуждены свыкнуться с фактом, что для того, чтобы поделиться кодом с коллегами, вам придется выполнить как минимум три шага:
Освоив эти три шага, можно перейти к изучению модели ветвления.
Поскольку многие компании, осваивающие git, не имеют представления о работе с системой, то запутаться очень легко. Основная проблема, с которой сталкиваются разработчики – наличие множества долгоживущих веток, каждая из которых содержит часть общих изменений. Трудно разобраться, в какой ветке разработка еще ведется, а какую требуется развернуть на production.
Как правило, в данной ситуации прибегают к применению стандартизированных схем, например, git flow или GitHub flow. Мы считаем, что их тоже можно улучшить и ниже излагаем набор методик, которые мы назвали GitLab flow.
Git flow и его недостатки
Git flow был одним из первых предложений по использованию веток git и привлек массу внимания в свое время. Git flow включает в себя мастер-ветку (master) и отдельную ветку для разработки (develop), а также дополнительные ветви для фич (feature), релизов (release) и патчей(hotfix). Работа ведется в ветке develop, затем переносится в ветвь релиза и, в конце концов, сливается в мастер-ветку. Git flow представляет собой четко определенный стандарт, но его сложность порождает две проблемы. Первая проблема: авторам приходится использовать ветку develop вместо master, поскольку master зарезервирован для кода, который отправляется в продакшен. Существует сложившийся обычай называть рабочую ветвь по умолчанию master, и делать ответвления и слияния с ней. Большинство инструментов по умолчанию используют это название для основной ветки и по умолчанию выводят именно ее, и бывает неудобно постоянно переключаться вручную на другую ветку.
Вторая проблема процесса git flow – сложности, возникающие из-за веток для патчей и для релиза. Подобная структура может подойти некоторым организациям, но для абсолютного большинства она просто убийственно излишяя. На сегодняшний день большинство компаний практикуют непрерывное развертывание (continuous delivery), что подразумевает, что основная ветвь по умолчанию может быть задеплоена (deploy). А значит, можно избежать использования веток для релиза и патчей, и всех связанных с ними хлопот, например, обратного слияния из веток релизов. Хотя для решения данных задач существуют специальные инструменты, они требуют документирование процесса и в целом осложняют работу. Часто разработчики по ошибке сливают изменения только в мастер-ветку, забывая про ветвь разработки. И корень всех этих проблем кроется в излишней сложности git flow при решении большинства задач. Кстати, формирование релизов вовсе не означает необходимости формировать патчи (hotfix).
GitHub flow – упрощенная альтернатива
В качестве ответа на стандарт git flow была сформулирована упрощенная альтернатива: процесс GitHub flow. В этом рабочем процессе используются только feature-ветки и ветка master. Схема очень чистая и простая, и многие компании с большим успехом применяют ее. Atlassian рекомендуют похожую стратегию, хотя они и перемещают (rebase) feature-ветки. Слияние всех ветвей в мастер-ветвь и частый деплой позволяют минимизировать объем кода, «путешествующего» по системе, что соответствует лучшим техникам упрощенной разработки (lean) и непрерывной доставки (continuous delivery). Но данная схема все же оставляет открытыми массу вопросов о деплое, средах, релизах и интеграции с баг-трекерами (issues). В стандарте GitLab flow мы предлагаем дополнительные рекомендации по данным вопросам.
Production branch с GitLab flow
GitHub flow предполагает, что вы в праве задеплоить в продакшен каждый раз после слияния feature-ветки в master. Это справедливо для SaaS-приложений, но во многих случаях такой сценарий неприменим. Один из примеров – ситуация, когда вы не можете управлять моментом релиза, например, если приложение для iOS должно пройти проверку в AppStore. Другой пример – когда у вас существуют строгий промежуток времени для деплоя (рабочие дни с 10 до 18 часов, когда вся команда в сборе), но слияние кода выполняется и в другое время. В этом случае вы можете создать ветвь production, отражающую состояние задеплоенного кода. Вы можете задеплоить новую версию, выполнив слияние кода из master-ветви в ветку production. Если вам необходимо знать состояние кода, задеплоенного в продакшен, вы можете просто выполнить checkout в production-ветку. Примерное время деплоя соответствует времени создания коммита слияния в системе контроля версий. Это время достаточно точное, если вы автоматически деплоите ветку в продакшен. Если вам нужно более точное время, вы можете посредством скрипта создавать метку для каждого деплоя. Данная схема предотвращает дополнительные затраты на подготовку релизов, создание меток и слияние, характерное для git flow.
Ветки сред с GitLab flow
Хорошей идеей может быть использовать среду, автоматически обновляющуюся к актуальному состоянию мастер-ветки. Лишь только в этом случае имя среды может отличаться от названия ветки.
Предположим, у вас имеется средя для подготовки (staging), среда для пре-продакшена (pre-production) и среда для продакшена (production). В этом случае мастер-ветвь деплоится на staging-среду. Когда кто-либо хочет задеплоить на pre-production, он создает запрос на слияние (merge request) из мастер-ветви в ветку pre-production. Ввод кода в эксплуатацию производится слиянием из ветки pre-production в ветвь production.
Ветви релизов с GitLab flow
Работать с release-ветками следует только в случае, если вам необходимо выпускать программное обеспечение во внешний мир (коробочные версии). В этом случае каждая ветвь содержит младшую версию программы (2-3-stable, 2-4-stable, и т.д.). Стабильная ветка использует в качестве точки отсчета master и создается как можно позднее. Создавая ветки как можно позднее, вы сводите к минимуму время, необходимое на исправление общих ошибок в многочисленных ветках. После анонса ветки релиза в эту ветвь попадают только исправления серьезных ошибок. По возможности исправления в первую очередь попадают в master, а уже затем отбираются (cherry_pick) в release-ветки. Такой подход не даст вам забыть перенести их в master и обратить внимание на ту же ошибку в последующих релизах. Такой подход именуется правилом ‘upstream first‘, которому следуют Google и Red Hat.
Каждый раз при включении фикса в ветвь релиза увеличивается на единицу патч-версия (для соответствия системе Семантического Версионирования) путем установки новой метки (tag). В некоторых проектах также используется ветвь stable, указывающая на тот же самый коммит, что и ветвь последнего релиза. В данной схеме организации рабочего процесса не принято использовать production-ветвь (или ветвь master в идеологии git flow).
Запросы Merge/pull с GitLab flow
Запросы на слияние и принятие изменений (merge/pull requests) создаются в приложениях для управления git-репозиториями. С их помощью вы просите ответственного сотрудника слить (merge) две ветки. Такие инструменты, как GitHub и Bitbucket используют термин «pull request«, поскольку первым ручным действием будет принятие изменений из feature-ветки. Инструменты GitLab и Gitorious оперируют термином «merge request«, поскольку слияние – финальное действие, требуемое от исполнителя. В данной статье мы будем использовать термин «запрос на слияние» (merge request).
Если вы работаете на feature-ветке дольше нескольких часов, рекомендуется поделиться промежуточным результатом работы с остальной частью команды. Это можно сделать, создав запрос на слияние, не адресуя его конкретному исполнителю, а вместо этого указав других пользователей в описании или в комментариях (/cc @mark @susan). Это означает, что ветка не готова для слияния, но неплохо бы получить отзывы коллег. Ваши коллеги могут комментировать непосредственно запрос на слияние или отдельные строки кода с помощью строчных комментариев. Запросы на слияние выполняют функцию инструмента для просмотра кода (code review), поэтому вам не потребуется использовать дополнительные инструменты вроде Gerrit или reviewboard. Если при обзоре выявится дефект, любой член команды может сделать коммит и выполнить команду push для исправления. Как правило, это делает создатель запроса merge/pull. Запросы merge/pull автоматически обновляются и отображают изменения кода, когда в ветку отправляются новые коммиты с помощью команды push.
Когда вы считаете, что код готов к слиянию, вы адресуете запрос на слияние человеку, который лучше всего знаком с базой кода, в которую вносятся изменения, и указываете всех остальных сотрудников, от которых вы хотели бы получить отзывы. Если ответственный сотрудник доволен результатом, то он выполняет слияние веток. Если же ответственный сотрудник не уверен в результате, он может закрыть запрос, не выполняя слияния.
В GitLab принято защищать долгоживущие ветки (например, master-ветвь), и, как правило, разработчики не могут изменять эти защищенные ветки, это нормально. Если вы хотите внести изменения в защищенную ветку, вы направляете запрос на слияние сотруднику с соответствующими правами доступа.
Ведение проблем с GitLab flow
GitLab flow призван сделать связь между кодом и системой отслеживания ошибок более прозрачной.
Любое значительное изменение кода должно начинаться с создания в системе задачи (issue) с описанием цели изменений. Очень важно иметь обоснование для каждого изменения кода. Это позволяет проинформировать всю команду и помогает разработчикам минимизировать охват ветки функционала. В GitLab каждое изменение кодовой базы начинается с заведения issue в системе отслеживания ошибок. Новая issue создается при условии, что для ее устранения потребуется серьезные усилия (не менее 1 часа работы). Для многих организаций это требование выполняется автоматически, поскольку сначала производится предварительная оценка трудозатрат на выполнение задачи. Названия issue должно описывать желаемое состояние системы, например «Как администратор, я хочу удалять пользователей, не получая ошибки» вместо «Админ не может удалять юзеров».
Когда вы готовы начать работу с кодом, вы создаете от master-ветви ветку для решения данной issue. Название ветки должно начинаться с номера проблемы, например ’15-require-a-password-to-change-it’.
Когда автор считает, что код готов, запрос на слияние адресуется ответственному рецензенту. Рецензент нажимает кнопку «слияние», если он уверен, что код готов для включения в master. В этом случае производится слияние кода и создается коммит слияния (merge commit), что позволяет в дальнейшем с легкостью отследить данное событие. Запросы на слияние всегда создают коммиты слияния, даже если коммит можно добавить без непосредственно слияния. Подобная стратегия слияния называется «без перемотки» (‘no fast-forward‘) в git. После слияния ветка функционала удаляется, поскольку в ней уже нет необходимости, в GitLab данное удаление является опциональным при слиянии.
Предположим, что было выполнено слияние ветки, но выявился дефект, и ошибка снова была открыта. В этом случае можно без проблем использовать прежнее название ветки, поскольку при слиянии она была удалена. В каждый момент времени существует не более одной ветки для каждой ошибки. При этом одна feature-ветка может решать несколько задач (issue).
Ссылки на ошибки и закрытие ошибок из запросов на слияние
Если вы хотите только упомянуть ошибку, не закрывая ее, вы можете просто оставить упоминание: » Предпочтительна неявная типизация. #12 «.
Если вы работаете над ошибкой, которая распространяется на несколько репозиториев, лучше всего создать отдельную ошибку для каждого репозитория и создать ссылки от всех к родительской ошибке.
Уплотнение коммитов при перемещении
Разработчикам рекомендуется почаще выполнять коммиты и отправлять изменения в удаленный репозиторий, чтобы остальные понимали, над чем работают коллеги. Это приводит к большому числу коммитов на одно изменение, что затрудняет понимание истории. Однако преимущества наличия постоянных идентификаторов для коммитов перевешивают эту трудность (пер.: имеется в виду возможность для других участников разработки опираться на актуальные коммиты из feature-веток). Для понимания контекста, в котором производились изменения, вcегда можно взглянуть на коммит слияния, группирующий все коммиты, когда код сливается с master.
После того, как слияние нескольких коммитов из feature-ветки в master произведено, откатиться обратно становится нетривиальной задачей. Если вы уплотнили (squash) все коммиты в один, то можно просто откатить этот коммит, но, как уже говорилось ранее, не следует перемещать (rebase) коммиты после отправки (push) в репозиторий. К счастью, git позволяет откатить слияние, произведенное некоторое время назад. Однако для этого требуется наличия конкретных коммитов слияния (merge commit) для тех коммитов, которые вы хотите отменить. Если вы отменяете слияние, а потом изменяете свое решение, вам придется отменить отмену (пер.: holy sh*t) вместо нового слияния, поскольку git не позволит вам слить код иным образом.
Не меняйте порядок коммитов при перемещении
Система git помимо прочего позволяет перемещать (rebase) коммиты feature-веток, располагая их вслед за коммитами master-а. Это предотвращает создание коммита слияния (merge commit) при слиянии мастер-ветки в feature-ветку и создает удобную и наглядную линейную историю. Однако, как и в случае с перемещением (squash), не следует перемещать коммиты, которые были отправлены на удаленный сервер с помощью команды push. Из-за этого вы не сможете переместить работу в процессе, которой вы уже поделились с коллегами (а именно такой подход мы крайне рекомендуем). Если вы используете перемещение (rebase) при обновлении feature-ветки, вам придется снова и снова разрешать похожие конфликты. Иногда можно повторно использовать сохраненные разрешения конфликтов (rerere), но если вы всё-таки откажетесь от практики перемещения (rebase), вам придется лишь один раз разрешить конфликты. Должен быть более удобный способ избежать множества конфликтов слияния.
«Я слышал, как люди заявляют, что используют CI, поскольку они запускают билды, возможно, используя CI сервер, на каждой ветке с каждым коммитом. Это называется непрерывным построением (continuous building), и это хорошая практика, но здесь нет интеграции, а значит, это не CI».
Для предотвращения многочисленных коммитов слияния нужно стараться ограничивать цикл жизни feature-веток, большинство из них должно занимать менее дня работы. Если ваши feature-ветки, как правило, требуют больше дня работы, обдумайте возможность выделения меньших блоков работы и/или используйте ротацию функций (feature toggle). Для работы с долгоживущими ветками, которые требуют более дня работы, существует две стратегии. В стратегии CI вы можете выполнять слияние с мастер-веткой в начале каждого дня, чтобы избежать затруднений в слиянии позже. В стратегии точек синхронизации (synchronization point) вы выполняете слияние только в четко установленные моменты времени, например в отмеченный релиз (tagged release). Линус Торвальдс поддерживает данную стратегию, поскольку в подобные моменты лучше известно состояние кода.
Перед принятием запроса на слияние, выберите «rebase before merge».
GitLab сделает попытку провести чистое перемещение перед слиянием веток. Если чистое перемещение невозможно, будет произведено обычное слияние. Если чистое перемещение возможно, при слиянии будет изменена история целевой ветки.
В завершение скажем, что вам следует избегать коммитов слияния, но не отказываться от них полностью. Ваша база кода должна оставаться чистой, но история должна отражать реальный ход работы. Разработка программного обеспечения требует множества путанных мелких шагов, и ваша история должна корректно отражать их. Вы можете использовать инструменты для просмотра сетевых графов коммитов, чтобы понять историю создания своего кода. Если вы используете перемещение, история изменяется, и инструменты не смогут это исправить, потому что они не умеют обрабатывать изменения идентификаторов коммитов.
Эмодзи в проблемах и запросах на слияние
Отправка (pushing) и удаление веток
Мы рекомендуем отправлять код из веток функционала с помощью push как можно чаще, даже если он еще не готов к просмотру. Следуя этому правилу, вы избежите ситуаций, когда несколько коллег случайно начинают работу над одной и той же проблемой. Конечно, этой ситуации можно избежать простым назначением исполнителя проблемы в системе отслеживания ошибок. Но зачастую кто-то просто забывает назначить исполнителя в баг-трекере. После слияния ветки ее следует удалить из системы управления исходным кодом. В GitLab и подобных системах эту возможность предлагают при слиянии. Это гарантирует, что обзор веток в системе управления репозиторием показывает только выполняемую работу. Кроме того, если кто-то заново открывает проблему в новой ветке, можно использовать прежнее имя без всяких проблем. При новом открытии проблемы необходимо создать новый запрос на слияние.
Частые коммиты с правильными комментариями
Мы рекомендуем выполнять коммиты как можно раньше и чаще. Каждый раз, когда у вас имеется рабочий набор кода и тестов, вы можете выполнить коммит. Преимущество в том, что если доработка или рефакторинг что-то ломают, достаточно просто откатиться на рабочую версию. Такой подход серьезно меняет точку зрения для программистов, работавших ранее с SVN, поскольку они выполняли коммиты, когда работа была готова для общего использования. Правильный подход: использовать запросы на слияние и на принятие изменений (merge/pull requests) с несколькими коммитами, когда вы готовы поделиться рабочим кодом с другими. Комментарий к коммиту должен отражать ваши намерения, а не содержимое коммита. Содержимое коммита и так легко видно, вопрос в том, зачем вы выполняли работу. Пример хорошего комментария к коммиту:
«Скомбинированы шаблоны для оптимизации user views».
Можно назвать несколько терминов, которые не годятся для комментирования коммита, поскольку содержат недостаточно информации: изменение, улучшение и реорганизация (рефакторинг). Термин «исправление» или «фикс» – тоже тревожный признак, если только он не идет в конце описания коммита и не ссылается на номер ошибки. Более подробную информацию о форматировании комментариев к коммитам вы найдете в этом прекрасном посте в блоге Tim Pope.
Тестирование перед слиянием
Слияние с другим кодом
