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

Ветка в Git решает одну задачу: отделяет незавершённую работу от кода, который уже можно собирать и выпускать. Но неправильная стратегия быстро превращает репозиторий в набор долгоживущих веток, конфликтов и непонятных слияний. Ниже — практики для Git 2.43+: как создавать ветки, синхронизировать их с main, выбирать merge или rebase и не терять историю.

Сначала выберите модель ветвления

У ветвления нет универсальной схемы. Выбор зависит от частоты релизов, размера команды и того, можно ли быстро откатить изменение. Для большинства веб-проектов с автоматическими тестами лучше всего работают короткоживущие feature-ветки: одна задача — одна ветка — один pull request.

Сноска. Feature flag — переключатель, который позволяет включать новую функциональность отдельно от факта её публикации в коде. Он снижает потребность держать незавершённую работу в отдельной долгоживущей ветке, но добавляет временный код и настройки.

Лучшая ветка — не самая аккуратно названная, а та, которая быстро исчезает после проверки изменения.

Создавайте ветку от актуального main

Главная причина будущих конфликтов — ветка начинается не от той версии кода, которая уже лежит на сервере. Перед новой задачей обновите локальную копию и только потом создавайте ветку.

git switch main
git pull --ff-only origin main
git switch -c feature/payment-timeout

Команда git pull --ff-only не создаёт незапланированный merge-коммит. Если локальный main уже разошёлся с удалённым, Git остановится, и вы сначала решите проблему явно. Команда git switch -c создаёт ветку и сразу переводит рабочую копию на неё.

Проверка: команда git branch --show-current должна вывести feature/payment-timeout, а git status — показать чистое рабочее дерево.

Держите ветку маленькой и понятной

Название должно отвечать на вопрос, что находится внутри. Подойдут форматы feature/payment-timeout, fix/cart-total, chore/upgrade-node. Не используйте имена вроде test, new или ivan-work: через неделю они не объяснят назначение ветки.

Одна ветка должна решать одну связанную задачу. Если в процессе исправления тайм-аута вы одновременно форматируете весь проект и обновляете зависимости, ревью становится дороже, а откат — опаснее.

• коммитьте логически законченные изменения;
• не смешивайте функциональность и массовое форматирование;
• пишите сообщение коммита с действием: Handle payment timeout;
• перед публикацией проверьте, что в коммит не попали локальные файлы, дампы и секреты;
• если задача выросла, разделите её на несколько веток или pull request.

Синхронизируйте ветку без лишних merge-коммитов

Пока вы работаете, в main могут попасть изменения коллег. Есть два основных способа обновить свою ветку: merge и rebase. Оба сохраняют результат, но по-разному меняют историю.

Rebase для личной рабочей ветки

Rebase переносит ваши коммиты поверх свежего состояния main. История получается линейной, но идентификаторы ваших коммитов меняются. Поэтому не переписывайте ветку, в которую уже активно коммитят другие люди.

git fetch origin
git switch feature/payment-timeout
git rebase origin/main

Если возник конфликт, Git остановится. После исправления файла добавьте его в индекс и продолжите операцию:

git add path/to/resolved-file
git rebase --continue

Если конфликт оказался слишком сложным, вернитесь в состояние до начала rebase:

git rebase --abort

После успешного rebase уже опубликованную ветку обычно нужно отправлять с защитным флагом:

git push --force-with-lease origin feature/payment-timeout

--force-with-lease безопаснее обычного --force: Git откажется перезаписывать удалённую ветку, если она изменилась после последнего получения данных. Но это не отменяет проверки: перед отправкой убедитесь, что ветка ваша и коллега не публиковал туда коммиты.

Merge для общей или уже опубликованной ветки

Если веткой пользуются несколько человек, не переписывайте её историю без согласования. В таком случае обновление выглядит так:

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

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

Сливайте через pull request, а не вручную

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

Перед открытием запроса полезно проверить локально:

git status
git log --oneline --decorate -5
git diff origin/main...HEAD

Команда git diff origin/main...HEAD показывает изменения ветки относительно общего предка с удалённым main. Это удобнее, чем смотреть весь локальный diff, в котором могут быть старые несвязанные изменения.

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

Cherry-pick — точечный перенос, а не способ синхронизации

git cherry-pick переносит выбранный коммит в текущую ветку. Приём полезен, когда исправление уже проверено в feature-ветке и его нужно отдельно доставить в release или hotfix. Он создаёт новый коммит с другим идентификатором, поэтому один и тот же логический фикс может появиться в истории дважды.

git switch release/2.8
git pull --ff-only origin release/2.8
git cherry-pick 4f2a9c1

Не используйте cherry-pick для регулярного переноса десятков коммитов между ветками. Так легко получить разные версии одного исправления и забыть перенести следующий связанный коммит. Для большой серии изменений лучше синхронизировать ветку через merge или rebase.

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

Ветка устарела перед слиянием

Симптом: после открытия pull request CI сообщает о конфликте или тесты проходят локально, но падают на актуальном main. Обновите ветку через rebase или merge, запустите тесты заново и только после этого просите повторное ревью.

Rebase запущен не в той ветке

Симптом: после команды git rebase изменилась история main или общей ветки. Не продолжайте работу вслепую. Выполните git rebase --abort, проверьте вывод git branch --show-current и только потом повторите операцию в нужной ветке.

Обычный force push уничтожил чужие коммиты

Симптом: удалённая ветка внезапно стала короче, а коммиты коллеги исчезли из её истории. Восстановление возможно через reflog или сохранённые ссылки, но порядок зависит от хостинга и состояния локальных клонов. Для личной ветки используйте --force-with-lease, для общей ветки сначала выясните, кто ещё в неё публикует.

Конфликт решён механически

Симптом: Git сообщает об успешном слиянии, но приложение перестаёт запускаться или меняется бизнес-логика. Конфликт нужно решать не по принципу «оставить верхнюю часть», а по смыслу: сравнить контракт, тесты и поведение соседних изменений. После этого запустите минимальный набор тестов и проверьте миграции отдельно.

Когда что выбирать

Используйте короткую feature-ветку и rebase, если вы работаете один, pull request ещё не принят, а коммиты не являются частью общей истории. Выбирайте merge, если ветка уже общая или её история должна остаться неизменной. Берите cherry-pick для одного проверенного исправления, которое нужно доставить в другую линию релиза.

Если ветки живут неделями, это обычно сигнал не к более сложной Git-схеме, а к слишком крупным задачам. Разделите работу, спрячьте незавершённые части за feature flag и уменьшите размер pull request.

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

Зафиксируйте в README проекта три правила: от какой ветки создаётся новая работа, когда разрешён rebase и кто отвечает за release-ветки. Затем добавьте защиту main на сервере: обязательный pull request, успешный CI и запрет прямой отправки. Через неделю посмотрите на три показателя — средний срок жизни ветки, число конфликтов и время от открытия pull request до merge. Именно они покажут, помогает ли выбранная схема, а не количество веток в репозитории.