Branching and merging

Branching is what makes Git a collaboration tool rather than just a backup. A branch lets you work on something — a feature, a fix, an experiment — without disturbing the stable code everyone else depends on, and then bring it back in when it is ready. On a real team, essentially all work happens on branches. This lesson is branching and merging in practice: how to create a line of work, and how to combine it back.

Why branch at all

Imagine everyone committing directly to main: half-finished features, broken code, and constant collisions, all on the branch that is supposed to be deployable. Branching solves this. You create a branch for your piece of work, commit freely on it — even broken, in-progress commits — and main stays clean and releasable the whole time. When your work is done and reviewed, you merge it into main. Because a branch is just a cheap pointer (the model lesson), this costs nothing and is the normal rhythm of work:

git switch -c fix/login-timeout   # create a branch and switch to it
# ... edit, add, commit as many times as you like ...
git switch main                    # go back to main; your work sits safely on the branch

A good habit: name branches for what they do — feature/agent-search, fix/payment-double-charge, chore/upgrade-deps. On a team, the branch name is the first thing people see, so make it say what the work is.

Bringing work back: merging

When your branch is ready, you merge it into the target branch (usually main). You switch to the branch you want to merge into, then merge the other one in:

git switch main
git merge fix/login-timeout   # bring the fix branch's commits into main

Git does this in one of two ways, and knowing which happened explains a lot:

• Fast-forward — if main has not moved since you branched, merging just slides main's pointer forward to your branch's latest commit. No new commit is created; the history stays linear. This happens when nobody else changed main while you worked.
• Three-way merge — if main did move on (someone else merged their work), Git combines the two lines of history by creating a new merge commit that has two parents — one from each branch. Your history now shows the two lines diverging and coming back together.

You do not choose between these; Git picks based on whether the histories diverged. Understanding them means a merge commit appearing in your history is not a mystery — it is Git recording that two lines of work were combined.

Keeping a branch up to date: merge vs rebase

While you work on a long-lived branch, main moves on underneath you. Before merging back, you often want your branch to include the latest main — to test against current code and to make the final merge clean. Two ways:

• Merge main into your branch — git switch mybranch; git merge main. This brings main's new commits in with a merge commit. Safe and simple; the history shows the merges.
• Rebase your branch onto main — git switch mybranch; git rebase main. This replays your branch's commits on top of the latest main, as if you had started from there. The result is a clean, linear history with no merge commits — but it rewrites your branch's commits (they get new hashes).

The practical rule that keeps you safe: rebase produces tidier history, but never rebase commits you have already shared/pushed and others may have based work on — rewriting shared history causes painful confusion. Rebasing your own local, unshared branch to tidy it before opening a pull request is fine and common; rebasing a branch other people are using is not. When in doubt, merge — it is always safe.

A simple, real workflow

Most teams use a variant of this feature-branch workflow, and it is the one to internalise:

1. Start from an up-to-date main: git switch main; git pull.
2. Branch for your work: git switch -c feature/thing.
3. Commit as you go on the branch — small, meaningful commits.
4. Push the branch and open a pull request (the PR lesson) for review.
5. Merge into main once approved and green in CI.
6. Delete the branch — it has served its purpose; a merged branch left around is clutter (and, as you may have seen, can pile up).

main is always deployable; all work happens on short-lived branches that are reviewed before merging. This single workflow underlies almost all professional software development, and every other Git skill (conflicts, undoing, PRs) sits inside it.

Check your work

Why branch: so in-progress/broken work does not touch the stable, releasable main; you commit freely on a branch and merge back when ready. Branches are cheap pointers — the normal rhythm. Name them for what they do (fix/..., feature/...).

Merging (git switch main; git merge branch) happens two ways: fast-forward (main hasn't moved → pointer slides forward, linear history, no merge commit) or three-way merge (main moved → a new merge commit with two parents). Git chooses based on whether histories diverged.

Staying current — merge vs rebase: merge main into your branch (safe, adds a merge commit) or rebase your branch onto main (replays your commits → clean linear history, but rewrites commits). Rule: rebase only your own unshared commits; never rebase shared/pushed history; when in doubt, merge.

Feature-branch workflow: update main → branch → commit → push + PR → review → merge → delete branch. main always deployable; short-lived reviewed branches. The backbone of professional development.

Practice

1. Create a well-named branch, make two commits on it, switch back to main, and confirm main is unchanged.
2. Merge a branch into main where main has not moved; confirm it fast-forwarded (linear, no merge commit).
3. Create divergence (commit on main and on a branch), merge, and find the resulting merge commit in the log.
4. Explain the difference between merging main into your branch and rebasing your branch onto main.
5. State the rule about when rebasing is safe and when it is dangerous, and why.
6. Write out the six steps of the feature-branch workflow and do one full cycle on a practice repo.

Official documentation

• Pro Git — Basic branching and merging — Creating branches and merging them.
• Pro Git — Rebasing — Rebase versus merge, and the golden rule.
• GitHub — GitHub flow — The feature-branch + pull-request workflow.

Next: resolving conflicts without panic.