Репозиторий-помойка: как навести порядок в Git

Заходите в репозиторий нового проекта. В master — 47 веток с именами fix, fix2, test, temp, vasya-branch. История — лента из «.», «упд», «фикс» и «merge branch master into master». Любой релиз — это лотерея: то поломанная миграция, то конфликт, который никто не помнит, как разруливать. Знакомо?

Это не «команда плохая». Это отсутствие процесса. Git очень либерален: он позволяет делать что угодно, и команда без договорённостей рано или поздно превращает репозиторий в помойку.

Почему так получается

Чаще всего — историческое. Начинали втроём, пушили в master, потом команда выросла до 15 человек, а правила остались те же. Никто не садился и не договаривался: какие ветки бывают, как они называются, кто и как их мержит, что должно случиться до релиза.

В итоге каждый делает «как привык», и любой merge — событие со спецэффектами.

Какую стратегию ветвления выбрать

Нет «правильной» — есть подходящая под ваш процесс.

• Trunk-based. Одна основная ветка, короткие feature-бранчи (часы–день), частые мерджи в main, фичи под флагами. Подходит командам с CD и хорошими тестами. Любимый паттерн SaaS-продуктов.
• GitHub Flow. main всегда деплоится. Любая работа — отдельный бранч → PR → merge. Минимум церемоний, идеально для веб-приложений с непрерывной доставкой.
• GitFlow. main, develop, release/*, hotfix/*, feature/*. Сложно, но оправдано там, где есть версии и долгая поддержка — десктоп, мобилки, коробки заказчику.

Самая частая ошибка — взять GitFlow для типичного веб-проекта с CD и страдать от лишних веток. Если деплоите по несколько раз в день — берите trunk-based или GitHub Flow.

Защищённые ветки и code review

Минимум, который должен быть включён в любом репозитории:

• Запрет прямого push в main/master. Изменения только через MR/PR.
• Обязательный review. Минимум одно approve, для критичных проектов — два.
• Зелёный CI как условие merge. Нет зелёного — нет мерджа.
• Линейная история. Squash или rebase merge. Никаких «merge commit'ов из соседнего merge'а».
• Auto-delete веток после merge. Чтобы список бранчей не превращался в кладбище.

Это настраивается в GitHub/GitLab/Bitbucket за 15 минут на проект. Один раз — и больше никто не сломает прод прямым пушем в master.

Conventional Commits

Договорённость о формате сообщений. Выглядит так:

feat(auth): добавили вход через Telegram
fix(billing): корректный расчёт НДС для физлиц
chore(deps): обновили Laravel до 13.4

Что это даёт:

• автогенерируемый CHANGELOG;
• автоматический bump версии (semantic-release);
• человеческую историю — git log --oneline читается без слёз;
• понятный фильтр для cherry-pick'ов в hotfix.

Завести правило и подключить commit-lint'ер — пара часов. Дальше работает само.

Webhooks: CI и уведомления

Репозиторий должен разговаривать с остальной инфраструктурой. Минимальный набор хуков:

• push / merge_request → CI (тесты, lint, билд, деплой).
• pipeline_failed → Telegram/Slack дежурного.
• merge_request_opened → канал команды + автоназначение reviewer'ов через CODEOWNERS.
• tag_push → деплой в прод и пост в канал релизов.
• Опционально: интеграция с Jira/YouTrack — связка коммита и задачи по номеру в названии бранча.

Настроить webhook на Telegram-бота и сделать так, чтобы команда узнавала о красном CI за 10 секунд, а не из жалоб тестировщика — это можно сделать самому за вечер; помогу настроить webhooks, CI-интеграции и единые шаблоны MR на всех проектах, если хочется не «как-нибудь работает», а сразу нормально и одинаково на всех проектах.

Что ещё навести

• CODEOWNERS — кто за какую папку отвечает, авто-reviewer на MR.
• Шаблоны MR/PR и issue. Чтобы человек не забыл написать «зачем» и «как тестировать».
• Pre-commit hooks (Husky, pre-commit) — линтеры и форматеры локально, до пуша.
• Регулярная чистка старых веток и tag'ов: git for-each-ref --sort=-committerdate refs/heads/.
• Зеркала и бэкапы репозиториев, особенно если хостинг внешний.

Запомнить

• Помойка в репозитории — это всегда отсутствие договорённостей, а не вина людей.
• Стратегию ветвления выбирают под процесс, а не наоборот.
• Защищённые ветки + обязательное review + зелёный CI как условие merge — must-have.
• Conventional Commits и webhooks превращают репозиторий из свалки в инструмент.

Если репозиторий уже превратился в зоопарк или процесс хочется выстроить с нуля — напишите. Настрою GitHub/GitLab/Bitbucket «под ключ»: branching strategy под ваш процесс (GitFlow, trunk-based, GitHub Flow), защищённые ветки, code review, webhooks для CI и уведомлений, шаблоны и CODEOWNERS.