# Git в workspace

- Выполняй Git-команды из репозитория владельца: root, frontend, backend,
  docs и specs имеют независимые history, index и branches.
- Новая работа: ветка `codex/<task>` от актуального `develop`, затем PR в `develop`.
  Сохраняй чужие staged/unstaged/untracked изменения; не переноси их в свой commit.
- Commit содержит одну связанную задачу и её необходимые проверки/документацию.
  Межрепозиторное изменение оформляй отдельными commits/PR с взаимными ссылками.
- Commits и заголовки PR — Conventional Commits; допустим `spec:`.
  Во frontend номер связанной issue добавляй в конец заголовка (`fix: … #12`);
  без связанной issue номер не нужен. Формат проверяет local commitlint.
- Перед commit проверь `git diff --cached --name-status` и сам staged diff
  в каждом affected repo. Root tracking ограничен [.gitignore](../../.gitignore):
  новый общий файл получает точечный allowlist и проверку
  [tracking](../../test-workspace-tracking.py). `git add -f` не используется.
- Не выполняй `git clean -fdx`, reset чужих изменений, force-push, удаление или
  перенос опубликованных тегов как обычную очистку. Для опасной операции нужны
  явная необходимость, сохранение данных и соответствующая авторизация.
- Обычный PR допускает squash. Release/hotfix, синхронизация main/develop,
  release-конфигурация и CI refs требуют чтения
  [процесса релиза](../../README.md#релизы-и-ветки): он владеет merge policy,
  версиями и тегами. Прямой push в `main` запрещён; версии вручную не повышай.