Branching and merging

A branch is not a separate copy of the project's files — it's a lightweight, movable label pointing at a specific commit. git branch feature creates a new pointer, initially pointing at the same commit main currently points to; committing on feature moves that pointer forward, leaving main's pointer exactly where it was. This is why creating a branch in Git is close to instant regardless of project size — it's creating one small pointer, not duplicating any files.

git checkout -b creates a branch and switches to it in one step (the modern equivalent, git switch -c, does the same thing with clearer naming — both take the new branch's name as an argument). Every commit made while on feature-login only moves the feature-login pointer — main stays exactly where it was, completely unaffected, the whole time. This is the actual mechanism behind "work on something risky without touching the stable version": the risky work genuinely lives on its own line of commits, isolated by construction, not by convention.

git checkout main then git merge feature-login brings feature-login's commits into main — Git creates a new merge commit (M above) that has two parents, one on each branch, combining both histories into one. After merging, main contains everything from both lines of work; feature-login still exists as a branch (until explicitly deleted), but its work is now also part of main's history.

If main hasn't moved at all since feature-login branched off (nobody else committed to main in the meantime), merging doesn't need to combine two diverging histories at all — Git just moves main's pointer forward to match feature-login's latest commit. This is called a fast-forward merge, and it's the simple case; the two-parent merge commit from the previous section only becomes necessary once both branches have diverged with independent commits.

A conflict happens when both branches changed the same lines of the same file in different, incompatible ways — Git can automatically merge changes to different files, or different parts of the same file, but it has no way to guess which of two conflicting changes to the same lines is correct. It marks the conflicting section directly in the file with <<<<<<</=======/>>>>>>> markers, and resolving it means manually editing the file to keep the correct version (one side, the other, or a combination), removing the conflict markers entirely, then git adding the resolved file and completing the merge with git commit.

Multiple people (or the same person, on multiple unrelated tasks) can work simultaneously, each on their own branch, without their in-progress work interfering with each other or with main at all — this is the practical foundation nearly all real collaborative Git workflows are built on, whether that's a team's pull-request process or one person just keeping "the stable version" and "the thing I'm currently experimenting with" cleanly separate. Cheap, disposable branches are what make it normal to create one for every single feature or fix, rather than branching being a rare, heavyweight event.