Meet Sandpiper
Topic 03

Meet Sandpiper

Foundations

Ideas stick when they have somewhere to live. Reading about branches in the abstract is like reading about swimming: the words go in, nothing sticks, and the first real attempt is still the first real attempt.

So for the rest of this book you are building Sandpiper — a small website for a neighbourhood birdwatching club. Every command you learn, you run against it. Every mistake in this book happens to it. By Chapter 9 it is a real repository with a real history, and it is the first thing you could show someone.

The project

Sandpiper is a handful of files, the sort anyone learning web development writes in their first month. The club meets on the first Thursday of every month, the site lists the meeting time, and members send in photographs of what they have seen.

Five names appear again and again in this book, always spelled the same way. index.html is the home page and exists from the start. style.css arrives in Chapter 2. sightings.js, the little script that lists recent bird sightings, arrives in Chapter 3. A notes/ folder shows up in Chapter 5, and it is where the first real accident happens. README.md, the page anyone visiting the project reads first, arrives in Chapter 9.

The Sandpiper folder, and when each part arrives
sandpiper/
the project folder · Chapter 1
index.html
the home page · Chapter 1
style.css
how the page looks · Chapter 2
sightings.js
the recent-sightings list · Chapter 3
notes/
local notes, mostly private · Chapter 5
README.md
what visitors read first · Chapter 9

Who is involved

You are. The book speaks to you in the second person and assumes your hands are on the keyboard, because that is the only way this particular skill arrives.

From Chapter 7 there is one other person: Theo, a classmate from the same coding course, who offers to help with the site. Theo is competent, friendly, and not a cautionary tale. He exists because merge conflicts, pull requests and code review all need a second pair of hands to be anything other than theoretical. Nobody else appears. Two people is enough to teach everything this book teaches about working together.

Why a website

Three reasons, and none of them is that websites are important. First, it is what most people are building when they first meet Git. Second, the files are plain text, so a change is something you can read: one line removed, one line added. Third, two people editing the same page is the most natural collision in the world, and it is exactly the collision Chapter 6 teaches you to resolve.

You do not need to know HTML to follow any of this. Git never looks inside your files and neither will we, beyond "this line changed". The files could be recipes or a novel and every command would behave identically.

What you need at the keyboard

A folder called sandpiper with a file in it, and whatever text editor you already use. That is all for now. If you would rather follow along with your own project instead, everything transfers — just be aware that the examples build on each other, and swapping projects halfway through is where people lose the thread.

Git itself is not installed yet, and there is one more thing to meet before it is: the window where you will be typing.

Common Confusions
  • "This is a toy project, so the lessons will be toy lessons." The size is small; the situations are not. Every conflict, accident and recovery in this book is one that happens on real projects in someone's first month, usually at the worst moment.
  • "I need to know HTML and CSS to follow along." No. Git treats every file as lines of text and never looks at what they mean. If you can save a file, you can do everything in this book.
  • "I should use my own project instead, to save time." You can, and nothing is wasted. Just remember that Chapter 8's conflict is the same file Chapter 6 already taught you to fix — that continuity is doing real work.
  • "Theo is a real person I need to coordinate with." Theo is fictional. Where a topic needs two people, you can play both sides with two folders on one machine, and Chapter 7 shows exactly how.
Why It Matters
  • A fixed example is what lets a later chapter say "the same conflict as before, now with somebody waiting" instead of introducing a whole new situation. The examples accumulate rather than resetting.
  • Concrete filenames make every command in this book something you can type rather than something you have to translate first.

Knowledge Check

Why does this book use one running project rather than a fresh example per chapter?

  • So that later examples build on situations you have already worked through yourself
  • Because Git can only track one project at a time on a single computer
  • Because a website is the only kind of project that Git is designed to handle
  • Because switching projects would require reinstalling Git with different settings

What does Git actually look at inside index.html?

  • The lines of text, so it can say which ones were added or removed
  • The HTML structure, so it can check the page is valid before committing
  • Nothing at all, because Git only records file names and their sizes
  • The images and styling, so it can warn you when the page will look wrong

When does Theo appear, and what is he for?

  • From Chapter 7, to make conflicts, pull requests and review involve a real second person
  • From Chapter 1, as the more experienced developer who reviews all of your work
  • He never appears; he is only mentioned as a hypothetical example of a teammate
  • In the final chapter, as the person who takes the project over when you finish

You got correct