Skip to content

git_workflow.md

Latest commit

 

History

History
122 lines (89 loc) · 5.56 KB

git_workflow.md

File metadata and controls

122 lines (89 loc) · 5.56 KB
Raw

Git Workflow

В main напрямую не коммитим. Любая задача идёт в отдельной ветке, созданной от свежего main; в main работа попадает только после проверки.

main ← PR ← ветка {тип}/{говорящее-имя} ← коммиты ← прогнанные lint + typecheck + build

Имя ветки — {тип}/{говорящее-имя}: тип из таблицы ниже, имя описывает саму работу, а не номер тикета (трекера у проекта нет). Примеры: feat/event-feed, fix/layout-metadata, docs/git-workflow. Одна ветка — одна задача; ветка живёт, пока задача не влита, и удаляется сразу после вливания.

Формат коммитов

Тип коммита (Conventional Commits):

Тип Когда
feat новая функциональность
fix исправление бага
refactor переработка без смены поведения
test тесты
docs документация
style форматирование, Tailwind-классы
chore конфиг, зависимости, CI

Scope — часть проекта, которую затронул коммит:

Scope Когда
app роуты в app/
features сценарий в features/{name} (имя — в теме коммита)
ui общие компоненты components/ui/
lib общая инфраструктура lib/
db миграции и сид supabase/
cfg next.config.ts, tsconfig, biome.json, зависимости, env
docs документация
ci CI/CD

Появился новый крупный каталог — добавь для него строку в таблицу.

Примеры:

  • feat(app): добавлена главная страница со списком
  • fix(app): исправлены метаданные в корневом layout
  • refactor(lib): вынесена генерация slug в отдельный модуль
  • chore(cfg): eslint заменён на biome
  • docs: обновлён git workflow под текущий проект

Номер задачи в сообщение не добавляем. Сообщение коммита — единственное место, где записано «почему», поэтому пиши причину, а не пересказ диффа.

Рабочий цикл

Начало задачи

git checkout main
git pull
git checkout -b {тип}/{говорящее-имя}

Во время работы

Коммить по ходу, малыми атомарными шагами (см. ниже). Если main ушёл вперёд и нужны его изменения — подтяни их в ветку: git merge main (или git rebase main, пока ветка не запушена).

Завершение задачи

  1. Прогони проверки — они заменяют ревью, поэтому красная проверка — это незавершённая работа, а не «починю следом»:
npm run lint
npm run typecheck
npm run build

Те же три команды автоматически гоняет pre-push (см. «Git hooks»).

  1. Запушь ветку и открой PR в main:
git push -u origin {тип}/{говорящее-имя}
  1. После вливания PR удали ветку и обнови локальный main:
git checkout main
git pull
git branch -d {тип}/{говорящее-имя}
git push origin --delete {тип}/{говорящее-имя}

Git hooks

Хуки — husky, ставятся сами через prepare при npm install. Файлы лежат в .husky/.

Хук Что делает
pre-commit biome check --staged — линт и формат только застейдженных файлов
pre-push npm run lint, npm run typecheck, npm run build

Хук не обходим: --no-verify не используем. Упал хук — чини причину.

Атомарность коммитов

Один коммит — одно логическое изменение. Примеры правильного дробления:

refactor(lib): вынесена генерация slug в отдельный модуль
feat(lib): добавлен парсер даты активности
feat(app): добавлен компонент карточки активности
feat(app): добавлена страница списка

Не смешивай рефакторинг и фичу в одном коммите.