102 lines
4.5 KiB
Markdown
102 lines
4.5 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/`.
|
|
|
|
Local development and the test server share the test database connection. Store the real host, username, and password only in ignored `.env` files or server environment variables. The shared test database name is `test_anxinyan`; never commit real database passwords to docs, skills, examples, or Git-tracked templates.
|
|
|
|
## 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 --repo anxinyan
|
|
```
|
|
|
|
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.
|
|
|
|
Use GitNexus with the branch workflow:
|
|
|
|
- Before changing unfamiliar code, use GitNexus query/context to locate the relevant flow.
|
|
- Before editing any function, class, or method, run upstream impact analysis for that symbol.
|
|
- Before committing, run detect-changes against the current diff; this remains a required check even when hooks are enabled.
|
|
- After commits, merges, branch checkouts, and rewrites, local hooks refresh the index with `npx gitnexus analyze --index-only --name anxinyan .`.
|
|
|
|
Enable the versioned lightweight hooks once per clone:
|
|
|
|
```bash
|
|
git config core.hooksPath scripts/git-hooks
|
|
```
|
|
|
|
The hook refresh is best-effort and non-blocking. Disable it temporarily with `GITNEXUS_AUTO_REFRESH=0` if needed. Manual refresh is available with:
|
|
|
|
```bash
|
|
./scripts/gitnexus-refresh.sh
|
|
```
|
|
|
|
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.
|
|
|
|
For backend local/test validation, confirm `server-api/.env` is ignored before using real database credentials:
|
|
|
|
```bash
|
|
git check-ignore -v server-api/.env
|
|
```
|
|
|
|
Before committing environment-related documentation, scan tracked docs and examples to ensure no real `DB_PASSWORD` value is present.
|
|
|
|
## 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.
|