Git and GitHub: a workflow for AI projects

Git and GitHub were already the foundation of team software work. With AI agents that edit files, run commands and make commits on their own, they have taken on another role: recording exactly what changed, separating the agent’s work from the version that is live and preventing anything from being published without review.

This article describes a workflow for AI projects built from the official documentation of Git (git-scm.com), GitHub (docs.github.com) and agent tools, consulted on October 8, 2026. GitHub’s features and plans change frequently. Before configuring anything, check in the documentation what applies to your type of account and repository.

Git and GitHub: the concepts you need

Git is a version control system: it stores a project’s history in steps. GitHub is an online service that hosts Git repositories and adds review, permissions and automation. One does not depend on the other, but they usually go together.

A repository is the project folder with its entire history.

A commit is a record of a set of changes, with author, date and message. It is Git’s “save point.”

A branch is a parallel line of work. The official book Pro Git defines it as a lightweight, movable pointer to a commit. Creating a branch is cheap and almost instantaneous, which encourages using one for each task.

A pull request (PR) is a request, made on GitHub, to merge the changes from a branch into the main branch. That is where review happens.

Why this matters more when an agent writes code

AI-generated code tends to look right before it is right. In the 2025 Stack Overflow survey, 84% of respondents said they use or plan to use AI tools in development. The main frustration, cited by 66%, was solutions that are “almost right, but not quite.” And 46% said they distrust the accuracy of the answers.

An agent also acts in more places than autocomplete. In how Claude Code works, we show that it reads the project, edits files, runs commands and uses git.

Claude Code’s documentation says its checkpoints (automatic restore points) let you undo file edits, but they are separate from git and do not cover actions on remote systems, such as databases, APIs and deployments, according to the How Claude Code works page. A git push to the wrong place or a deploy does not come back with a keyboard shortcut.

That is why the workflow below starts from a simple rule: the agent can make all the mistakes it wants inside an isolated area, and only what passes review reaches the main version.

The basic workflow, adapted for agents

GitHub documents a lightweight workflow called GitHub flow, with six steps: create a branch, make changes with commits, open a pull request, address review comments, merge and delete the branch.

In an AI project, the same workflow looks like this:

1. You describe the task to the agent.
2. The agent creates a branch for it and works only there.
3. It makes small commits as it goes and runs the tests.
4. It (or you) opens a pull request summarizing what changed.
5. A person reviews, requests adjustments and approves.
6. Automated checks pass, and only then does the code enter the main branch.

The following sections detail each lock along this path.

Rule 1: the agent works on its own branch

According to GitHub flow, working on a branch keeps the default branch intact. Use short, descriptive names that show the task, such as fix-login or agent/adjust-prices.

If you run more than one agent at the same time, or want to keep programming while it works, use worktrees. According to Git’s documentation, the git worktree command lets you have several working folders linked to the same repository, each with a different branch. One agent’s edits do not collide with yours.

Claude Code has this feature built in. The Common workflows page shows the claude --worktree task-name command, which opens an isolated session in its own worktree. The same page suggests plan mode, in which the agent proposes a plan and edits nothing until you approve.

The GitHub Copilot agent that works in the cloud (called a cloud agent in the documentation) follows the same logic by default. According to the risks and mitigations page, it can only push code to a single branch, created with the copilot/ prefix when the task does not start from an existing PR, and branch protections still apply.

Rule 2: small commits and clear messages

A giant commit with ten mixed changes is hard to review and impossible to undo halfway. Pro Git, in the Contributing to a Project section, recommends that each commit be a logically separate set of changes, with at least one commit per issue.

The same chapter gives practical guidance:

• run git diff --check before committing to find problematic whitespace;
• use git add --patch to include only part of a file’s changes;
• write a summary line of up to about 50 characters, leave a blank line and explain the reason for the change in the body;
• use the imperative: “Fix bug,” not “Fixed bug.”

You can record these rules in the agent’s instructions file (in Claude Code, CLAUDE.md). Explicitly ask for small commits, one change per commit and messages that explain why.

Identify what was done by AI. GitHub records the Copilot agent’s commits as authored by Copilot, with the person who requested the task as co-author, to make traceability easier. Claude Code also adds attribution lines to commits and PRs by default, which are configurable, according to its documentation.

Rule 3: human review on every pull request

The pull request is where you read the diff, the line-by-line comparison between old and new code. Claude Code’s documentation recommends reviewing the generated PR before submitting it and asking the agent itself to highlight risks and points of attention.

Two settings reinforce this stage:

• CODEOWNERS. A file with this name, in .github/, at the root or in docs/, defines who is responsible for each part of the code. According to the documentation, these people are automatically requested to review PRs that touch their files.
• Whoever asks does not approve. With the Copilot agent, the person who requested the task cannot approve the resulting PR, which preserves the requirement for approval by someone else. GitHub Actions workflows (repository automations) also only run after someone with write permission approves.

In the newsroom’s assessment, review is the easiest stage to skip when the code “seems to work.” It is precisely there that unnecessary dependencies, tests that only confirm their own error and changes outside the requested scope show up.

Rule 4: protect the main branch

Verbal agreements do not hold back an agent with push permission. Rules configured on GitHub do, because they apply to any account or app.

Protected branches allow, among other options:

• requiring a pull request with a minimum number of approvals before merging;
• dismissing stale approvals when new commits arrive;
• requiring review from the owners defined in CODEOWNERS;
• requiring automated checks to pass, such as tests, lint and type checking;
• requiring signed commits and linear history;
• blocking force push (forcibly rewriting history) and branch deletion, which are blocked by default;
• applying the rules to administrators as well.

Rulesets are the newer alternative. According to the documentation, several rulesets can apply to the same branch at the same time, and when two rules conflict the most restrictive one wins. They can also be turned on and off without being deleted.

For required checks, choose what the agent cannot “talk its way past”: automated tests, the project build and, in JavaScript projects, type checking. We explain why types catch a good share of errors in AI-generated code in TypeScript: why adopt it.

Rule 5: secrets out of the repository

Passwords, API keys and tokens (access credentials) should not go into Git. Once in a commit, they stay in the history even after being deleted from the file.

The risk is concrete. According to a report by security company GitGuardian released on March 17, 2026, about 29 million secrets were detected in public commits on GitHub in 2025, up 34% in one year. The company says commits made with the help of Claude Code leaked secrets in about 3.2% of cases, double the overall average. These are GitGuardian’s own measurements, a company that sells security products, with a methodology described in little detail in the announcement. And a higher rate does not prove the tool causes the leak: the text itself says the cases may reflect human error.

Three layers help:

1. The .gitignore file. It lists files Git should ignore, such as the .env with local credentials. Note the detail in the documentation: files Git already tracks are not affected. If .env has already gone into a commit, you need to remove it from the index with git rm --cached.
2. Secret scanning. GitHub looks for credentials across the entire history of all branches, as well as issues and pull requests. According to the documentation, it is automatic and free on public repositories. On private organization repositories, it depends on the paid GitHub Secret Protection product.
3. Push protection. Instead of warning afterward, it blocks the push that contains a secret and explains why. The user version is on by default and prevents pushing secrets to public repositories on GitHub.com. The per-repository version needs to be enabled. Whoever bypasses the block must give a reason, and the bypass is logged.

If a secret leaks, GitHub’s guidance is to revoke and rotate the credential immediately. Cleaning the history is laborious and, once the key has been revoked, often unnecessary.

Checklist for your repository

• The main branch is protected and only receives code through pull requests.
• At least one human approval is required, and stale approvals are dismissed with new commits.
• Tests, build and type checking are required checks.
• The agent works on its own branch, preferably in a separate worktree.
• The agent’s instructions file asks for small commits and explanatory messages.
• .gitignore covers .env and other files with credentials.
• Secret scanning and push protection are active where your plan allows.
• The agent has no permission to push directly, deploy or change production settings without asking.

Key takeaways

With AI agents, Git stops being just history and becomes the project’s security perimeter. The agent can experiment freely on an isolated branch. What reaches the main version goes through a pull request, human review and automated checks.

The most effective locks are the ones configured on GitHub, because they apply equally to people and agents: protected branches, required review, tests and types as a merge condition, secret scanning and blocking.

If you are starting a product with these tools, see also how to build an MVP with AI agents and how to measure productivity in AI projects.