Как назвать ветку в git
Почти каждая система контроля версий (СКВ) в какой-то форме поддерживает ветвление. Используя ветвление, Вы отклоняетесь от основной линии разработки и продолжаете работу независимо от неё, не вмешиваясь в основную линию. Во многих СКВ создание веток — это очень затратный процесс, часто требующий создания новой копии каталога с исходным кодом, что может занять много времени для большого проекта.
Некоторые люди, говоря о модели ветвления Git, называют ее «киллер-фича», что выгодно выделяет Git на фоне остальных СКВ. Что в ней такого особенного? Ветвление Git очень легковесно: операция создания ветки выполняется почти мгновенно, переключение между ветками туда-сюда, обычно, также быстро. В отличие от многих других СКВ, Git поощряет процесс работы, при котором ветвление и слияние выполняется часто, даже по несколько раз в день. Понимание и владение этой функциональностью дает вам уникальный и мощный инструмент, который может полностью изменить привычный процесс разработки.
О ветвлении в двух словах
Для точного понимания механизма ветвлений, необходимо вернуться назад и изучить то, как Git хранит данные.
Как вы можете помнить из Что такое Git?, Git не хранит данные в виде последовательности изменений, он использует набор снимков (snapshot).
Когда вы делаете коммит, Git сохраняет его в виде объекта, который содержит указатель на снимок (snapshot) подготовленных данных. Этот объект так же содержит имя автора и email, сообщение и указатель на коммит или коммиты непосредственно предшествующие данному (его родителей): отсутствие родителя для первоначального коммита, один родитель для обычного коммита, и несколько родителей для результатов слияния двух и более веток.
Предположим, у вас есть каталог с тремя файлами и вы добавляете их все в индекс и создаёте коммит. Во время индексации вычисляется контрольная сумма каждого файла (SHA-1 как мы узнали из Что такое Git?), затем каждый файл сохраняется в репозиторий (Git называет такой файл блоб — большой бинарный объект), а контрольная сумма попадёт в индекс:
Ваш репозиторий Git теперь хранит пять объектов: три блоб объекта (по одному на каждый файл), объект дерева каталогов, содержащий список файлов и соответствующих им блобов, а так же объект коммита, содержащий метаданные и указатель на объект дерева каталогов.
Если вы сделаете изменения и создадите ещё один коммит, то он будет содержать указатель на предыдущий коммит.
Создание новой ветки
В результате создаётся новый указатель на текущий коммит.
Переключение веток
Какой в этом смысл? Давайте сделаем ещё один коммит:
Если выполнить команду git log прямо сейчас, то в её выводе только что созданная ветка «testing» фигурировать не будет.
Ветка никуда не исчезла; просто Git не знает, что именно она вас интересует, и выводит наиболее полезную по его мнению информацию. Другими словами, по умолчанию git log отобразит историю коммитов только для текущей ветки.
Важно запомнить, что при переключении веток в Git происходит изменение файлов в рабочем каталоге. Если вы переключаетесь на старую ветку, то рабочий каталог будет выглядеть так же, как выглядел на момент последнего коммита в ту ветку. Если Git по каким-то причинам не может этого сделать — он не позволит вам переключиться вообще.
Давайте сделаем еще несколько изменений и создадим очередной коммит:
Ветка в Git — это простой файл, содержащий 40 символов контрольной суммы SHA-1 коммита, на который она указывает; поэтому операции с ветками являются дешёвыми с точки зрения потребления ресурсов или времени. Создание новой ветки в Git происходит так же быстро и просто как запись 41 байта в файл (40 знаков и перевод строки).
Это принципиально отличает процесс ветвления в Git от более старых систем контроля версий, где все файлы проекта копируются в другой подкаталог. В зависимости от размера проекта, операции ветвления в таких системах могут занимать секунды или даже минуты, когда в Git эти операции мгновенны. Поскольку при коммите мы сохраняем указатель на родительский коммит, то поиск подходящей базы для слияния веток делается автоматически и, в большинстве случаев, очень прост. Эти возможности побуждают разработчиков чаще создавать и использовать ветки.
Давайте посмотрим, почему и вам имеет смысл делать так же.
Правильное именование веток
Есть ли широко используемые шаблоны для наименования веток в системе git? Если есть статьи или другие обучающие материалы по данной тематике, пожалуйста, приложите их к ответу на данный вопрос.
3 ответа 3
Git Flow
Основные ветки
Ветки master и develop считаются основными ветками, их смысл состоит в том, что они существуют до тех пор, пока существует сам проект. В ветке master всегда хранится стабильная версия проекта (релиз), в ветке develop хранится текущая рабочая версия проекта.
Вспомогательные ветки
Кроме основных веток существуют так же и вспомогательные, которые используются для добавлений фич в проект, реализации багфиксов и подготовки релизов. Каждая такая ветка существует до тех пор, пока ведётся работа над задачей, для которой она была создана, после чего она удаляется, предварительно сливаясь с одной из основных веток (или сразу с двумя), если задача была успешно выполнена.
Используются следующие типы веток:
GitLab Flow
GitLab Flow даёт достаточно подробные рекомендации по именованию веток.
Стабильные ветки
Это правило даёт максимальный эффект, когда вы настраиваете автоматическое развертывание приложения в соответствующую среду. То есть:
Версионные ветки
Если вы выпускаете поддерживаемые версии продукта, используйте для них версионные ветки (version branches) с единообразными именами, содержащими номер версии и некоторый идентификатор версионной ветки, например:
Ветки фич
Для решения конкретных задач из трекера (системы учета задач) используются отдельные ветки фич (feature branches). У каждой задачи есть номер и название (заголовок). Соответственно, ветка для этой задачи должна иметь вид:
То есть, если в нашем трекере есть две задачи:
То соответствующие ветки должны называться:
Если заголовки задач у вас в кириллице или любом другом не-ASCII алфавите, то, пожалуй, названия веток лучше переводить. Наверное, можно и транслит использовать, но мне кажется, что его сложно читать. На этот счёт в GitLab Flow нет конкретного правила, поэтому вам нужно самостоятельно выработать внутрикомандное правило. Тут допустимы вольности, потому что вы всегда можете точно сопоставить ветку с задачей по их номеру.
GitHub flow
По сравнению с другими вариантами, GitHub Flow проще, но и ограниченнее.
Он неплох для хорошо дисциплинированных команд, способных выпускать в продакшн каждую фичу сразу по мере готовности без серьёзных поломок. Это требует хорошего автоматического QA/QC и/или стальных нервов.
В нём ветки делятся на две категории:
Всё. Больше ничего нет. Релизы обозначаются метками (tag), хотфиксы фактически приводят к новым релизам и, соответственно, новым меткам.
Но из-за ограниченности и простоты, как правило, его расширяют.
К примеру, по мере развития проекта обычно возникают версионные ветки. Скажем, если намечается группа версий, в которую придётся «бэкпортить» (backport, портировать на старую версию) новые фичи или исправления, то для неё можно создать свою именованную ветку, эту группу версий объединяющую, обычно по неполному номеру версии или маске:
Как Переименовать Ветку Git (Локальную и Удалённую)
Если вы работаете в Git, то вам, наверняка, знакома ситуация, когда ветка случайно была названа неправильно или просто нужно сменить её название, чтобы лучше организовать проект. В любом случае это довольно распространённое явление, когда вам нужно переименовать ветку Git, локальную или удалённую. В этом руководстве мы покажем, как это сделать. А также кратко объясним, что такое Git-репозиторий и некоторые полезные команды Git.
Установите и используйте Git вместе с мощным и надёжным хостингом от Hostinger.
Как Переименовать Локальную Ветку Git?
Прежде чем мы начнём, убедитесь, что вы выбрали ветку, которую хотите переименовать:
Если вы хотите посмотреть все локальные ветки, используйте следующую команду:
Разобравшись с этим, выполните следующее действие:
Как Переименовать Удалённую Ветку Git?
Хотя удалённую ветку и нельзя переименовать напрямую, процесс довольно простой и состоит лишь с трёх шагов:
Как Создать Новую Локальную Ветку Git?
Прежде чем создавать новую ветку, обратите внимание, что каждый репозиторий, о котором мы будем говорить дальше, содержит основную стабильную ветку (master branch), содержащую изменения, готовые для продакшена. Когда вы создаёте ветку, всё, что делает Git, это создаёт новый указатель.
Мы можем создать новую локальную ветку, выполнив следующие шаги.
Или же вы можете создать новую ветку и переключиться на неё:
Вы также можете клонировать ветку и затем перейти на неё:
Как Удалить Локальную Ветку Git?
Чтобы удалить локальную ветку, вы можете использовать одну из следующих команд Git:
Опция -d (–delete) удалит локальную ветку, если вы уже запушили и смержили её с удалённой веткой.
Опция -D (–delete –force) удалит локальную ветку независимо от того, успели вы запушить и смержить её с удалённой веткой или нет.
Как Удалить Удалённую Ветку Git?
Вы также можете удалить удалённую ветку и указать, как название удалённого репозитория, так и ветки. В большинстве случаев, название удалённого сервера по умолчанию — «origin«. Команда будет выглядеть так:
Осмотр и Сравнение
В Git вы можете просмотреть все внесённые вами изменения в любое время. Чтобы увидеть эти изменения, введите следующую команду:
Или, для более подробной информации:
Что Такое Ветка Git?
Git — это распределённая система контроля версий (DVCS), в которой все члены команды имеют доступ к полной версии проекта. Её главная задача — помогать в управлении проектам, сделать процесс разработки эффективным, гибким и безопасным.
Ветки — это отдельные линии развития вашего проекта. Они позволяют работать параллельно с master веткой, при этом не влияя на неё. Когда же ваша часть кода готова, вы можете выполнить слияние, или мерж.
Ветвление Git позволяет создавать, удалять и смотреть другие ветки. Кроме того, ветка действует как указатель на моментальный снимок изменений (snapshot), которые вы внесли или хотите внести в файлы проекта. Это полезно в ситуациях, когда вы хотите добавить дополнительную функцию или устранить баг.
Ветка не только инкапсулирует изменения, но также гарантирует, что нестабильный код не попадёт к файлам основного проекта. Как только вы закончите обновлять код в ветке, вы сможете смержить изменения в ветку master.
Что Такое Git-репозиторий?
Репозиторий работает как папка для проекта. Он содержит все файлы и хранит их историю изменений. Репозитории могут быть частными или общедоступными. Вы также можете делиться ими с другими людьми в вашей организации.
Когда вы инициализируете Git-репозиторий, в корне папки проекта автоматически создаётся каталог .git/. Здесь Git отслеживает изменения в файлах проекта, сохраняет объекты, ссылки и дополнительную информацию для управления репозиториями.
Будьте осторожны, ведь если вы случайно удалите папку .git/, вы потеряете всю истерию вашего проекта.
Как Клонировать Удалённый Репозиторий?
Чтобы клонировать репозиторий, мы будем использовать команду Git clone. Кроме того, вам также необходимо указать URL-адрес репозитория:
Для SSH:
Дополнительная Информация о Git
Если вам нужна информация о том, как пользоваться Git, обратитесь к официальной документации, доступной онлайн. Кроме того, рекомендуем ознакомиться с нашими руководствами об основных командах Git, о том, как использовать PuTTY SSH-терминал для подключения к вашей учётной записи хостинга или VPS-серверу, как установить Git (англ) в Ubuntu, а также подробное руководство по GitHub.
Итоги
Теперь вы знаете, как управлять ветками с помощью различных команд. Вы можете создать или переименовать ветку Git, посмотреть список существующих веток или удалить какую-то из них.
Мы надеемся, что вам понравилось это руководство. И с нетерпением ждём вас в следующем!
Ольга уже около пяти лет работает менеджером в сфере IT. Написание технических заданий и инструкций — одна из её главных обязанностей. Её хобби — узнавать что-то новое и создавать интересные и полезные статьи о современных технологиях, веб-разработке, языках программирования и многом другом.
Удачная модель ветвления для Git
В этой статье я представляю модель разработки, которую использую для всех моих проектов (как рабочих, так и частных) уже в течение года, и которая показала себя с хорошей стороны. Я давно собирался написать о ней, но до сих пор не находил свободного времени. Не буду рассказывать обо всех деталях проекта, коснусь лишь стратегии ветвления и управления релизами.
В качестве инструмента управления версиями всего исходного кода она использует Git.
Почему Git?
За полноценным обсуждением всех достоинств и недостатков Git в сравнении с централизованными системами контроля версий обращайтесь к всемирной сети. Там Вы найдёте достаточное количество споров на эту тему. Лично же я, как разработчик, на данный момент предпочитаю Git всем остальным инструментам. Git реально смог изменить отношение разработчиков к процессам слияния и ветвления. В классическом мире CVS/Subversion, из которого я пришёл, ветвление и слияние обычно считаются опасными («опасайтесь конфликтов слияния, они больно кусаются!»), и потому проводятся как можно реже.
Но с Git эти действия становятся исключительно простыми и дешёвыми, и потому на деле они становятся центральными элементами обычного ежедневного рабочего процесса. Просто сравните: в книгах по CVS/Subversion ветвление и слияние обычно рассматриваются в последних главах (для продвинутых пользователей), в то время как в любой книге про Git они бывают упомянуты уже к третьей главе (основы).
Благодаря своей простоте и предсказуемости, ветвление и слияние больше не являются действиями, которых стоит опасаться. Теперь инструменты управления версиями способны помочь в ветвлении и слиянии больше, чем какие-либо другие.
Но хватит говорить об инструментах, давайте перейдём к модели разработки. Модель, которую я хочу представить, — это, по сути, просто набор процедур, которые исполняет каждый член команды, чтобы все вместе могли достичь высокой управляемости процесса разработки.
Децентрализованный, но централизованный
Предлагаемая модель ветвления опирается на конфигурацию проекта, содержащую один центральный «истинный» репозиторий. Замечу, что этот репозиторий только считается центральным (так как Git является DVCS, у него нет такой вещи, как главный репозиторий, на техническом уровне). Мы будем называть этот репозиторий термином origin, т.к. это имя и так знакомо всем пользователям Git.
Каждый разработчик забирает и публикует изменения (pull & push) в origin. Но, помимо централизованных отношений push-pull, каждый разработчик также может забирать изменения от остальных коллег внутри своей микро-команды. Например, этот способ может быть удобен в ситуации, когда двое или более разработчиков работают вместе над большой новой фичей, но не могут издать незавершённую работу в origin раньше времени. На картинке выше изображены подгруппы Алисы и Боба, Алисы и Дэвида, Клэр и Дэвида.
Технически это реализуется несложно: Алиса создаёт удалённую ветку Git под названием bob, которая указывает на репозиторий Боба, а Боб делает то же самое с её репозиторием.
Главные ветви
Мы считаем ветку origin/master главной. То есть, исходный код в ней должен находиться в состоянии production-ready в любой произвольный момент времени.
Ветвь origin/develop мы считаем главной ветвью для разработки. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза. Эту ветку также можно назвать «интеграционной». Она служит источником для сборки автоматических ночных билдов.
Когда исходный код в ветви разработки (develop) достигает стабильного состояния и готов к релизу, все изменения должны быть определённым способом влиты в главную ветвь (master) и помечены тегом с номером релиза. Ниже мы рассмотрим этот процесс в деталях.
Следовательно, каждый раз, когда изменения вливаются в главную ветвь (master), мы по определению получаем новый релиз. Мы стараемся относиться к этому правилу очень строго, так что, в принципе, мы могли бы использовать хуки Git, чтобы автоматически собирать наши продукты и выкладывать их на рабочие сервера при каждом коммите в главную ветвь (master).
Вспомогательные ветви
Помимо главных ветвей master и develop, наша модель разработки содержит некоторое количество типов вспомогательных ветвей, которые используются для распараллеливания разработки между членами команды, для упрощения внедрения нового функционала (features), для подготовки релизов и для быстрого исправления проблем в производственной версии приложения. В отличие от главных ветвей, эти ветви всегда имеют ограниченный срок жизни. Каждая из них в конечном итоге рано или поздно удаляется.
Конечно же, с технической точки зрения, у этих ветвей нет ничего «специфического». Разбиение ветвей на категории существует только с точки зрения того, как они используются. А во всём остальном это старые добрые ветви Git.
Ветви функциональностей (feature branches)
Могут порождаться от: develop
Должны вливаться в: develop
Соглашение о наименовании: всё, за исключением master, develop, release-* или hotfix-*
Ветви функциональностей (feature branches), также называемые иногда тематическими ветвями (topic branches), используются для разработки новых функций, которые должны появиться в текущем или будущем релизах. При начале работы над функциональностью (фичей) может быть ещё неизвестно, в какой именно релиз она будет добавлена. Смысл существования ветви функциональности (feature branch) состоит в том, что она живёт так долго, сколько продолжается разработка данной функциональности (фичи). Когда работа в ветви завершена, последняя вливается обратно в главную ветвь разработки (что означает, что функциональность будет добавлена в грядущий релиз) или же удаляется (в случае неудачного эксперимента).
Ветви функциональностей (feature branches) обычно существуют в репозиториях разработчиков, но не в главном репозитории (origin).
Создание ветви функциональности (feature branch)
При начале работы над новой функциональностью делается ответвление от ветви разработки (develop).
Добавление завершённой функциональности в develop
Завершённая функциональность (фича) вливается обратно в ветвь разработки (develop) и попадает в следующий релиз.
Конечно, такой подход создаёт некоторое дополнительное количество (пустых) объектов коммитов, но получаемая выгода более чем оправдывает подобную цену.
Ветви релизов (release branches)
Могут порождаться от: develop
Должны вливаться в: develop и master
Соглашение о наименовании: release-*
Ветви релизов (release branches) используются для подготовки к выпуску новых версий продукта. Они позволяют расставить финальные точки над i перед выпуском новой версии. Кроме того, в них можно добавлять минорные исправления, а также подготавливать метаданные для очередного релиза (номер версии, дата сборки и т.д.). Когда вся эта работа выносится в ветвь релизов, главная ветвь разработки (develop) очищается для добавления последующих фич (которые войдут в следующий большой релиз).
Новую ветку релиза (release branch) надо порождать в тот момент, когда состояние ветви разработки полностью или почти полностью соответствует требованиям, соответствующим новому релизу. По крайней мере, вся необходимая функциональность, предназначенная к этому релизу, уже влита в ветвь разработки (develop). Функциональность, предназначенная к следующим релизам, может быть и не влита. Даже лучше, если ветки для этих функциональностей подождут, пока текущая ветвь релиза не отпочкуется от ветви разработки (develop).
Очередной релиз получает свой номер версии только в тот момент, когда для него создаётся новая ветвь, но ни в коем случае не раньше. Вплоть до этого момента ветвь разработки содержит изменения для «нового релиза», но пока ветка релиза не отделилась, точно неизвестно, будет ли этот релиз иметь версию 0.3, или 1.0, или какую-то другую. Решение принимается при создании новой ветви релиза и зависит от принятых на проекте правил нумерации версий проекта.
Создание ветви релиза (release branch)
Ветвь релиза создаётся из ветви разработки (develop). Пускай, например, текущий изданный релиз имеет версию 1.1.5, а на подходе новый большой релиз, полный изменений. Ветвь разработки (develop) готова к «следующему релизу», и мы решаем, что этот релиз будет иметь версию 1.2 (а не 1.1.6 или 2.0). В таком случае мы создаём новую ветвь и даём ей имя, соответствующее новой версии проекта:
Мы создали новую ветку, переключились в неё, а затем выставили номер версии (bump version number). В нашем примере bump-version.sh — это вымышленный скрипт, который изменяет некоторые файлы в рабочей копии, записывая в них новую версию. (Разумеется, эти изменения можно внести и вручную; я просто обращаю Ваше внимание на то, что некоторые файлы изменяются.) Затем мы делаем коммит с указанием новой версии проекта.
Эта новая ветвь может существовать ещё некоторое время, до тех пор, пока новый релиз окончательно не будет готов к выпуску. В течение этого времени к этой ветви (а не к develop) могут быть добавлены исправления найденных багов. Но добавление крупных новых изменений в эту ветвь строго запрещено. Они всегда должны вливаться в ветвь разработки (develop) и ждать следующего большого релиза.
Закрытие ветви релиза
Когда мы решаем, что ветвь релиза (release branch) окончательно готова для выпуска, нужно проделать несколько действий. В первую очередь ветвь релиза вливается в главную ветвь (напоминаю, каждый коммит в master — это по определению новый релиз). Далее, этот коммит в master должен быть помечен тегом, чтобы в дальнейшем можно было легко обратиться к любой существовавшей версии продукта. И наконец, изменения, сделанные в ветви релиза (release branch), должны быть добавлены обратно в разработку (ветвь develop), чтобы будущие релизы также содержали внесённые исправления багов.
Первые два шага в Git:
Теперь релиз издан и помечен тегом.
Чтобы сохранить изменения и в последующих релизах, мы должны влить эти изменения обратно в разработку. Делаем это так:
Этот шаг, в принципе, может привести к конфликту слияния (нередко бывает, что причиной конфликта является изменение номера версии проекта). Если это произошло, исправьте их и издайте коммит.
Теперь мы окончательно разделались с веткой релиза. Можно её удалять, потому что она нам больше не понадобится:
Ветви исправлений (hotfix branches)
Могут порождаться от: master
Должны вливаться в: develop и master
Соглашение о наименовании: hotfix-*
Ветви для исправлений (hotfix branches) весьма похожи на ветви релизов (release branches), так как они тоже используются для подготовки новых выпусков продукта, разве лишь незапланированных. Они порождаются необходимостью немедленно исправить нежелательное поведение производственной версии продукта. Когда в производственной версии находится баг, требующий немедленного исправления, из соответствующего данной версии тега главной ветви (master) порождается новая ветвь для работы над исправлением.
Смысл её существования состоит в том, что работа команды над ветвью разработки (develop) может спокойно продолжаться, в то время как кто-то один готовит быстрое исправление производственной версии.
Создание ветви исправлений (hotfix branch)
Ветви исправлений (hotfix branches) создаются из главной (master) ветви. Пускай, например, текущий производственный релиз имеет версию 1.2, и в нём (внезапно!) обнаруживается серьёзный баг. А изменения в ветви разработки (develop) ещё недостаточно стабильны, чтобы их издавать в новый релиз. Но мы можем создать новую ветвь исправлений и начать работать над решением проблемы:
Не забывайте обновлять номер версии после создания ветви!
Теперь можно исправлять баг, а изменения издавать хоть одним коммитом, хоть несколькими.
Закрытие ветви исправлений
Когда баг исправлен, изменения надо влить обратно в главную ветвь (master), а также в ветвь разработки (develop), чтобы гарантировать, что это исправление окажется и в следующем релизе. Это очень похоже на то, как закрывается ветвь релиза (release branch).
Прежде всего надо обновить главную ветвь (master) и пометить новую версию тегом.
Следующим шагом переносим исправление в ветвь разработки (develop).
У этого правила есть одно исключение: если в данный момент существует ветвь релиза (release branch), то ветвь исправления (hotfix branch) должна вливаться в неё, а не в ветвь разработки (develop). В этом случае исправления войдут в ветвь разработки вместе со всей ветвью релиза, когда та будет закрыта. (Хотя, если работа в develop требует немедленного исправления бага и не может ждать, пока будет завершено издание текущего релиза, Вы всё же можете влить исправления (bugfix) в ветвь разработки (develop), и это будет вполне безопасно).
И наконец, удаляем временную ветвь:
Заключение
Хотя в этой модели ветвления совершенно нет ничего принципиально нового, «большая картинка», с которой начинается эта статья, зарекомендовала себя в наших проектах с самой лучшей стороны. Она формирует элегантную мысленную модель, которую легко полностью охватить одним взглядом, и которая позволяет сформировать у команды совместное понимание процессов ветвления и слияния, действующих на проекте.
Высококачественная PDF-версия этой картинки свободна для скачивания здесь. Распечатайте её и повесьте у себя на стену, чтобы к ней можно было обратиться в любой момент.
Прим. переводчика: статья не новая, ссылка на оригинал уже появлялась на хабре. Этот перевод — для тех, кому английский ещё даётся не так легко (а также для моих коллег, среди которых я занимаюсь пропагандой, хехе). Для автоматизации описанных в статье процедур автор создал проект gitflow, который можно найти на github.