Branching is what makes Git powerful, yet it intimidates many developers because the mental model is rarely explained clearly. Once you understand what a branch actually is, the rest — merging, rebasing, resolving conflicts — stops feeling like magic. This guide builds that model and gives you a workflow that works whether you are solo or on a team.
What a branch actually is
A branch in Git is not a copy of your files — it is simply a lightweight, movable pointer to a commit. When you commit on a branch, the pointer moves forward. This is why branches are cheap to create and discard: making one just writes a new pointer. Understanding this demystifies almost everything else.
The everyday workflow
- Create a branch for each piece of work: git checkout -b feature/login.
- Commit small, focused changes as you go.
- Push the branch and open a pull request for review.
- Merge into the main branch once approved, then delete the feature branch.
Keeping the main branch always deployable and doing all work on short-lived branches is the core habit that scales from one developer to many.
Merge vs rebase
Both combine work from two branches, but differently. Merging creates a new commit that ties two histories together, preserving exactly what happened. Rebasing replays your commits on top of another branch, producing a linear, tidy history as if you had started from the latest code. A common guideline: rebase your own local branch to keep it current, but merge (and never rebase) shared branches others may have based work on.
Conflicts are normal
A conflict happens when two branches change the same lines. Git pauses and marks the conflicting sections so you can choose the right result. Conflicts are not errors — they are Git asking a question it cannot answer for you. Resolve them, test, and continue.