73 lines
3.1 KiB
Markdown
73 lines
3.1 KiB
Markdown
---
|
|
name: project-management
|
|
description: Use when managing the Anxinyan project at /Users/wushumin/www/biyou/anxinyan, especially Git branch workflow, collaboration rules, commits, pre-submit checks, GitNexus detect-changes, release branch handling, or deciding where project-management rules belong.
|
|
---
|
|
|
|
# 安心验项目管理规范
|
|
|
|
Project root: `/Users/wushumin/www/biyou/anxinyan`.
|
|
|
|
Use the outer repository as the single source of truth for all project work. Do not create separate Git branch systems inside `server-api`, `admin-web`, `user-app`, or `work-app`.
|
|
|
|
Do not manage release artifacts in Git. Files under `releases/` and `releases_dev/`, including zip packages, APKs, and checksum files, are local delivery artifacts and must not be committed or pushed. Put production packages in `releases/` and test packages in `releases_dev/`.
|
|
|
|
## Branch Model
|
|
|
|
- `master`: stable, release-ready mainline. Do not do daily development directly here.
|
|
- `develop`: integration branch for normal multi-person development.
|
|
- `feature/<scope>-<name>`: feature or improvement branches created from `develop`.
|
|
- `release/<version-or-date>`: release stabilization branches created from `develop`.
|
|
- `hotfix/<name>`: urgent production fixes created from `master`.
|
|
|
|
After repository initialization, keep the local checkout on `develop` for daily work.
|
|
|
|
## Standard Workflows
|
|
|
|
For normal work:
|
|
|
|
1. Start from updated `develop`.
|
|
2. Create a `feature/<scope>-<name>` branch.
|
|
3. Commit focused changes with clear Conventional Commits messages.
|
|
4. Open a merge request back to `develop`.
|
|
5. Include changed surfaces, verification commands, and risk notes in the merge request.
|
|
|
|
For releases:
|
|
|
|
1. Create `release/<version-or-date>` from `develop`.
|
|
2. Keep the release branch limited to release blockers, verification fixes, and docs.
|
|
3. Merge the verified release branch to `master`.
|
|
4. Merge `master` back into `develop`.
|
|
|
|
For hotfixes:
|
|
|
|
1. Create `hotfix/<name>` from `master`.
|
|
2. Fix only the production issue.
|
|
3. Merge to `master` for release.
|
|
4. Merge `master` back into `develop`.
|
|
|
|
## Required Checks
|
|
|
|
Before committing, run:
|
|
|
|
```bash
|
|
git status -sb
|
|
git diff --check
|
|
npx gitnexus detect-changes --scope all
|
|
```
|
|
|
|
Before changing code symbols, follow the repository `AGENTS.md` GitNexus rule: run upstream impact analysis for the target symbol and report the blast radius. Before committing any change, run GitNexus detect changes.
|
|
|
|
For release packaging or deployment preparation, also follow the release checklist and packaging skill. At minimum, run the relevant backend smoke/audit scripts and frontend checks for the surfaces touched.
|
|
|
|
Production packages should stay under the ignored local `releases/` directory and use `https://api.anxinjianyan.com`. Test packages should stay under the ignored local `releases_dev/` directory and use `https://test.api.anxinjianyan.com`. Hand off both kinds of artifacts separately from Git branches.
|
|
|
|
## Documentation Source
|
|
|
|
The human-readable branch workflow is documented in:
|
|
|
|
```text
|
|
docs/development/branch-workflow.md
|
|
```
|
|
|
|
Keep this skill and that document aligned when branch rules change.
|