docs: establish workspace engineering conventions
Workspace security / security (push) Successful in 7s
Workspace verify / verify (push) Successful in 20s
Workspace security / security (pull_request) Successful in 6s
Workspace verify / verify (pull_request) Successful in 20s
Conventional commits / commits (pull_request) Successful in 10s

This commit is contained in:
2026-09-15 05:42:02 +03:00
parent 2567a75556
commit 93dd5539ad
11 changed files with 504 additions and 25 deletions
+22
View File
@@ -0,0 +1,22 @@
# 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` запрещён; версии вручную не повышай.