Branches and Merging Essentials

Your team is building a website. One person needs to redesign the homepage while another fixes bugs in the checkout process. If they both edit the same files at once, chaos erupts—edits collide, work vanishes. Git branches solve this by letting each person work on a separate copy of the code at the same time.

Think of a branch as a parallel timeline. The main branch (usually called main or master) is your official, stable code. When you create a new branch, you're saying "I'm splitting off here to work on something." Your changes live only on that branch until you're ready to merge them back.

Let's walk through it. Sarah starts on main, then creates a branch called dark-mode. She commits changes to dark-mode—new colors, updated fonts. Meanwhile, James creates a branch called fix-login from the same main and commits fixes to the login form. Their work doesn't interfere. Each branch is its own timeline.

When Sarah's dark-mode work is solid, she merges her branch back into main. Git compares what changed on dark-mode versus main and weaves those changes in. Now main has both the dark-mode features and everything else. James does the same with fix-login. Both features are now in the official code.

Merging usually works smoothly. But if Sarah and James both edited the same line of code, Git stops and asks you to resolve the conflict by hand—decide which version to keep.