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
23 lines
2.2 KiB
Markdown
23 lines
2.2 KiB
Markdown
# 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` запрещён; версии вручную не повышай.
|