Files

27 lines
2.6 KiB
Markdown

# Git в workspace
- Выполняй Git-команды из репозитория владельца: root, frontend, backend,
docs и specs имеют независимые history, index и branches.
- Новая работа: ветка с номером Issue по [Engineering Workflow](engineering-workflow.md#git-branching)
от актуального `develop`, затем PR в `develop`.
Сохраняй чужие staged/unstaged/untracked изменения; не переноси их в свой commit.
- Commit содержит одну связанную задачу и её необходимые проверки/документацию.
Межрепозиторное изменение оформляй отдельными commits/PR с взаимными ссылками.
- Commits и заголовки PR — Conventional Commits со ссылкой на Issue;
допустим `spec:`. Исключения release — в README.
Формат проверяет local commitlint; правила других repo принадлежат их AGENTS.
- Перед commit проверь `git diff --cached --name-status` и сам staged diff
в каждом affected repo. Root tracking ограничен [.gitignore](../../.gitignore):
новый общий файл получает точечный allowlist; проверь staged paths вручную. `git add -f` не используется.
- Не выполняй `git clean -fdx`, reset чужих изменений, force-push, удаление или
перенос опубликованных тегов как обычную очистку. Для опасной операции нужны
явная необходимость, сохранение данных и соответствующая авторизация.
- Обычный PR сливается squash или rebase-merge; merge-коммит не используется.
`main` обновляется только fast-forward из `develop`, поэтому
`origin/main` всегда предок `origin/develop`. Проверка:
`git merge-base --is-ancestor origin/main origin/develop`.
- Release, hotfix и release-конфигурация требуют чтения
[процесса релиза](../../README.md#релизы-и-ветки): он владеет merge policy,
версиями и тегами. Прямой push в `main` запрещён; версии вручную не повышай.
Отдельной синхронизации `main → develop` в обычном процессе нет.