Branches and pull requests explained without jargon

If you are not sure what a commit or a diff is, start with Git for designers. This page focuses on what comes next: how to use branches and pull requests to review what an AI does.

Why should the AI work on a branch?

An AI can touch many files in a single step. If it does so directly on the main version, any mistake reaches everyone, and undoing it means guessing what moved. On a branch, the change is isolated: if it goes wrong, you discard the branch and the main version stays as it was.

GitHub’s official guide puts it this way: creating a branch gives you “a space to work without affecting the default branch”, and a short, descriptive name lets collaborators see ongoing work at a glance. Its examples are increase-test-timeout and add-code-of-conduct (GitHub Docs, GitHub flow). In your own project, fix-contact-form works the same way.

Branches also allow parallel work. If the menu redesign takes a week and a form fix takes an hour, each task lives on its own branch and the fix does not wait for the redesign.

What is a pull request and what does it contain?

It is the formal request to merge a branch’s changes into another branch, usually the main one. GitHub defines it as a proposal to merge changes into a project and organizes it into tabs (GitHub Docs, About pull requests):

Reviewers can comment on the whole set or on a specific line, and the author pushes more changes to respond. When the change is ready, it is merged and the branch is deleted.

Reviews come in three types: comment without approving or rejecting, approve (the changes are ready to merge), or request changes before merging. Review is optional unless a repository administrator requires approvals before merging (GitHub Docs, About pull request reviews).

GitHub also offers draft pull requests. A draft cannot be merged, and code owners are not automatically asked to review it until it is marked ready. It is useful while the AI is still working, or when you want to show progress with no risk of it being merged by mistake.

How do you review a pull request made by an AI?

The typical flow looks like this:

1. You create a branch for the task.
2. The AI makes the change on that branch and commits are saved with clear descriptions.
3. You open a pull request with a three-line description: what changed, why and how it is tested.
4. You review the full diff in the files-changed tab, not just the screen. Look for unexpected files, new data and added dependencies.
5. If something is extra, ask the AI to remove it and update the pull request.
6. Merge when the task’s criteria are met, and delete the branch.

A simple practice: one pull request per task. If a change mixes three subjects, it is hard to review and, if one part fails, it blocks the other two. When a task takes more than a day, split it into small pull requests, each with its own review.

What do you look for in the AI’s diff?

With the task’s criteria in view, check four things:

• Scope. Do the touched files match what you asked for? A configuration or validation file nobody mentioned deserves a question.
• What was deleted. Red lines matter as much as green ones. A removed check can make something “work” without being right.
• New dependencies and data. Added packages, keys, URLs or pasted text you did not expect.
• Behavior. Open the branch and try it. A clean diff does not guarantee the screen looks or works right.

If the change touches data or permissions, read frontend vs. backend first to confirm the rule lives in the right place. To review code you did not write, reading code without knowing how to program gives the minimum questions. The criteria you check come from a PRD for agents or a specification written before starting.

When is a branch not needed?

For a text fix in your own project, a branch may be more paperwork than value. Branches and pull requests make sense when the change touches several files, when another person must review it or when what breaks could affect users. A useful test: if you would not mind discarding the whole change, it can go straight in; if you would mind, use a branch.

Example

Illustrative example: a designer needs to change the button color across a site and, at the same time, wants the AI to rewrite the pricing page. She creates two branches: button-colors and rewrite-pricing. The first is merged in a day. The second takes a week and goes through review by someone on the content team, who comments on two paragraphs. Reviewing the pricing diff, the designer notices the AI also modified the contact page template, which she had not asked for. She has it removed before merging. Because each change has its own pull request, the color change did not have to wait for the pricing copy and the extra change never reached production.

How to apply it tomorrow

1. Before asking the AI for the next change, create a branch with a name of two or three words that describes the task.
2. Write the pull request description before opening it: what changed, why and how it is tested. If you cannot write it, the change is not ready for review.
3. Review the full diff and tick off each of the task’s criteria before approving.
4. Once the change is merged, delete the branch. Old branches confuse more than they help.

A pull request also documents decisions: when a review changes a rule, note in the description why. A good title describes the result, not the process: “Fix the primary button color” says more than “various changes”.

Common mistakes

• Working everything on the main branch because “it is only a small change”.
• Naming branches test2 or final-changes.
• Opening a pull request with no description, so nobody knows what to review.
• Approving without reading the diff, or reading only the green lines.
• Leaving old branches open for months, with changes that no longer fit.
• Mixing several subjects in one pull request.

Sources

• GitHub Docs, “GitHub flow” (branches, commits, pull requests, merge and branch deletion): https://docs.github.com/en/get-started/using-github/github-flow
• GitHub Docs, “About pull request reviews” (review types and administrator-required approvals): https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews
• GitHub Docs, “About pull requests” (pull request tabs, head and base branch, drafts): https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests