Стратегии ветвления для командной работы

Мы уже освоили базу: научились сохранять состояния кода с помощью коммитов и перемещаться по истории изменений. Однако в крупных проектах над кодом одновременно работают десятки инженеров. Если бы все вносили правки в одну линию, проект превратился бы в хаос. Для решения этой задачи существует ветвление в Git.

Ветка — это не копия проекта, а подвижный указатель на конкретный коммит. Создавая новую ветку, вы получаете изолированное пространство. В нем можно экспериментировать, внедрять функции или исправлять баги, не рискуя стабильностью основного кода.

На Схеме 1 показано, как ветка развивается параллельно основной линии.

Управление ветками: создание и переключение

Раньше для работы с ветками использовали команду git checkout. В современных версиях Git её заменили на две специализированные команды: git switch для переключения и git restore для восстановления файлов. Рекомендуем использовать актуальный синтаксис.

Основные команды:

  • git branch — показать список локальных веток. Текущая ветка отмечена звёздочкой.
  • git switch -c <название_ветки> — создать новую ветку и сразу перейти в неё (флаг -ccreate).
  • git switch <название_ветки> — перейти в существующую ветку.

Стратегии ветвления

Чтобы работа в команде была системной, используют стратегии — правила создания и именования веток.

Feature Branch Workflow

Самый популярный подход в продуктовой разработке. Для каждой задачи создается отдельная ветка. После завершения работы и проверки её вливают в основную ветку (обычно main).

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

  • В main всегда находится рабочий код.
  • Инженеры не мешают друг другу.
  • Удобно проводить ревью кода перед слиянием.

Git Flow

Строгая стратегия с «вечными» ветками: master (только для релизов) и develop (для интеграции фич). Также используются временные ветки для подготовки релизов и срочных исправлений (hotfixes). Этот подход часто встречается в энтерпрайз-проектах с жестким циклом выпуска обновлений, но для небольших команд он может быть избыточным.

Слияние изменений и разрешение конфликтов

Когда работа в ветке закончена, её нужно объединить с основной. Для этого используется команда git merge.

Сначала перейдите в ветку, в которую вы хотите влить изменения (например, main), а затем выполните: git merge <название_фиче_ветки>

Fast-forward vs Three-way merge

Если в основной ветке не появилось новых коммитов, Git просто передвинет указатель вперед (Fast-forward). Если же основная ветка ушла вперед, Git создаст специальный «коммит слияния» (merge commit).

Конфликт слияния

Конфликт возникает, если в двух ветках изменили одни и те же строки в одном файле. Git не может решить, какой вариант оставить, и просит вас сделать выбор вручную.

Пример конфликта в файле config.py:

<<<<<<< HEAD
# Изменения в текущей ветке (main)
PORT = 8080
=======
# Изменения в ветке, которую мы вливаем
PORT = 9000
>>>>>>> feature-new-port

Чтобы разрешить конфликт:

  1. Откройте файл и выберите нужный код, удалив маркеры <<<<, ====, >>>>.
  2. Сохраните файл.
  3. Добавьте файл в индекс: git add <имя_файла>.
  4. Завершите слияние: git commit.

Практика:

  1. Создайте ветку test-branch из main.
  2. В ветке test-branch создайте файл readme.txt с текстом «Версия 1» и закоммитьте.
  3. Вернитесь в main и создайте тот же файл readme.txt, но с текстом «Версия 2». Закоммитьте.
  4. Выполните git merge test-branch и вручную разрешите возникший конфликт.

Умение управлять ветками — обязательный навык для DevOps-инженера. Теперь, когда вы освоили локальную работу, мы перейдем к GitLab. Там ветки станут основой для командного взаимодействия и автоматизации через запросы на слияние (Merge Requests).

Понравился урок?

Сохраните прогресс и получите персональный курс по любой теме — без форм и паролей

Продолжить в Telegram