Git Deploy Release

Git Deploy Release

Operating Rules

• Treat main as the default working and production branch unless the user explicitly asks for a feature branch or the change is risky enough to justify proposing one.
• Never use assistant-branded branch names or commit messages. Do not include strings such as codex, claude, or other AI assistant names in git metadata.
• Keep commit messages concise, human, and descriptive of the product change.
• Before committing, inspect git status --short --branch and avoid staging unrelated user changes.
• If deleting files or branches, only do so when the user requested it or when the cleanup is clearly part of the task.

Release Prep

• Check for an existing semantic version before deployment or release prep. Inspect common locations such as package.json, package-lock.json, pyproject.toml, Cargo.toml, VERSION, app config files, and docs that already carry a version.
• If a semver exists, increment it deliberately during deploy prep. Prefer patch increments for small fixes, minor increments for visible feature/content additions, and major increments only for breaking changes or explicit user instruction.
• Do not introduce placeholder versions into projects that do not already carry semver unless the user asks.
• Regenerate lockfiles or generated metadata when the version source requires it.

Testing Gate

• Test locally before deploying. Use the repo's existing commands first, then add targeted checks that match the change.
• First determine whether the repository actually has CI/CD; do not invent a remote pipeline gate where none is configured. When a repository has no CI/CD, run the relevant available local checks and report that no CI/CD verification exists.
• When CI/CD is configured, inspect the remote run for the exact pushed commit and wait for a terminal result. Do not call the work finished, ready, or deployed while required CI is pending, running, failed, or unverified.
• If configured CI fails, read the exact failing step and log before changing code. Distinguish a product regression from CI-environment or inherited test-harness failure, fix only the demonstrated cause, rerun relevant local checks, push, and verify the replacement run is green.
• For webapp deploys, keep a checklist, audit the changed path, run deterministic tests, use browser or DOM checks when the UI changed, and capture live verification after deploy.
• Do not describe a deployment as complete until the changed route or behavior has been tested against the live target.
• If a check cannot run, report exactly why and what residual risk remains.

Commit And Push

• Stage only intended files. Use pathspec exclusions when unrelated local files exist.
• Run git diff --cached --check before committing.
• Commit after the relevant test batch passes, not before.
• Push to origin main by default when the user asked to deploy or converge work onto production.
• If a temporary feature branch was used and the user asks to converge, fast-forward or merge into main, push main, and delete the temporary local and remote branch after confirming main contains the work.

Deployment Flow

1. Confirm the working branch and repo state.
2. Apply the requested change without reverting unrelated work.
3. Increment existing semver if the task includes deployment or release.
4. Run local tests and build checks.
5. Commit and push intended files.
6. If the repository has required remote CI, verify it is green for the pushed commit; otherwise record that the repository has no CI/CD gate.
7. Deploy with the repo's documented command or deployment script.
8. Verify live health, changed pages, and any sitemap or SEO routes affected by the change.
9. Report the exact tests, CI result, deploy command, live URLs checked, commit hash, branch state, and any unproven items.