Git & Command Line•22 min read•Intermediate
Branches & Merging
Why every feature lives on a branch, and how merge / rebase fit changes back together.
Why branches
Branches let you work on multiple things in parallel without them stepping on each other. Standard workflow: one long-lived `main` branch (the source of truth), and short-lived feature branches (one per task). When the feature is done, you merge it back into main.
Git branches & merge
Each commit points to its parent(s). Branches are just movable labels on commits.
HEAD →C3main branch with 3 commits. HEAD points at C3 (main).
Branch commands
bash
git branch # list branches; * marks current
git branch new-feature # create a branch (don't switch)
git switch new-feature # switch to it
git switch -c new-feature # create AND switch in one step
git switch main # back to main
git branch -d done-feature # delete a merged branch
git branch -D dead-feature # force-delete (DANGEROUS — uncommitted work lost)Merging
bash
git switch main
git merge new-feature # bring new-feature's commits into main
# If both branches changed the same lines, you'll get a CONFLICT.
# Edit the files, remove the <<<<< / ===== / >>>>> markers, then:
git add resolved-file.txt
git commit # finishes the mergeFast-forward vs three-way merge
If main hasn't moved since you branched off, Git just FAST-FORWARDS — moves main's pointer to the tip of your branch. If main has new commits too, Git creates a MERGE COMMIT combining both histories.
Rebase — the alternative to merge
`git rebase main` REPLAYS your branch's commits on top of main, producing a linear history. Cleaner log, but rewrites commit hashes — never rebase a branch others have based work on.
bash
git switch new-feature
git rebase main # replay my commits on top of latest main💡 Tip
Pick a side: most teams choose either 'always merge' or 'always rebase before merge'. Both work. Inconsistency is what bites.