.webp)
.webp)
Введение
За счет ветвления в Git разработчики могут работать сразу над несколькими функциями или изменениями, не мешая друг другу и не меняя основную кодовую базу. Поскольку ветки – это неотъемлемая часть Git, были приняты некоторые соглашения о присвоении им имен, призванные поддерживать понятность и структурированность кодовой базы.
Особенно важно придерживаться методических рекомендаций по присвоению имен, когда вы работаете над проектом совместно с другими разработчиками. Это позволит избежать путаницы и обеспечит планомерность работы каждого.
В этой статье мы расскажем о различных соглашениях о присвоении имен веткам Git и поделимся рекомендациями, как создать структурированный репозиторий.
Типы веток в Git
Ветки в Git можно разделить на два типа в зависимости от их продолжительности жизни и типа вносимых ими изменений:
- Постоянные ветки
- Временные ветки
Такое разделение позволяет командам эффективнее управлять своими рабочими процессами в Git. Правильно выбранные имена гарантируют, что ветки с длительным жизненным циклом будут стабильными, а временные ветки будут использоваться для конкретных сиюминутных задач и не будут наводить беспорядок в репозитории.
В следующих разделах мы подробнее описали эти типы веток.
Постоянные ветки
Постоянные ветки Git – это ветки с длительным жизненным циклом, которые являются надежным и структурированным способом организации текущей работы. Эти ветки доступны в репозитории на постоянной основе, а их имена довольно просты.
Вот некоторые постоянные ветки Git:
- Основная ветка (master/main). Производственная ветка в репозитории Git, используемая по умолчанию, которая должна быть неизменно стабильной. Разработчики могут включать изменения в основную ветку только после рецензирования и тестирования кода. Все участники проекта обязаны поддерживать стабильность и актуальность основной ветки.
- Ветка разработки (dev). Главная ветка разработки, которая выступает в качестве центрального узла для разработчиков, где они могут интегрировать свои новые функции, исправлять какие-то ошибки и вносить любые другие изменения. Ее основная задача – быть тем местом, где разработчики могут вносить изменения, не реализовывая их непосредственно в основной ветке. Разработчики тестируют, рецензируют и только потом включают эти изменения в основную ветку.
- Ветка контроля качества (QA/test). Эта ветка содержит весь код, готовый к проверке качества и автоматизированному тестированию. Тестирование качества – это необходимый этап перед добавлением каких-либо изменений в производственную среду, который позволяет поддерживать стабильность кодовой базы.
Временные ветки
Временные ветки – это одноразовые ветки с непродолжительным жизненным циклом. Эти ветки служат конкретным сиюминутным целям и чаще всего потом удаляются.
Вот некоторые временные ветки Git:
- Bugfix-ветка. Эта ветка содержит код с ошибками, которые необходимо исправить как можно скорее. Это может быть отклоненный код из feature-веток, который необходимо исправить перед внедрением.
- Hotfix-ветка. Это ветка для внедрения временного решения в ошибочный код без соблюдения стандартной процедуры. Эта ветка используется только в экстренных случаях и когда необходимо быстро внести исправление. Разработчики включают hotfix-ветку непосредственно в производственную ветку, а затем уже в ветку разработки.
- Feature-ветка. Эта ветка предназначена для добавления, изменения конфигурации и удаления функций. Эта ветка является частью ветки разработки. После того, как все изменения будут внесены, разработчики включают ее обратно в ветку разработки.
- Experimental-ветка. Эта ветка выступает в качестве площадки для разработки новых функций или реализации каких-то своих идей, которые не являются частью релиза или спринта. Эта ветка предназначена для испытания новых вещей.
- WIP-ветка. Разработчики используют WIP-ветку (Work In Progress – незавершенные работы) для разработки или испытания новых функций. Эти ветки не обязательно должны являться частью обычного рабочего процесса разработки. Они создаются для отдельно взятого проекта и зачастую бывают неофициальными, безо всяких конкретных или стандартизированных правил.
- Merging-ветка. Это временная ветка, которая используется для разрешения конфликтов слияния. Такие конфликты могут возникать при добавлении последней разработки и feature или hotfix-ветки в другую ветку. Эта ветка также полезна при объединении двух feature-ветвей, разработанных несколькими участниками. Этот процесс включает в себя слияние, проверку и одобрения окончательного варианта изменений.
Этот далеко не полный список. Существует множество других неплохих форматов и соглашений о присвоении имен для временных ветвей какого-то конкретного проекта.
На следующей диаграмме показан пример рабочего процесса в репозитории Git с несколькими постоянными и временными ветками:
Соглашения о присвоении имен веткам Git
Большая часть соглашений о присвоении имен веткам, как правило, определяются самим проектом или командой. Вы можете использовать те имена, которые вам больше всего подходят, но при условии, что вы будете придерживаться единого стиля на протяжении всего проекта.
Ниже представлены несколько основных соглашений о присвоении имен веткам Git, которые многие разработчики применяют при работе в системе контроля версий.
Использование дефисов и слешей в качестве разделителей
Одно из самых распространенных соглашений о присвоении имен – это использование слеша (/) или дефиса (-) в качестве разделителя в имени ветки. Эти символы облегчают чтение названия ветки за счет того, вам не нужно разделять слова в уме.
Например, сравните следующие имена ветвей:
featurenewuserregistrationworkflowwithemailverificationи
feature/new-user-registration-workflow-with-email-verificationДанное имя ветки является описательным и содержит информацию о своей функции, в данном случае – добавить новый рабочий процесс регистрации пользователя с проверкой электронной почты. При этом гораздо проще разобрать для чего она нужна, когда в названии используются разделители – слеш и дефис.
Помимо этого, старайтесь давать веткам более короткие имена. Чтобы улучшить приведенное выше имя, его можно сократить:
feature/email-verification-workflowИтак, основными преимуществами использования разделителей в названии ветки являются:
- Улучшенная читаемость, препятствующая возникновению путаницы
- Более легкое управление, особенно при работе с большим количеством веток
Разделяя слова дефисами и слешами и используя строчные буквы, вы можете обеспечить лучшую читаемость.
Примечание: не используйте пробелы в именах ветвей, так как в таком случае будет создан «осиротевший» коммит, к которому будет невозможно получить доступ ни из одного коммита в репозитории. Также избегайте использования каких-либо других специальных символов, помимо дефисов и слешей, так как они могут вызвать проблемы в Git.
Использование цифр
Если для создания трабл-тикетов и разработки новых функций вы используете Jira, то будет полезно добавить номер тикета к названию ветки. Номер тикета в названии ветки Git помогает отслеживать ход работы над этой веткой. Кроме того, номера тикетов Jira уникальны, так что вероятность, что две ветки будут иметь одинаковые имена, нулевая.
Если вы пользуетесь внешней системой для отслеживания хода разработки, то вы можете указать в названии ветки внешний ID отслеживания. Но не используйте только цифры. Дайте все же ветке описательное имя, чтобы пояснить, в чем ее назначение.
Например, следующее название ветки содержит ID отслеживания и описание:
wip/8712-add-login-moduleИз названия мы можем понять, что это WIP-ветка. Далее следует ID отслеживания и описание ее назначения.
Использование ключевых слов
Чаще всего название ветки начинается с ключевого слова, которое определяет назначение ветки. Как правило, эти ключевые слова обозначают тип ветки, например,
- bugfix
- hotfix
- wip
- feature и т.д.
Такое распределение по категориям помогает разработчикам, совместно работающим над проектом, понимать назначение той или иной ветки. Ключевые слова обычно отделяются от остальной части названия слешем (/).
Например, в начале следующего имени ветки используется ключевое слово, показывающее ее назначение:
bugfix/fix-login-errorЗадача ветки – исправление ошибки авторизации. Она создана именно для этой цели.
Использование имени автора
Еще одно соглашение – это использование имени автора в названии ветки Git. Таким образом, можно пояснить, кто из разработчиков работал над этой веткой, а также легко отслеживать, кто работает над той или иной функцией. Имя автора, как правило, пишется в самом начале.
Например,
johndoe/feature/add-user-profileЗдесь имя ветки начинается с имени автора, за которым следует слеш, отделяющий его от типа ветки. Далее идет назначение ветки – добавить функцию создания профиля пользователя.
Длина имени
Старайтесь делать так, чтобы имена ветвей были описательными, но при этом максимально короткими и простыми, особенно если над проектом работают несколько человек. Разработчики должны иметь возможность, глядя на название ветки, быстро определить, для чего нужна она ветка.
Например, для того, чтобы улучшить вот это имя:
feature/user-authentication-system-with-two-factor-authenticationМы можем его укоротить до вот такого варианта:
feature/2fa-authЕсли имена веток будут слишком длинные, трудно будет отличить их друг от друга, особенно по мере увеличения сложности проекта и, соответственно, количества ветвей. Работать с короткими и простыми именами гораздо проще.
Одновременное использование нескольких соглашений о присвоении имен
Можно использовать сразу несколько соглашений о присвоении имен веткам Git. Но все-таки не стоит применять все эти правила к каждой ветке. Вместо этого постарайтесь скомбинировать их в привычной для себя манере и доступной форме, чтобы сохранить их читаемость.
Например, рассмотрим следующее имя ветки:
feature/user-registration-system/bugfix/T-133-issue123В этом имени используется несколько соглашений. Оно говорит нам о том, что это feature-ветка, где разрабатывается функция регистрации пользователей. При этом внутри нее есть еще одна ветка – bugfix-ветка с тикетом Jira под номером 133 для исправления ошибки 123.
Несмотря на то, что название описательное, оно довольно длинное и с ним будет сложно работать. Впрочем, мы можем его укоротить до вот такого варианта:
feature/T-133-bugfixТакой укороченный вариант имени по-прежнему дает нам необходимый контекст, но с ним будет гораздо проще работать, так как в нем используется меньше соглашений. По сути, ваша команда сама должна решить, сколько информации включать в имена и каких соглашений придерживаться. Таким образом, вы сможете гарантировать, что репозиторий будет оставаться структурированным и простым в управлении.
Заключение
Git – это отличный вариант для разработчиков, которые хотят совместно работать над одной кодовой базой. В этой статье мы перечислили соглашения, которые вы можете использовать для именования ветвей, а также методические рекомендации, следуя которым, вы сможете сохранить структуру и качество своей кодовой базы.
