It lets you experiment, fix, or build without immediately changing what everyone else relies on. The main version stays stable until your work is ready.
Think about a shared client proposal. There’s a final version the team trusts. Before you rewrite a section, you make a draft copy. You can edit it, ask someone to review, and compare it back to the final, while the trusted proposal stays untouched. A branch works like that, but inside git: a separate line of history in the same repository.
How it shows up
When an agent like Claude Code or Codex works on code, it may create a branch named something like fix-search-filter, so the team knows what kind of draft is happening. As the work progresses it makes commits, each a snapshot of meaningful change, and when the branch is ready you open a pull request so a person or another agent can review before it merges. Branches matter most when several people or agents work at once: without them, one person’s unfinished work can break everyone else, and a bad attempt can be thrown away without the main version absorbing the mess. When two branches change the same part of the same file, you get a merge conflict, which is just Git asking a person to decide the final version.
Why you care
A branch is a draft space. It lets you ask an agent to work without treating every change as final, which makes review calmer: inspect the difference, test the result, ask for revisions, then merge. Good work needs a place to be unfinished before it becomes official.