Before an AI changes a real project, you need a way to answer three simple questions:

1. What did the project look like before this change? 2. Exactly which files changed? 3. How do we safely keep, share, or undo the result?

That system is Git. A branch is one of Git's most useful tools. GitHub is where a Git project can be backed up, shared, reviewed, and connected to services that deploy it.

This sounds technical at first because the names are unfamiliar. The underlying idea is simple: Git gives your project a memory; branches give you a safe place to try a change before it becomes the main version.

Start with the three things people mix up

Git is not the same thing as GitHub. Git runs on your computer. You can use Git without a GitHub account. GitHub is a popular place to send a Git project when you want a backup, collaboration, pull requests, or a connection to deployment tools.

The project itself might look like this:

my-app/
  README.md
  CONTEXT.md
  src/              the application code
  public/           images and public files
  package.json      project tools and scripts
  .git/             Git's local history and settings

You normally do not open or edit .git/ yourself. Git manages it. Its presence tells you the folder is a Git repository: a project folder whose history Git is tracking.

Git records checkpoints called commits

You do not save every keystroke in Git. You make a commit when a focused piece of work reaches a useful checkpoint.

For example:

Commit 1: Create the pricing page structure
Commit 2: Add three pricing cards
Commit 3: Fix mobile layout and verify in browser

Each commit records the files that changed and a message explaining why. That gives you a sequence you can inspect later:

Create project ── Add pricing cards ── Fix mobile layout ── Add comparison table
      A                    B                     C                    D

If the comparison table breaks the site, Git lets you compare it with the earlier checkpoint. You can restore a file, undo a change deliberately, or return to a version that worked. Git does not make bad work good; it makes the history visible and recoverable.

The main branch is the version you protect

Most projects call their primary branch main. It represents the version of the project you treat as the accepted baseline. On a live product, it is often the branch that deployment services use to create the production site.

main
  A ── B ── C

You can work directly on main when you are learning or making a tiny personal change. But once the project matters—or an AI is about to make a real feature—you get a safer workflow by creating a branch first.

A branch is a separate line of work, not a separate project

A branch starts from a known Git checkpoint and gives one idea its own history. It still belongs to the same repository and can use the same project files, but its commits do not change main until you deliberately merge them.

main:                 A ─────────────── B
                          \
feature/pricing-page:     C ── D

In this example:

• A is the last accepted version of the project.
• You create feature/pricing-page from A.
• The agent makes commits C and D for the pricing-page work.
• main stays untouched while you test and review.
• When the work is approved, you merge the branch into main, producing B.

Think of a branch as a protected experiment. It is not a whole duplicate application and it is not a magical safety shield. It is a clear boundary around one change, with a history you can review before accepting it.

Git, GitHub, and the path to a live product

Git keeps the local history. GitHub receives the commits when you push them. A deployment service can then build a preview or production version from the GitHub repository.

Project folder on your computerGit commit: local checkpointFeature branchGit pushGitHub repositoryPull request: review the changeMerge into mainProduction deployment

GitHub does not automatically make a branch live. Your hosting setup decides what happens. Many projects deploy a preview from each pull request and deploy production only after a merge into main. That is a strong default because you can test the real branch before it affects users.

Why branches matter more with AI

An AI can change many files quickly. That is useful when the brief is clear and dangerous when the task grows fuzzy. A focused branch makes the question reviewable: did this branch do the one job we asked for?

Give the agent a branch boundary like this:

Confirm the current branch before editing.

Work only on `feature/company-comparison`.
Read README.md, CONTEXT.md, and the comparison specification first.
Do not modify the database schema, authentication, or deployment settings.
Run the required checks.
Summarize changed files and wait for review before merging or deploying.

The branch name should describe the job. feature/company-comparison is better than new-stuff. You should be able to see a branch in GitHub and immediately understand its purpose.

Review before you merge

Opening a pull request is not paperwork for its own sake. It gives you a clean screen for reviewing the branch against main: changed files, added lines, removed lines, test results, discussion, and deployment preview.

Before you merge an AI-made branch, answer:

1. Did it change only the files you expected? 2. Does the diff contain a dependency, secret, configuration, or database change you did not approve? 3. Did the project checks pass? 4. Did you test the actual behavior in the browser, including the important mobile or user path? 5. Does the pull request or handoff say what changed and what remains?

If the answer is unclear, do not merge yet. Ask the agent to explain one change, revise the branch, or stop the experiment. A merge is the moment an isolated idea becomes part of the accepted project history.

What happens when two changes meet

Two branches can usually merge cleanly when they change different files or different parts of a file. A merge conflict happens when Git cannot safely decide how to combine two incompatible edits to the same lines.

That is not a disaster. It is Git refusing to guess. Read both changes, decide which version belongs in the product, test it, and make a new commit that records the decision. Do not ask an agent to automatically accept every conflict without showing you the affected code.

Parallel AI work needs separate boundaries

A Git worktree is an advanced tool that gives each branch its own physical folder on your computer. That means two coding agents can work at the same time without one agent's uncommitted files appearing in the other agent's workspace. You do not need worktrees on day one. You need the principle: two builders should not silently edit the same working copy.

A branch has three healthy endings

Every branch should end in one of these states:

• Merged: the change was reviewed, tested, and accepted.
• Closed: the idea was rejected or no longer needed.
• Paused with a note: work is blocked, but the branch and handoff explain why.

Do not keep a cemetery of branches named test2, fix-final, and new-stuff. Good names and short handoffs are part of project memory. “Tried a new onboarding flow; paused because mobile navigation needs redesign” prevents the next agent from repeating the same experiment blindly.

Practical exercise: make one safe branch

Choose a small documentation change. Then ask an AI agent:

Read the answer. Then create a clearly named branch such as docs/improve-readme, make one small change, inspect the diff, test anything affected, and commit it with a clear message. If GitHub is connected, push the branch and open a pull request—even if you are the only reviewer.

You are learning the full loop: create a safe place, make one focused change, examine the evidence, and choose whether the project should accept it.

Check your understanding

1. What is the difference between Git and GitHub? 2. What does a commit record? 3. Why is main treated differently from a feature branch? 4. What is a pull request for? 5. Why do two active AI builders need separate branches or worktrees? 6. What should happen before an AI-made branch is merged or deployed?