“Tests passed” is an incomplete pull request description. Which tests ran, against which revision, and did the agent change anything afterward?
A reliable git workflow connects one bounded task to a branch, explainable commits, revision-specific evidence, human review, and a recoverable merge. Teams introducing coding agents can preserve their existing Git practices while making these handoffs explicit.
The workflow below combines documented Git behavior with a proposed team operating template. The examples are illustrative, not results from an agent benchmark.
Why AI-Assisted Teams Need a Deliberate Git Workflow
An agent can change implementation, tests, dependencies, and configuration within one task. When those changes arrive together, reviewers must reconstruct both the intended behavior and the reasoning behind the patch.
The additional control an AI coding Git workflow needs is evidence continuity: the requirement, diff, test results, and approval should describe the same candidate change. A successful run from an earlier commit cannot validate code added afterward.
Assign a human owner before delegation. That person resolves scope questions and remains accountable for bringing the change through review.
Turn One Task into One Reviewable Branch
Define the task as an observable outcome. For example: “Reject negative retry counts while preserving existing behavior for zero and positive values.” Specify allowed files, acceptance checks, and exclusions such as dependency upgrades.
Keep your established Git branching workflow. For concurrent agents, give each independent task a separate branch and working directory. A linked worktree provides another checkout without switching the original directory’s branch. Git worktree behavior.
git status --short
git fetch origin
git worktree add -b fix/retry-validation ../retry-validation origin/mainThis example assumes origin/main is the intended base and both the branch name and destination are unused. status inspects local changes; fetch updates remote-tracking information without merging into the current checkout. The new worktree leaves existing uncommitted changes in the original directory and does not copy them into the task. Git fetch behavior.
A worktree is not a security sandbox. Configure credentials and execution permissions separately. If two tasks depend on the same interface, agree on that interface and integration order before dispatching both agents.
Keep Agent Commits Small and Explainable
Use one coherent behavior change as the unit of a commit. Keep its regression test alongside it where practical; move unrelated formatting or cleanup into another task.
Before committing, inspect the changed files and stage deliberately:
git diff
git add -p
git diff --cachedThese inspection commands do not discard edits. git add -p changes the staging area by selecting hunks, leaving unstaged edits in the working directory; new untracked files need explicit staging. A commit records everything staged, so review the complete staged diff. Interactive staging.
Prefer Reject negative retry counts before scheduling over AI fixes. Explain why the behavior changed and identify relevant limits in the commit body. Commit size should follow reviewability, not an arbitrary line quota.
Open a Pull Request with Evidence
Open a draft PR when the approach is ready for discussion. Mark it ready for review only when another person can connect the requirement to the implementation and its checks.
Link Requirements, Tests, and Known Limits
For the retry example, connect each requirement to a named test: negative values rejected, zero accepted, positive behavior preserved. Record the tested commit SHA, command, environment, result, and accessible run or artifact link.
Write “not run” for missing checks. If validation used a mocked scheduler, say that integration with the real scheduler remains unverified.
Verdent Manager provides a relevant handoff surface: completed tasks gather in To Review, with outputs and access to changed files or diffs. Teams can use that handoff to assemble the PR evidence, while repository approval and merge decisions remain separate. Verdent Manager task handoffs.
Separate Generated Changes from Manual Fixes
Preserve useful attribution at the commit or PR level. Record what the agent proposed, what a person corrected, and why. Avoid suggesting that a mixed patch has precise line-by-line authorship when that history was not captured.
During review, a separate correction commit makes the response to feedback visible. If the team later squashes commits, retain that explanation in the PR. Rerun affected checks after manual fixes: human edits also change the candidate under review.
Review, Test, and Merge with Guardrails
Review the requirement before reading the agent’s explanation. Then inspect the diff for behavior outside scope, weakened assertions, new dependencies, permission changes, and edits to CI configuration.
Use AI code review to surface possible defects and missing cases. A human reviewer should resolve findings against the requirement and code; another agent’s approval is not independent proof of correctness.
Enforce the pull request workflow through repository settings. On GitHub, protected branches can require reviews and status checks, dismiss stale approvals, or require approval of the latest reviewable push. Configure bypass permissions deliberately. Protected-branch controls.
Run repository-required checks plus tests specific to the change. For retry validation, assertions should cover rejected inputs and unchanged scheduling behavior. If the base branch moves, validate the resulting integration through the repository’s update or merge-queue policy.
Merge only when the final candidate has the required evidence and approval. Restrict agent credentials so they cannot bypass that decision.
Recover from a Bad Agent Change
Stop further automated edits and preserve the failed revision and logs before repairing anything.
For an unmerged branch, add a corrective commit or close the PR while retaining its diagnostic record. Do not reset a directory containing someone else’s uncommitted work.
For a merged change, a reviewed revert usually preserves shared history more clearly than rewriting the branch. git revert records a new commit that reverses an earlier change and normally requires a clean working tree. Git revert behavior.
Identify the actual merged commit first: a squash commit and a merge commit require different handling, and reverting a merge requires choosing its mainline parent. Test the recovery patch and follow the normal approval path. Reverting source code does not reverse database migrations, external writes, or deployed state; those need their own recovery steps.
A Team Workflow Template
Copy this into a task or PR template. Fill it before treating an agentic development workflow as ready for merge.
Task and acceptance:
- Issue / requirement:
- Expected behavior and regression cases:
- Allowed scope / exclusions:
Ownership and isolation:
- Human owner / reviewer:
- Base revision / task branch / worktree:
- Agent tool and available run identifier:
- Permissions / dependencies on other tasks:
Change and evidence:
- What changed, and why:
- Agent contribution / manual corrections:
- Tested SHA / integration revision:
- Commands / environment / results / artifact links:
- Checks not run / known limits:
Decision and recovery:
- Required reviews and checks:
- Final approved revision:
- Merge method / resulting commit:
- Revert target / external-state recovery:Treat an empty evidence field as an unanswered question. If the revision changes, refresh the affected results before approval.
FAQ
Should an AI Agent Be Added as a Commit Co-Author?
Follow repository policy and any applicable tool requirements. GitHub supports Co-authored-by trailers, but the trailer itself records attribution, not approval or correctness. Use an appropriate documented identity rather than inventing one. If co-authorship is unnecessary, record the tool and contribution in the PR while identifying the responsible human owner. Commit co-authorship.
How Should Agent Commits Be Handled During a Repository Freeze?
Apply the same freeze policy to agent and human changes. Disable scheduled write or merge automation where required; allow draft preparation only if policy permits it. Emergency exceptions should identify the release owner’s authorization, eligible fix, target branch, and required checks. An agent classifying its own patch as “low risk” does not grant an exception.
What Is the Safest Way to Backport an Agent-Authored Fix?
Create a dedicated branch from the supported release branch and select the smallest complete fix, including necessary dependencies. From a clean checkout, git cherry-pick -x <commit> can record the source commit for traceability. Cherry-picking changes the index and working tree and may conflict. Review adaptations and run release-branch tests; a clean application alone does not establish compatibility. Backport traceability.
How Should Teams Preserve Review Evidence After Squash Merging?
Record the final PR head SHA, resulting squash SHA, approvals, check-run identifiers, and relevant artifacts in a durable record linked to the PR. Squashing combines the changes into a new commit, so retain an explicit mapping. Archive essential evidence according to retention policy rather than relying on temporary CI links. Squash-merge behavior.
Can Agent Pull Requests Be Included in Release Provenance Records?
Yes. Link the PR and merged revision to the release’s source revision, build run, and artifact digest. Record agent involvement as supplemental metadata where your system supports it. Build attestations can establish artifact origin and build context; they do not establish that AI-generated code is correct or that a human reviewed it. Artifact attestations.
Conclusion
A useful git workflow makes “tests passed” precise: this requirement, this revision, these checks, and this reviewer’s decision. When a late edit breaks that chain, the change returns to validation. That rule keeps agent speed compatible with a team’s ability to explain, approve, and recover its work.
