Перейти к основному содержанию
`Ctrl`+`K`

# Ветка

Ветка (`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