Git Workflow & Parallel Work

KI-generated work is normal software development in XAIO. It is not one large, opaque generation step that you either accept whole or throw away.

Every change is a commit

When the agent finishes a turn, the result is staged, committed and pushed as an ordinary Git commit. The developer who asked for the change is recorded as the commit author; XAIO is the committer. History, blame and your review tools therefore attribute the change to the person, not to a tool.

Because these are ordinary commits, everything you already do keeps working: diffs, branches, merges, pull requests, reverting a single change, bisecting to find where something broke.

Bring your own repository

A project can be connected to an existing GitHub repository. Your branch protection, required reviews and CI pipelines keep applying — XAIO pushes into your process instead of replacing it.

Two people, one repository

Git operations on a project are serialized across the platform's server replicas with a shared lock, so two operations cannot write to the same repository at the same time and leave it half-finished. The classic case this prevents is two processes racing on the repository index.

One honest limitation: the lock is built to degrade rather than to block. If the coordination service is unreachable, the operation still runs, unserialized, and the event is logged. That is deliberate — a lock that becomes a single point of failure is worse than the race it prevents.

What we recommend for teams

• One branch, or one workstream, per feature.
• Merge through pull requests, using the review rules you already have.
• Keep AGENTS.md changes in the same pull request as the code they govern.
• Let one person own a feature's chat. Parallel work is fine across features, expensive inside one.

The agent can read the history

The agent has read-only access to the project's version history: the commit log with filters (file, author, time range, message, code search), the changes in a single commit or a range, line-level authorship, and the branch list with ahead/behind against the base branch. That is enough to produce a changelog, track down a regression, or answer "who changed this?".

Read-only means read-only — no commit, no push, no checkout, no network access from these tools.

The useful one in a team is the code search: asking which commit introduced a particular line finds the commit, and therefore the person to ask.

Who wrote which message

In a shared project every chat message is stored with the sender's email address, taken from the authenticated session rather than from the client, so the agent knows who asked for what. The address is passed to the agent only — the chat itself still shows display names. It uses Git's author format, which is what lets the agent line up chat senders with commit authors.