Use Git for AI-assisted website deployments

Make the repository the source of truth

• Track application source, configuration templates, dependency locks and deployment scripts.
• Ignore secrets, uploaded media, caches, build output and local editor files unless the project requires them.
• Document the runtime versions and commands needed to produce a release.
• Keep server-only configuration outside Git and inject it during deployment.

Give each change a clear boundary

1. Start from a clean, current default branch.
2. Create a branch or worktree for the requested change.
3. Ask the agent to make one coherent change and include tests or verification.
4. Review the diff for unrelated edits, generated files and dependency changes.
5. Commit only after the production build succeeds.

Identify exactly what was deployed

• Deploy a commit, tag or immutable release archive rather than whichever files happen to be on a laptop.
• Record the commit identifier with the release directory or deployment log.
• Keep the previous release and its matching environment configuration available for rollback.
• Do not rewrite shared branch history to hide a failed deployment. Revert it with a new commit.

Add automation after the manual path works

A Git push should not become a production deployment until the build, test, secret and rollback steps are understood. Automate the same verified sequence rather than inventing a second release process.

1. Build the application in a clean environment.
2. Stop when tests, type checks or security checks fail.
3. Use a protected environment for production credentials.
4. Require an approval before the production deployment job when the business needs it.
5. Verify the live health endpoint and important routes after release.