Git-Native AI Development: Every Action is a Commit

Originally published at getorquesta.com/blog/git-native-ai-development-every-action-is-a-commit-2026-10-23

We built Orquesta with a core assumption: when an AI agent modifies your codebase, you need the same level of traceability you'd expect from a human developer. That means every change lands as a discrete commit, with a diff, an author, and a timestamp. No ephemeral patches, no hidden state. Just git.

Most AI coding tools today treat the repository as a sandbox for experimentation. The agent might apply changes directly to the working tree, or maybe create a single mega-commit at the end of a session. Both approaches obscure the decision-making process. When you review the code later, you can't tell which file was touched by the agent at which step, or why. Rollback becomes a binary choice: accept everything or revert everything. That's a dangerous place to be when you're letting an LLM drive.

Our approach is different. In Orquesta, the agent operates on real branches, and every atomic action it takes becomes a git commit. When the agent edits a file, runs a command, or even just thinks about something in Batuta mode, we snapshot the repository state with a clear commit message. The result is a chronological, auditable log of everything the AI did.

Why traditional AI coding falls short

Let's be honest about the current landscape. Tools like Copilot or ChatGPT generate code snippets, but you copy-paste them yourself. You're the one making the commit. More autonomous agents, like Devin or OpenHands, operate in cloud sandboxes and push changes to your repo at the end of a task. But the intermediate steps are often lost or compressed into a single commit with a generic message like "AI refactor". That's not traceability, it's a black box with a receipt.

When you're working in a team, especially with production code, you need to answer questions like:

• What exactly did the AI change in this file?
• When did it make that change relative to other modifications?
• Who authorized this change? Was it the AI acting autonomously, or a human approving a step?
• If something breaks, how do I isolate and revert only the problematic part?

Without granular commits, these questions are hard to answer. You end up bisecting manually or reading through the entire diff of a large commit, hoping to spot the issue. That's wasted engineering time.

Implementing git-native AI actions

In Orquesta, we treat the git repository as the source of truth for the agent's activity. When you submit a prompt, the agent starts working in a dedicated branch. Every time the agent performs a discrete action—creating a file, editing a block, running a shell command that modifies the code, or even running a test and fixing a failure—we automatically commit the changes. The commit message is generated by the agent itself, summarizing what it did and why. For example:

git log --oneline -5
a3f2c1d (HEAD -> feature/agent-refactor) fix: update regex pattern to handle edge case
8b7e6f5 test: add unit test for new validation logic
c2d9a4e refactor: extract helper function to reduce duplication
7e1b3c0 docs: update README with new API details
5f8d2a1 initial: scaffold new module structure

Each commit has a clear, human-readable message. The author field is set to the AI agent's identity, not the human user, so you can distinguish who (or what) made each change. In our case, we use a separate git config for the agent, like user.name "Orquesta Agent" and user.email "[e-mail]". This separation is crucial for accountability: if something goes wrong, you know it wasn't your teammate's manual edit—it was the machine.

We also ensure that the agent doesn't work directly on main or shared branches. It creates a feature branch from the base. Then, when the work is done, you can open a pull request. The PR shows the complete sequence of commits, allowing reviewers to see the evolution of the code, not just the final state. They can comment on individual commits, ask for changes, or revert specific ones if needed.

The power of step-by-step rollback

The biggest benefit of this approach is surgical rollback. Imagine the agent is working on two separate features in the same session: adding a new API endpoint and fixing a bug in an unrelated utility. Without discrete commits, if the API endpoint introduces a regression, you'd have to revert the entire session's work to remove it, losing the bug fix too. With granular commits, you can simply:

git revert a3f2c1d

and only the problematic commit is undone, leaving the rest of the work intact.

This also helps when you want to experiment with different approaches. Since each step is a commit, you can branch off from any point in the agent's history, cherry-pick specific changes, or compare two alternative paths. It's like having a time machine for your codebase, powered by git's own mechanics.

We've used this to great effect internally. During a recent refactor of our CLI, the agent made a series of commits that progressively improved the code. When we later realized that an early optimization actually made things slower, we were able to git revert that single commit without touching the dozens of subsequent improvements. That would have been a nightmare with a single mega-commit.

Handling commit noise

One common objection is that committing every action creates too much noise. If the agent makes 50 tiny edits, you get 50 commits, cluttering the history. We've addressed this in two ways. First, the agent is instructed to combine related changes into a single commit when appropriate. For example, if it's fixing a typo across multiple files as part of a single logical change, that becomes one commit. Second, we provide a post-processing step in Orquesta where you can squash commits before merging. This gives you the best of both worlds: during the agent's execution, you see every step in real-time, but the final merged history can be as clean as you want.

It's also worth noting that these intermediate commits are on the agent's feature branch, not on your main branch. So the noise is contained. Once you're satisfied, you can squash-merge the entire PR into a single clean commit if that's your team's preference. The granularity is still there for the review process.

Security and auditability

Since Orquesta runs the agent locally on your machine (or on your own infrastructure via Batuta over SSH), the git commits are created locally. No code is pushed to a third-party cloud sandbox. That means your commit history stays within your control. For regulated industries, this is a significant advantage—you can demonstrate exactly what the AI did, when, and with what authorization, all from your existing git logs. Combined with our full audit trail of prompts and API calls, you have a complete chain of custody.

What about non-code actions?

You might wonder: the agent might run commands that don't modify files, like checking the current git status or running a build to see if it passes. Should those be commits? In Orquesta, we only create commits when the repository state changes. Commands that are read-only don't generate commits because there's nothing to commit. But we do log them in the agent's activity feed, so you can see what the agent was doing between commits. This keeps the git history focused on actual changes.

Conclusion

Making every AI action a git commit is more than a technical gimmick. It's a philosophical stance: if we're going to let machines write our code, we need to hold them to the same standards of traceability and accountability that we expect from human developers. Git is the perfect tool for this—it's battle-tested, universally understood, and already integrated into every developer's workflow. By building Orquesta on git-native principles, we've turned AI from a black box into a transparent collaborator. And when something goes wrong, as it inevitably will, you'll be glad you can see every step it took.