Ветки в Git: рабочий пример для командной разработки

В интернет-магазине добавляют оплату картой, а в продакшене уже исправляют ошибку в корзине. Если все коммитят прямо в main, новая форма оплаты может попасть к пользователям раньше тестов, а срочный фикс — случайно затереть незавершённую работу. В этой статье разберём рабочий сценарий для Git 2.40 и новее: создадим ветку функции, отдельно выпустим исправление, сольём изменения и сравним три подхода к организации веток.

Сценарий: магазин и две параллельные задачи

Представим репозиторий интернет-магазина. Ветка main соответствует коду, который можно выкатывать в продакшен. Команда получила две задачи:

• feature/payment-form — добавить страницу ввода данных карты;
• fix/cart-total — исправить неправильный пересчёт итоговой суммы в корзине.

Работать нужно в отдельных ветках. Так изменения оплаты не попадут в стабильную версию, пока функция не готова, а исправление корзины можно выпустить независимо.

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

Ветка нужна не для хранения копии проекта, а для управления риском: незавершённая работа не должна менять код, который уже обслуживает пользователей.

Три подхода и их цена

Перед командами обычно стоит не вопрос «нужны ли ветки», а вопрос «как долго живёт ветка и кто решает, когда её сливать». Для нашего сценария подходят три распространённых варианта.

Для небольшого магазина с pull request разумно начать с веток функций. Если команда выпускает изменения несколько раз в день и умеет быстро проверять код, можно сокращать срок жизни веток и двигаться к trunk-based. Git Flow не стоит добавлять только потому, что в репозитории появились две задачи: дополнительные ветки не заменяют процесс тестирования.

Живой проход: функция оплаты

1. Проверить исходную точку

Сначала разработчик получает свежую версию основной ветки. Команды рассчитаны на Git 2.40+, где для переключения используется git switch.

git switch main
git pull --ff-only origin main
git status

Флаг --ff-only запрещает Git молча создать merge-коммит во время обновления. После третьей команды рабочее дерево должно быть чистым: Git покажет сообщение nothing to commit, working tree clean.

2. Создать ветку задачи

git switch -c feature/payment-form
git branch --show-current

Команда switch -c создаёт ветку и сразу переводит вас в неё. Проверка — вторая команда выводит feature/payment-form. В этот момент main остаётся на прежнем коммите.

Название должно описывать задачу, а не имя разработчика: feature/payment-form лучше, чем ivan-new. Название не заменяет номер задачи в трекере, но помогает понять назначение ветки без просмотра истории.

3. Делать небольшие коммиты

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

git status
git add path/to/payment-form
git commit -m Add payment form

git add path/to/payment-validation
git commit -m Validate payment data

В реальном проекте замените пути на файлы репозитория. Проверка после каждого коммита — команда git status не показывает незаписанных изменений, а git log --oneline -2 выводит последние два сообщения. Коммит не должен содержать пароль, токен или ключ API: секреты нужно хранить вне репозитория и заранее проверять автоматическим сканером.

4. Опубликовать ветку и открыть проверку

git push -u origin feature/payment-form

Ключ -u связывает локальную ветку с удалённой. После отправки в GitHub, GitLab или другой хостинг появляется возможность открыть pull request в main. Названия кнопок зависят от платформы, но смысл один: коллеги проверяют изменения до слияния.

В pull request стоит указать, что изменилось, как проверить форму и какие сценарии ещё не покрыты. Проверка должна смотреть не только на стиль кода. В нашем примере важнее выяснить, не утекают ли данные карты в журнал приложения и не меняется ли итог заказа при ошибке платежа.

Параллельный срочный фикс

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

git switch main
git pull --ff-only origin main
git switch -c fix/cart-total

git add path/to/cart-total
git commit -m Fix cart total calculation
git push -u origin fix/cart-total

После тестов ветку исправления сливают в main через pull request. Только затем разработчик оплаты обновляет свою ветку: в ней должен быть свежий код корзины, иначе проверка функции будет идти на устаревшей основе.

git switch feature/payment-form
git fetch origin
git merge origin/main

Если Git напишет Already up to date, новых коммитов для добавления нет. Если появится конфликт, Git остановит слияние до ручного решения. После разрешения конфликтных файлов выполните git add для каждого исправленного файла и завершите слияние командой git commit. Сначала запустите тесты, затем отправьте обновлённую ветку через git push.

Что ломается чаще всего

Изменения сделали не в той ветке

Проверка — git branch --show-current перед первым изменением. Если коммит уже создан не там, не переписывайте историю общей ветки без согласования. Сначала покажите коммит команде и выберите безопасный способ переноса, например отдельный pull request или перенос изменений средствами Git после резервной проверки.

Ветка устарела

Ошибка проявляется не обязательно сразу. Pull request может выглядеть зелёным, а после слияния сломать код, который недавно изменили в main. Перед финальной проверкой обновите ветку из удалённого main и снова запустите тесты. Частота такого обновления зависит от скорости команды, но для короткой задачи это стоит делать перед отправкой на ревью.

Конфликт решили «оставить как есть»

Маркеры <<<<<<<, ======= и >>>>>>> означают, что Git не выбрал вариант сам. Их нельзя оставлять в рабочем файле. Выберите корректную логику, удалите маркеры, запустите тесты и только потом выполните git add.

Ветка живёт месяцами

Долгая ветка накапливает расхождения с main. Цена — больше конфликтов, сложнее ревью и выше вероятность, что функция уже не соответствует текущим требованиям. Если задача крупная, делите её на вертикальные части и скрывайте незавершённое поведение feature flag, а не складывайте все изменения в одну гигантскую ветку.

Когда какой подход выбирать

Для нашего магазина ветки функций подходят, пока pull request проходит проверку за часы или несколько дней, а main остаётся потенциально готовой к выпуску. Trunk-based стоит выбирать, если у команды есть быстрые тесты, автоматическая сборка и правило вливать маленькие изменения. Git Flow оправдан только при действительно редких и формализованных релизах, когда отдельно поддерживаются версии и исправления.

Главный критерий — не количество веток, а время от первого коммита до безопасной проверки в общей ветке. Чем оно больше, тем дороже каждое расхождение.

Что делать дальше

Зафиксируйте в README короткое правило репозитория: от какой ветки создаются задачи, кто одобряет pull request, какие проверки обязательны и когда ветку можно удалить. Затем настройте автоматический запуск тестов для каждого pull request и запрет прямых коммитов в main. Через неделю посмотрите на три показателя: среднее время жизни ветки, число конфликтов и долю pull request, которые возвращаются на доработку. По ним видно, нужна ли вам более короткая ветка, лучшее тестовое покрытие или другой процесс слияния.