Git records snapshots of intentional file changes and the reasoning that connects them. A good backend workflow uses small branches, readable diffs, tests, and focused commits so a change can be reviewed, understood, and reversed. Git is not a backup for secrets, databases, or uncommitted work.
The important step is reviewing git diff --cached: the index is the exact proposal for the next commit. Avoid git add . until you understand every untracked file.
A commit should represent one reviewable reason. “Add ticket input validation and its tests” is stronger than “updates.” Formatting, dependency changes, migrations, and behavior changes are easier to review when separated where practical.
If a shared commit is wrong, prefer:
This adds a visible inverse change. Rewriting shared history can remove colleagues' work and should require explicit coordination.
Prompts, tool schemas, evaluation datasets, safety policies, and model routing rules are executable product behavior. Version them beside code. A prompt change without evaluation evidence deserves the same scrutiny as a business-rule change. Never commit provider keys or private evaluation examples.
Make two independent changes: add a README sentence and add a harmless test. Stage only the test, prove the README remains unstaged, commit, then commit the README separately.
Acceptance criteria: git show --stat proves two focused commits and git status --short ends clean.