Commits, Branches & Merges: The Model
Version control has three core ideas, and once you have them, you can follow almost any conversation about how a team works: commits (described snapshots of change), branches (independent lines of work), and merges (bringing branches back together). The commands belong to the Git course; the mental model belongs here.
These three words come up constantly — "I committed that", "work on a branch", "we merged it" — so this is the vocabulary that makes the rest make sense.
A picture to hold: writing a chapter on a photocopy of the manuscript, then carefully folding your edits back into the master. The photocopy is a branch; folding it back is a merge; each saved step along the way is a commit.
Commits
A commit is a described checkpoint — a snapshot of the code at a moment, with a short message saying what changed and why. Commits are the unit of history: each one is a point you can return to, and together they tell the story of how the code got to where it is. Good practice is small, frequent commits with clear messages, so each step is easy to understand and undo on its own.
Branches
A branch is an independent line of work — a safe parallel copy where you can build a feature without disturbing the main code. You branch off, make your commits there, and the main line stays untouched until you're ready. Branches are cheap and quick, which is what lets several people each work on their own thing at the same time without interfering.
Merges and Conflicts
A merge combines the work from one branch back into another — usually a finished feature branch into the main line. Most merges are automatic. But when two people changed the same lines in different ways, version control can't guess who's right, so it flags a merge conflict and a human decides how to combine them. A conflict isn't a disaster — it's just two overlapping changes needing a quick human judgment.
The Main Branch
One branch is special: the main branch (often literally called main). It's the shared, authoritative line that's meant to always be in working order — the version you'd ship. Everyone branches off main to do work and merges finished, reviewed work back into it. Keeping main always working is a core team discipline, because it's the line everyone depends on.
On Cadence, Lena builds the reminders feature on a branch called reminders, committing as she goes, while Marcus fixes a separate bug on his own branch off main. When reminders is done and reviewed, it merges into main. A small conflict pops up on one file they both touched — they resolve it by hand in a minute. Two people, two parallel lines of work, cleanly brought together.
- "Branching duplicates the real code and risks it." Branches are cheap, isolated lines of work; the main code stays safe while you experiment. Branching is the safe way to work, not a risky one.
- "A merge conflict means something is broken." It just means two changes overlapped on the same lines, so a person has to choose how to combine them. It's a normal, routine part of teamwork.
- "You should commit rarely, in big chunks." Small, frequent, well-described commits are the norm — each one easy to understand and undo. Giant commits hide what changed and are hard to reverse.
- "Branch", "commit", "merge", and "conflict" are everyday words on any team — this is the mental model that makes them all click.
- It's the direct foundation for pull requests in the next topic, which are built on branches, commits, and merges.
- Understanding the main branch as the always-working shared line explains a lot of how teams protect quality and coordinate work.
Knowledge Check
What is a commit?
- A described checkpoint of the code, with a message about what changed
- An independent parallel line of work kept separate from the main code base
- The act of combining two separate lines of work together
- The completed final version of the software ready to ship
What is a branch?
- An independent line of work where you can build without disturbing main
- A single described checkpoint of the code at one moment
- A report describing a defect that was found in the code
- A group of developers who are assigned to work on one part of the project
What is a merge conflict?
- When two people changed the same lines, so a human must combine them
- A serious error meaning the whole codebase is now broken
- An argument between two of the developers about how the code should be written
- A slowdown that happens when too many branches exist
What is special about the "main" branch?
- It's the shared, authoritative line that's meant to always be working
- It's a throwaway copy used only for risky experiments
- It's a private branch belonging to one senior developer
- It's the actual physical server that the live application runs on in production
You got correct