Writing good code is half the job. The other half is getting it into version control safely and out to a real server without breaking anything for real users. This is where the discipline from the last two posts — clear prompts, real review — matters most, because the stakes go up.
Git, with Claude doing the typing
Claude can run git commands directly: checking status, viewing diffs, staging files, and writing commit messages. A typical exchange:
Review what's changed and commit it with a message explaining
why, not just what changed.Good commit messages explain intent — “fix race condition in double-submit on checkout” beats “update checkout.js” — and Claude is genuinely good at this once it has read the actual diff and understands the reasoning, not just the file names.
The non-negotiable safety rules
Some git operations are destructive or hard to undo. A well-behaved agent workflow treats these as requiring your explicit confirmation every time, never as routine:
- Force-pushing — can overwrite history other people depend on.
git reset --hard— discards uncommitted work permanently.- Skipping hooks (
--no-verify) — hooks usually exist for a reason; skip them deliberately, not by default. - Amending published commits — rewrites history others may have already pulled.
None of these are forbidden outright — sometimes you genuinely need a force-push. The rule is that they should never happen silently as a side effect of an unrelated instruction.
Pull requests
Claude can open a PR directly: pushing a branch, writing a description that actually explains the change and includes a test plan, and handing you the link. The same review discipline from the previous post applies — read the PR description, read the diff, and don’t merge on trust alone just because an agent wrote it instead of a person.
Working across environments safely
Most real projects have at least a development and a production environment, sometimes staging in between. The habits that keep this safe:
- Be explicit about which environment an instruction applies to — “restart the dev server” and “restart the production server” should never be ambiguous.
- Treat any database or server change on production as requiring an explicit go-ahead, the same way you’d want a junior engineer to check with you first.
- Back up before destructive changes. A database migration, a bulk content change, a theme swap — take a backup first, every time, as routine as it sounds.
This isn’t about distrust of the agent specifically — it’s the same discipline you’d want from anyone, human or otherwise, operating on systems real users depend on.
A real shape this takes
A realistic production task looks like: inspect the current server setup, take a database and file backup, make the change, verify it works (checking the actual site, not just assuming success), and only then consider it done. Skipping the verification step — actually loading the page, actually checking the log — is the single most common way agent-assisted deployments go wrong. Claude reporting success and a feature actually working are two different claims; only one of them is confirmed by looking.
Last post in the series: pulling everything together into a complete roadmap, from a blank idea to a production-ready application.