Three places to understand
- Local copy: where the agent or developer changes code.
- Remote repository: shared history, often hosted by a Git provider.
- Hosting environment: the server running the published application.
Why clean status matters
Before deployment, the project should have a clear status. If the server or local project contains manual changes that are not committed, it becomes difficult to know what is actually running, what is safe to deploy, and what might be overwritten.
You do not need to know Git commands
You can ask the coding agent to handle Git for you. Instead of knowing the exact commands, describe the outcome you want and ask the agent to explain what it plans to do before it changes anything.
Useful prompts:
- "Check the Git status and explain what has changed in plain language."
- "Show me which files are modified, untracked, or staged, and tell me what each category means."
- "Create a commit with the current approved changes, using a clear commit message."
- "Pull the latest version safely and tell me if there are conflicts before resolving them."
- "Push the committed changes to the remote repository after tests pass."
Recommended workflow
- Ask the agent to check the current Git status.
- Ask it to explain any changes before touching them.
- Start from the newest repository version when safe.
- Make the change in a bounded set of files.
- Run relevant tests or build commands.
- Commit with a short, clear message.
- Push the change and deploy only after approval.
- Verify the live environment after deployment.
How to handle a dirty main branch
A "dirty" branch means there are local changes that have not been committed, stashed, or discarded. This is common, but it should be handled carefully, especially on main or on a production server.
Do not ask the agent to "just reset everything" unless you are certain the changes are disposable. A reset can permanently remove local work.
Instead, ask the agent to classify the changes first:
- Which changes are intentional and should be committed?
- Which changes are temporary and should be stashed?
- Which files are generated artifacts that can be ignored or removed?
- Which changes are risky or unclear and need human review?
Good prompt for cleaning up Git status
"Check the Git status. Do not reset or delete anything yet. Group the changes into: safe to commit, should be stashed, generated files, and needs review. Explain your recommendation before running any Git command that changes history or removes files."
Branch or no branch?
Small, safe text changes can often be handled directly in the main flow by agreement. Larger features, experiments, and risky changes should happen on a branch so they can be reviewed before merge. If main is dirty, ask the agent to help preserve the current work first, then create or switch to the right branch.