Ветка

Ветка#

Ветка (branch) представляет собой изолированную линию разработки в системе контроля версий. Ее основное назначение — обеспечить возможность параллельного внесения и тестирования изменений без воздействия на стабильное состояние основного кода. Ниже приведены ключевые аспекты использования веток.

  1. Изоляция изменений. Ветки обеспечивают изоляцию процессов разработки. Все изменения, вносимые в рамках отдельной ветки, не оказывают влияния на другие ветки до момента выполнения операции слияния (merge). Это позволяет вести разработку и экспериментирование, не затрагивая стабильную версию проекта, расположенную в основной ветке.

  2. Организация параллельной разработки. Использование веток является стандартным методом для организации параллельной работы над несколькими функциональностями или исправлениями. Каждая задача может выполняться в собственной ветке, что исключает конфликты между усилиями различных разработчиков на ранних стадиях и позволяет независимо управлять жизненным циклом каждого изменения.

Правила наименования веток#

Основные ветки используют фиксированные имена: main, master, release-candidate, release, dev и другие.

Ветки для задач именуются по формату: Group/[SubGroup]/Label/Some-name-[Issue].

Group - обозначение группы веток:

  • wip (Works in progress) - для долгосрочных задач с неопределенным сроком завершения.
    Пример: wip/feat/config-manager-203636t.

  • iss (Issue) - для краткосрочных веток, связанных с конкретной задачей.
    Пример: iss/fix/db-generator-update-class-exist-field-210782t

  • junk - для экспериментальных разработок. Подлежит обязательному удалению после завершения экспериментов.
    Пример: junk/chore/update-sbt-version

  • usr/<user_name> - для персональных экспериментальных веток.
    Пример: usr/ya.ryazanov/chore/java-21-support

[SubGroup] - опциональная подгруппа.
Пример: usr/ya.ryazanov/wip/java-21-support, где wip является подгруппой.

Label - тип изменений в ветке:

  • feat - реализация нового функционала.

  • fix - исправление ошибок.

  • hotfix - оперативное исправление критических ошибок.

  • test - добавление тестов.

  • refactor - рефакторинг кода без изменения функциональности.

  • docs - обновление документации.

  • chore - прочие изменения, не подпадающие под указанные категории.

Some-name-[Issue] - краткое описание и номер задачи.

Совет

Наименование должно быть на английском языке и в нижнем регистре, что бы избежать конфликтов при работе на разных операционных системах.

Слияние веток#

Слияние веток - это процесс интеграции изменений из одной ветки в другую, позволяющий объединить параллельно развивающиеся линии разработки.

Типы слияния#

Fast-Forward слияние#

Происходит, когда целевая ветка не содержит изменений, отсутствующих в сливаемой ветке. Git просто перемещает указатель целевой ветки вперёд.

Условия:

  • Отсутствуют расхождения в истории.

  • Целевая ветка является прямым предком сливаемой.

Преимущества:

  • Сохраняется линейная история.

  • Не создаётся дополнительных коммитов.

Recursive слияние (трехстороннее)#

Применяется, когда обе ветки содержали изменения после момента расхождения. Git создаёт новый коммит слияния, объединяющий изменения.

Характеристики:

  • Создаётся коммит слияния с двумя родителями.

  • Сохраняется полная история изменений.

  • Требует разрешения конфликтов при необходимости.

Слияние с отклонением fast-forward (–no-ff)#

Принудительное создание коммита слияния даже когда возможно fast-forward слияние.

Применение:

  • Сохранение информации о факте слияния в истории.

  • Улучшение читаемости истории проекта.

  • Отслеживание функциональных веток.

Процесс слияния#

  1. Определение базового коммита - поиск общего предка веток.

  2. Анализ различий - сравнение изменений в обеих ветках.

  3. Автоматическое объединение - применение непротиворечивых изменений.

  4. Разрешение конфликтов - ручное устранение противоречий (при необходимости).

  5. Создание коммита слияния - фиксация результата объединения.

Стратегии слияния#

  • ort (По умолчанию) - оптимизированная стратегия для сложных слияний.

  • resolve - трёхстороннее слияние с разрешением конфликтов.

  • octopus - для слияния более двух веток одновременно.

Лучшие практики#

  • Регулярное слияние изменений из основной ветки в feature-ветки.

  • Использование --no-ff для сохранения информации о слиянии feature-веток.

  • Тщательное тестирование после слияния.

  • Использование Merge Request для код-ревью перед слиянием.

Команды слияния#

# Слияние с fast-forward (по умолчанию)
git merge feature-branch

# Слияние с созданием коммита слияния
git merge feature-branch --no-ff

# Прерывание слияния в случае конфликтов
git merge --abort
Содержание