Picture a small website for a bike repair shop in Hebden Bridge. It has a homepage, a services page, and a footer carrying the shop's phone number. You have been asked to add opening hours to the homepage by Friday. A colleague is rewriting the contact details at the same time.
If you both edit the same files on the same branch, you will spend Friday afternoon untangling each other's changes. Branches exist to prevent exactly that. What follows is the whole cycle — create, commit, merge, resolve a conflict — using that one small project, so the commands have somewhere to live in your memory.
What a branch actually is
A branch in Git is a movable label pointing at a commit. That is the whole idea. When you create one, Git does not copy your files; it writes down a name and points it at the commit you are standing on. Switching branches swaps the files in your working folder to match.
Every repository starts with one branch, usually called main (older projects may still use master). Whatever you commit lands on the branch you are currently on. Git tracks your position with a pointer called HEAD, which is why git status tells you things like "On branch main".
A branch is not a copy of your project. It is a label on a commit, and labels cost almost nothing.
Start a branch before you start typing
Run git status first. If you have uncommitted work you care about, commit it or park it with git stash. Then create and switch to your new branch in one step:
git switch -c add-opening-hours
The -c means "create". Older guides and older Git versions use git checkout -b add-opening-hours, which does the same thing. Both are fine; switch is simply easier to read.
Name branches so a colleague can guess what they do: add-opening-hours, fix-footer-phone, redesign-services-page. Lowercase, hyphens, no spaces, short enough to type without checking.
Make the change and commit it
Edit index.html, add the opening hours block, save, then look at what you have done before you record it:
- git status — shows the file as modified.
- git diff — shows the exact lines you added or removed.
- git add index.html — stages the change.
- git commit -m "Add opening hours to homepage" — records it on your branch.
The diff step matters. It is where you catch a stray console log or a paragraph you did not mean to delete. Commit messages in the imperative mood — "Add", "Fix", "Remove" — read well in a log.
Want the whole picture? git log --oneline --graph --all draws a small diagram showing both branches side by side.
Merging the branch back
When the opening hours look right, switch back and bring the work in:
git switch main
git merge add-opening-hours
Because main has not moved since you branched, Git slides the label forward. This is a fast-forward merge, and there is nothing to resolve. If a colleague has committed to main in the meantime, Git creates a merge commit instead — still automatic, as long as you have not both edited the same lines.
Once merged, tidy up with git branch -d add-opening-hours. The commits stay in the history, which is worth remembering if deleting a branch makes you nervous.
When Git cannot decide: your first conflict
Now the awkward bit. Suppose your colleague's branch, update-contact-footer, changes the same footer lines you touched. You merge it into main and Git stops with "CONFLICT (content): Merge conflict in index.html. Automatic merge failed; fix conflicts and then commit the result."
Nothing is broken. Git has two versions of the same line, no rule for choosing between them, and it wants a human to decide. It marks the spot in the file:
- <<<<<<< HEAD
- your version of the line
- =======
- the incoming version
- >>>>>>> update-contact-footer
Everything between HEAD and the equals sign is what sits on your current branch. Everything below it is arriving from the branch you are merging.
Resolving the conflict, step by step
- Run git status. The conflicted file appears under "Unmerged paths".
- Open the file and find the markers. A large file may contain several sets; work through each one.
- Decide what the final line should be. Sometimes that is one side, sometimes the other, often a blend — your opening hours plus their new phone number.
- Delete the markers and the version you are rejecting, so the file reads exactly as you want it to read.
- Stage and commit. Run git add index.html, then git commit. Git pre-fills the message, so you can save it as it is.
- Check the result. Open the site in a browser and look at the homepage and footer. A clean merge is not the same as a correct page.
If it goes badly, git merge --abort puts everything back as it was before you started. Aborting and reading the diff properly is quicker than guessing your way through.
One habit for next time: keep branches short-lived and merge main into them regularly. Conflicts grow with the number of commits between branch points, so a branch that lives for a day is easier to merge than one that lives for a month.
Habits that keep branching painless
- One branch per piece of work, with a name that describes it.
- Commit in small steps, with messages you would understand in six months.
- Read git diff before every commit.
- Pull the latest main before you merge, so you are merging into reality.
- Keep main working, so anyone can deploy from it at any time.
- Delete branches once they are merged.
Practise on a throwaway folder
Reading about conflicts is not the same as fixing one. Make an empty folder, run git init, add a text file and commit it. Create a branch, change a line, commit. Switch back to main, change the same line differently, commit. Now merge and resolve the conflict by hand.
Fifteen minutes on a folder nobody cares about will teach you more than an hour of reading. Once you have done it once, the second time is just work — and the next time someone asks for a small feature by Friday, you will reach for a branch without thinking about it.
Photo: cottonbro studio / Pexels
