Работа в команде с Git-ветками: практическое пособие и лучшие практики

Эта статья — практичная инструкция по совместной работе в одном репозитории, когда над проектом работают 2+ человека: фронтенд, бэкенд, тестирование, DevOps. Цель — предсказуемый процесс, меньше конфликтов, быстрые хотфиксы и стабильные релизы.

1) Базовые принципы командной работы

Один репозиторий — один источник правды

  • История изменений должна быть читаемой.
  • Любое изменение попадает в основные ветки только через Merge Request / Pull Request.
  • Автоматические проверки (линтеры, тесты, сборка) — обязательны.

Никаких «прямых пушей» в основные ветки

Обычно защищают (protected branches):

  • master (или main)
  • test
  • dev

2) Рекомендуемая схема веток

Ниже — универсальная схема, которая хорошо работает для большинства команд.

Ветка master (или main)

Назначение: стабильный код для релиза.

  • В неё попадает только то, что полностью готово: протестировано, отревьюено, прошло CI.
  • Из неё делают релизные теги.
  • Прямые коммиты запрещены.
  • Хотфиксы делаются от неё отдельной веткой и возвращаются обратно через MR.

Ветка test

Назначение: «почти релиз», кандидат на выкатку.

  • Сюда попадает только то, что уже прошло проверку на стенде/стейдже и ревью.
  • После регресса ветка может быть слита в master.
  • Это удобное место, где QA проверяет «сборку релиза».

Ветка dev

Назначение: ранняя интеграция и проверка в окружении.

  • Сюда попадают изменения для совместной проверки на стендах.
  • Это не мусорная ветка, а «интеграционная»: код должен собираться и запускаться.
  • Обычно на dev разворачивается staging/тестовый контур для команды.

Ветки задач (feature/fix)

Назначение: разработка конкретной фичи/фикса.

  • Ветвимся от test, чтобы начинать работу от максимально стабильной базы и уменьшать сюрпризы ближе к релизу.
  • Примеры названий:
  • feature/<task-id>-short-title
  • fix/<task-id>-short-title
  • hotfix/<task-id>-short-title
  • chore/<task-id>-short-title (техдолг/инфра/рефакторинг)

3) Основной рабочий поток (фича/фикс)

Ключевая идея: сначала интегрируем и проверяем через dev, а затем продвигаем в test.
Так test остаётся веткой кандидата в релиз, а dev — местом ранней интеграции.

Шаг 0. Обновить базовую ветку test

Перед началом работы важно забрать актуальное состояние:

git checkout test
git pull --ff-only

Шаг 1. Создать ветку задачи от test

git checkout -b feature/PROJ-123-short-title

Шаг 2. Разработка и небольшие коммиты

  • Коммиты должны отражать логические шаги.
  • Лучше несколько понятных коммитов, чем один огромный.
git status
git add -A
git commit -m "feat(module): implement X"

Шаг 3. Запушить ветку

git push -u origin feature/PROJ-123-short-title

Шаг 4. Ранний MR в dev (рекомендуется)

Создайте MR в dev как можно раньше:

  • можно начать как Draft/WIP,
  • цель: видимость для команды, ранний CI, раннее ревью, ранняя интеграция.

Когда MR готов:

  • CI зелёный,
  • ревью получено по правилам команды,
  • вмержить ветку задачи → dev.

Шаг 5. Деплой dev на staging и быстрая самопроверка

После мержа в dev:

  • задеплоить dev на тестовое окружение (staging),
  • сделать smoke-тест (основной happy path + критичные места).

Шаг 6. Передать задачу в QA

  • уведомить тестировщика,
  • QA проверяет на staging.

Если QA находит баг:

  • фиксы делаются в той же ветке задачи,
  • push → MR обновляется → снова merge в dev → redeploy → повторная проверка.

Шаг 7. Продвижение в test (кандидат в релиз)

После успешной проверки:

  • создать MR из ветки задачи → test,
  • CI + ревью,
  • затем merge в test.

test должен оставаться «чистым»: туда попадает уже проверенное.

4) Обязательная синхронизация веток: test → dev

Одна из самых частых причин хаоса — когда test и dev расходятся.
После любого мержа в test нужно синхронизировать dev, чтобы интеграционная ветка содержала всё, что уже стало кандидатом в релиз.

Рекомендуемый способ: MR test → dev (прозрачно и с CI).
Если политика допускает — можно merge напрямую.

Пример (если делаете merge вручную и это разрешено процессом):

git checkout dev
git pull --ff-only
git merge --no-ff test
git push

После синка:

  • при необходимости обновить staging (deploy dev),
  • уведомить команду: test синхронизирован в dev.

5) Хотфикс: быстрый и безопасный сценарий

Хотфикс — изменение, которое нужно срочно выпустить в релиз.

Правило

Хотфикс начинается от master и возвращается в master.

Поток хотфикса

  1. Создать ветку от master:
git checkout master
git pull --ff-only
git checkout -b hotfix/PROJ-777-short-title
  1. Сделать фикс, коммиты, push:
git add -A
git commit -m "fix(area): patch Y"
git push -u origin hotfix/PROJ-777-short-title
  1. MR в master + ревью + CI → merge.
  2. Обязательная протяжка хотфикса вниз по веткам:
  • master → test
  • test → dev
  • deploy dev на staging и проверка.

Иначе команда продолжит работать на базе без хотфикса и позже получит конфликты/регрессии.

6) Merge или Rebase: что и когда

Merge (вмержить)

Используется для интеграции веток в командной разработке.

  • Безопасно и прозрачно.
  • Сохраняет реальную историю: что и когда было объединено.
  • Хорошо работает с MR/PR.

Типовые случаи:

  • feature/* → dev (через MR)
  • feature/* → test (через MR)
  • test → dev (через MR)
  • hotfix/* → master (через MR)

Rebase (ребейз)

Используется для актуализации личной ветки задачи относительно базы (обычно test).

  • Уменьшает конфликты ближе к финальному MR.
  • Делает историю линейнее.

Пример: актуализировать ветку относительно test:

git checkout feature/PROJ-123-short-title
git fetch origin
git rebase origin/test

Если ребейз уже запушенной ветки неизбежен:

  • это переписывает историю,
  • пушить нужно только с --force-with-lease.
git push --force-with-lease

Важно: никогда не ребейзить общие ветки (dev, test, master).

7) Коммуникации: что обязательно проговаривать

Всегда сообщайте о «точках синхронизации»

Команда должна знать, когда нужно подтянуть изменения. Минимальные ситуации:

  • вмержили в dev и задеплоили на staging,
  • вмержили в test,
  • протащили хотфикс вниз: master → test → dev.

Сообщение должно быть коротким и полезным

  • куда влито (dev/test/master),
  • задеплоено ли на staging,
  • что проверить (1–2 предложения).

8) Практические команды Git (короткая шпаргалка)

Посмотреть, что изменилось

git status
git diff

Обновить текущую ветку без лишних мерджей

git pull --ff-only

Забрать изменения (fetch)

git fetch origin

Создать ветку

git checkout -b fix/PROJ-555-short-title

Решение конфликтов

  1. Git покажет конфликтующие файлы.
  2. Исправить руками.
  3. Отметить исправленное:
git add <file>
  1. Продолжить:
  • при rebase:
git rebase --continue

9) Рекомендуемая политика веток (кратко)

  • master: только через MR, только стабильное, хотфиксы от master.
  • test: только через MR, кандидат в релиз.
  • dev: только через MR, ранняя интеграция + staging.
  • feature/*, fix/*: от test, MR в dev для проверки, затем MR в test для попадания в релиз-кандидат.
  • После любого хотфикса: master → test → dev + deploy + уведомление.
  • Личные ветки актуализируем rebase-ом на test (или merge — по политике команды).

10) Итог

Стабильная командная работа в Git строится на трёх вещах:

  1. Понятная схема веток (master/test/dev + ветки задач).
  2. MR + ревью + CI как обязательные ворота.
  3. Дисциплина синхронизации: проверяем через dev (staging), продвигаем в test, хотфиксы протягиваем вниз.

Этот подход одинаково хорошо подходит для фронтенда, бэкенда и QA-команд: он снижает конфликты, ускоряет проверку и делает релизы предсказуемыми.