🌿 Lesson 4: Branches & Merging

🌳 Introduction: Why Branches?

Imagine you want to try a dark color scheme on your website. It might look amazing. It might look terrible. And it might take a few tries and a few commits to find out. Meanwhile, you'd like your working site to stay exactly as it is, in case you need to fix a typo on the Contact page in the middle of the experiment.

That's what a branch is for. A branch is a separate line of commits, a safe copy of your timeline where you can experiment freely. Your main timeline (the main branch you've been using all morning) doesn't change until you decide to merge the experiment in. And if the experiment flops, you simply never merge it.

In the diagram, main keeps moving (a typo fix) while the dark-theme branch holds two experimental commits. When the experiment is done, it's merged back into main.

🔀 Creating & Switching Branches

Before you start, make sure your work is committed: git status should say nothing to commit, working tree clean.

See your branches: git branch

git branch

* main

Just one so far. The * marks the branch you're currently on.

Create a branch and switch to it: git switch -c

Branch names should be short, lowercase, and use hyphens instead of spaces, and they should describe the experiment:

git switch -c dark-theme

Switched to a new branch 'dark-theme'

-c means create. Check again:

git branch

* dark-theme
  main

Commit on the branch

Now work exactly as you did this morning. In VS Code, change your body colors in css/style.css, save, check Live Server, then commit:

body {
    font-family: Arial, sans-serif;
    background-color: #0f172a;
    color: #e2e8f0;
}

git add css/style.css
git commit -m "Try a dark color scheme"

[dark-theme 742986d] Try a dark color scheme
 1 file changed, 2 insertions(+), 1 deletion(-)

Notice the commit output now says [dark-theme …] instead of [main …]. The commit landed on your branch.

Switch back: git switch main

git switch main

Switched to branch 'main'

Now look at Live Server. Your site is light again! Open style.css in VS Code: the dark colors are gone. They're not lost; they live on the dark-theme branch. Switch back with git switch dark-theme and they reappear. Try it a couple of times. This is the moment branches "click" for most people.

🤝 Merging a Branch Back

You love the dark theme. Time to bring it into main. Merging always works the same way: go to the branch you want to receive the changes, then merge the other branch into it.

git switch main
git merge dark-theme

Updating 9a988fb..742986d
Fast-forward
 css/style.css | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Check Live Server: main is dark now. That's it, you merged!

⏩ Fast-Forward vs. Merge Commit

Git merges in one of two ways, and it picks for you. You just need to recognize them.

Fast-forward: main didn't move

In the example above, nobody committed anything on main while you worked on dark-theme. So Git didn't need to combine anything. It just slid the main label forward to your branch's latest commit. That's why the output said Fast-forward. No new commit is created.

Merge commit: both branches moved

Now suppose you start an add-footer branch and commit a footer there, but before merging you switch back to main and commit a font change. Both lines have new commits, so Git has to combine them. It makes a special merge commit with two parents:

git switch main
git merge add-footer

A VS Code tab called MERGE_MSG opens with the message Merge branch 'add-footer'. That default is fine. Close the tab and Git finishes:

Merge made by the 'ort' strategy.
 index.html | 1 +
 1 file changed, 1 insertion(+)

('ort' is just the name of Git's merge engine. Older Git versions say 'recursive'. You can ignore it.)

Either way, the result is the same: main now contains the branch's work.

🗺️ Seeing Branches & Cleaning Up

Draw the history: git log --oneline --graph --all

Add --graph to draw the lines and --all to include every branch, not just the one you're on:

git log --oneline --graph --all

*   36ac9a0 Merge branch 'add-footer'
|\
| * 6fa0174 Add a footer to the home page
* | 1e78600 Switch body font to Georgia
|/
* 742986d Try a dark color scheme
* 9a988fb Revert "Rewrite about page intro"
...

Read it from the bottom up. Each * is a commit. Where the lines split, a branch started; where they join, it was merged. The dark-theme commit sits in a straight line, because it was a fast-forward. The footer work split off and joined back with a merge commit. (Remember: press q if the log opens in the pager.)

Delete a merged branch: git branch -d

Once a branch is merged, its commits are safely part of main, and the branch label is just clutter. Delete it:

git branch -d dark-theme

Deleted branch dark-theme (was 742986d).

The lowercase -d is the safe version: if the branch has commits that aren't merged yet, Git refuses and warns you that the branch is not fully merged. That's your safety net against deleting unfinished work. (It mentions an uppercase -D that forces the delete. Only use that for an experiment you truly want to throw away.)

💥 Merge Conflicts

Usually Git combines branches on its own, even when both changed the same file, as long as they changed different lines. But if both branches change the same line in different ways, Git can't know which one you want. So it stops and asks you. That's a merge conflict.

Causing a conflict on purpose

Here's the recipe. Both branches will change the h1 color in css/style.css:

1. Create a branch: git switch -c heading-color
2. In style.css, set the h1 color to purple (#7c3aed). Save and commit: git commit -am "Make headings purple"
3. Go back: git switch main
4. Change the same line to green (#059669). Save and commit: git commit -am "Make headings green"
5. Merge: git merge heading-color

This time Git stops:

Auto-merging css/style.css
CONFLICT (content): Merge conflict in css/style.css
Automatic merge failed; fix conflicts and then commit the result.

Take a breath and run git status. It tells you exactly where you are and what to do:

On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   css/style.css

no changes added to commit (use "git add" and/or "git commit -a")

Reading the conflict markers

Open css/style.css. Git has written both versions into the file, fenced off with markers:

h1 {
<<<<<<< HEAD
    color: #059669;
=======
    color: #7c3aed;
>>>>>>> heading-color
}

• <<<<<<< HEAD starts the version from the branch you're on (main). VS Code calls this the Current change.
• ======= divides the two versions.
• >>>>>>> heading-color ends the version from the branch you're merging in. VS Code calls this the Incoming change.

Your job: make the file look the way you want it to, and delete all three marker lines. You can keep one side, keep both, or write something new.

🧩 Resolving a Conflict

Option 1: The inline buttons

When VS Code opens a conflicted file, it highlights the two versions in different colors and shows a row of small clickable links just above the <<<<<<< line:

Accept Current Change | Accept Incoming Change | Accept Both Changes | Compare Changes

• Accept Current Change keeps main's green and removes the markers.
• Accept Incoming Change keeps the branch's purple and removes the markers.
• Accept Both Changes keeps both lines, one after the other. For two color values that isn't what you want (the second one wins in CSS), but it's perfect when both sides added something, like two new nav links.

Let's say you choose purple: click Accept Incoming Change. The file becomes:

h1 {
    color: #7c3aed;
}

You can also simply edit the text by hand: delete the lines you don't want plus the three markers. That works everywhere, in any editor.

Option 2: The merge editor

VS Code also has a three-pane merge editor. Open it with the Resolve in Merge Editor button at the bottom-right of the conflicted file (or from the file's entry under Merge Changes in the Source Control panel). The top panes show Incoming and Current side by side; the bottom pane is the Result. Tick the checkbox or Accept link on the side you want, look at the Result, then click Complete Merge. (Button labels can shift a little between VS Code versions.)

Finish the merge: git add + git commit

Save the file, check Live Server to make sure the page looks right, then tell Git the conflict is resolved by staging the file:

git add css/style.css
git status

On branch main
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

Changes to be committed:
	modified:   css/style.css

Now commit. Leave off -m: Git already wrote a message for you.

git commit

The MERGE_MSG tab opens with Merge branch 'heading-color'. Close the tab to finish:

[main 1088d56] Merge branch 'heading-color'

(In VS Code's Source Control panel you can instead click + on the file to stage it, then the Commit button.) Look at your graph:

*   1088d56 Merge branch 'heading-color'
|\
| * 5a219ae Make headings purple
* | bb98465 Make headings green
|/
*   36ac9a0 Merge branch 'add-footer'
...

🎉 You just resolved a merge conflict. Delete the branch with git branch -d heading-color and you're done.

git merge --abort

❓ Common Questions

🛠️ Hands-on Exercise

# Part A
git switch -c new-colors
# edit css/style.css in VS Code, save
git add css/style.css
git commit -m "Try a new color scheme"
git switch main
git merge new-colors          # "Fast-forward"
git branch -d new-colors

# Part B
git switch -c new-heading
# edit the h1 in index.html, save
git commit -am "Change heading to Sam's Photo Corner"
git switch main
# edit the SAME h1 line differently, save
git commit -am "Change heading to Welcome, Friends"
git merge new-heading         # CONFLICT (content): Merge conflict in index.html
git status
git merge --abort             # practice the escape hatch
git merge new-heading         # conflict again
# resolve in VS Code, remove all markers, save
git add index.html
git commit                    # close the MERGE_MSG tab
git log --oneline --graph --all
git branch -d new-heading

<body>
<<<<<<< HEAD
    <h1>Welcome, Friends</h1>
=======
    <h1>Sam's Photo Corner</h1>
>>>>>>> new-heading

📓 Learning Journal

Summary

📚 Additional Resources

• Pro Git — Basic Branching and Merging
• VS Code — Source Control (includes merge conflicts)
• Learn Git Branching (an interactive visual playground)
• Git Quick Reference (this site): the branching & merging commands on one page

🚀 What's Next?

So far everything lives on your own computer. In the next lesson you'll put your repository on GitHub: create an account and a repository, push your commits up, pull changes down, and clone a project. Your site's history will be backed up in the cloud and ready to share.