Tailwind Takeoff ‐ Git Collaboration

Opening Task (15 Minutes)

• Scholars open Schoology and complete a short warm-up quiz covering Git concepts from prior lessons: staging vs. committing, git status, git log, and the difference between a local and remote repository
• While scholars work, instructor circulates and notes who may need extra support during today’s guided practice
• Once time is called, a randomly selected scholar facilitates a brief review of each question — instructor corrects misconceptions before moving on
• Bridge to today’s lesson: “So far you’ve all been working on your own repos. Today we’re working in a shared repo as a team. What new problems do you think that creates?” Take 2–3 responses, then transition to the next section

Git Branching & Pull Requests: Concept + Live Demo (30 Minutes)

Open with the framing question to the class: “If all three of you are editing the same file at the same time, what happens?” Let two or three students respond, then use that tension to motivate the branch workflow.

Introduce the core ideas while projecting the lesson slides:

• main is sacred — it’s the stable, shared version of the project. No one commits directly to it
• Branches are isolated workspaces — each team member forks off from main to build their feature without affecting anyone else
• Pull requests are proposals — when your work is ready, you open a PR to request that your branch be merged into main
• Code review is a gate — a teammate reviews the changes line by line and either approves or requests revisions before the merge happens

Key talking points while projecting the branch diagram:

• Every branch forks from main at a specific commit — it doesn’t automatically receive changes others make on different branches
• A PR is a conversation: it shows exactly what changed, line by line, in the diff view
• Merging closes the PR and integrates the work into main for the whole team

Check-for-understanding questions:

• “If Student A merges their branch before Student B finishes theirs, does Student B automatically get Student A’s changes?”
• “What’s the difference between a branch and a commit?”

Demonstrate the full workflow from the instructor machine, narrating every command as you type it.

Step 1 — Clone and orient (already done for students, but show it):

git clone <repo-url>
cd <project-folder>

Step 2 — Create and switch to a feature branch:

git checkout -b feature/team-page

Explain: -b creates the branch and immediately checks it out. The branch name should describe what you’re building.

Step 3 — Create the new page:

touch pages/team.html

Add a minimal HTML skeleton with a visible <h1> — just enough to produce a real diff.

Step 4 — Stage, commit, and push the branch:

git add pages/team.html
git commit -m "Add team page with placeholder content"
git push origin feature/team-page

Point out: git push origin feature/team-page — the branch name goes at the end. This is different from their personal projects where they always pushed to main.

Step 5 — Open the pull request on GitHub (switch to browser):

• Navigate to the repo on GitHub
• GitHub will display a banner: “feature/team-page had recent pushes — Compare & pull request” — click it
• Walk through the PR form: title, description, the diff view at the bottom
• Assign a reviewer (pick a student volunteer)
• Submit the PR — do not merge yet

Instructor note: Leave this PR open. You will return to it during the Pull Requests & Peer Review section to demo the review interface.

Guided Practice: Each Student Creates a Branch and Page (40 Minutes)

Each team must decide who builds which page before anyone runs a command. Every team member needs a unique branch and a unique file. Suggest this division — teams can adjust:

Remind scholars: coordinate your page names with your team before running a single command. Two people creating the same file on different branches will produce a merge conflict.

Post these steps somewhere visible (whiteboard or shared screen) and have students work through them independently:

# 1. Make sure you're starting from an up-to-date main
git checkout main
git pull origin main

# 2. Create your feature branch
git checkout -b feature/your-page-name

# 3. Create your HTML file in the pages/ folder
# (use your code editor — create the file there)

# 4. Build a basic HTML page
# At minimum: doctype, html, head, body, an h1 with your page name

# 5. Stage and commit
git add pages/your-page-name.html
git commit -m "Add [page name] page"

# 6. Push your branch to GitHub
git push origin feature/your-page-name

Circulate and watch for these common issues:

• Student forgets to git pull before branching — their branch may be behind if a teammate already merged. Have them pull and re-branch
• Student accidentally commits to main — walk them through git reset or have them branch from where they are now
• Student pushes but can’t find the branch on GitHub — almost always a typo in the branch name; check with git branch -a and re-push

Before moving on, every student should be able to answer yes to both:

• “Is your branch visible on GitHub under the Branches tab?”
• “Does your commit show up in the branch’s commit history?”

Break (10 Minutes)

Pull Requests & Peer Review (25 Minutes)

Have all students open their PRs on GitHub now. Walk the class through the PR form fields one more time from the projector:

• Title — short, describes the change (e.g., “Add about page”)
• Description — what was added and any notes for the reviewer
• Reviewer — assign one teammate (not yourself)

Each student assigns a different teammate as reviewer. With three-person teams, rotate the assignments:

• Student A reviews Student B’s PR
• Student B reviews Student C’s PR
• Student C reviews Student A’s PR

Return to the PR opened during the demo. Show students the review interface:

• Click the Files changed tab — this is the diff view
• Click the + icon on a specific line to leave an inline comment
• Use the Review changes button to submit: Approve, Comment, or Request changes

Emphasize the goal of a code review: not to criticize, but to catch issues before they reach main. Things to look for in today’s review:

• Does the file live inside pages/?
• Is the HTML valid — proper doctype, <head>, <body>?
• Does the page actually render something visible (at minimum an <h1>)?

Students conduct their reviews. Each reviewer must:

1. Open the Files changed tab and inspect the diff
2. Leave at least one inline comment on the file
3. Submit a formal review — Approve or Request changes

Circulate and prompt reviewers who are clicking Approve without engaging: “What does the page look like? Click the file and read through the structure before you approve.”

Vite & npm Introduction (20 Minutes)

Frame clearly before showing any commands:

“Right now each of your HTML files is separate. Eventually we’re going to use Tailwind CSS to style everything — but Tailwind isn’t a file you just link to. It needs to be processed and bundled. That’s what Vite does. Think of Vite as the engine that takes all of your source files, connects them together, and serves them as one working website. npm is the package manager — it’s how we install Vite and Tailwind in the first place.”

Key vocabulary to introduce — no deep dive, just one sentence each:

Show from the instructor machine, then have students follow along simultaneously:

# Install all dependencies listed in package.json
# Only needed once per machine, or after a fresh clone
npm install

# Start the dev server
npm run dev

Vite will output something like:

  VITE v5.x.x  ready in 300ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: http://192.168.x.x:5173/

Open http://localhost:5173 in the browser and show the site live. Make a small visible change to index.html (e.g., change a heading text) and save — point out that the browser updates instantly without a manual refresh. Name this: “That’s called hot module replacement — HMR. We’ll learn more about how it works in a later unit. For now just know it’s one of the things that makes Vite useful.”

Tell students explicitly what they don’t need to understand yet:

“You don’t need to understand how Vite is configured. For now: npm install once when you clone, and npm run dev every time you want to work on the project.”

Students open their terminals and run:

npm install
npm run dev

They should see index.html loading at localhost:5173. Circulate and help anyone who hits errors. Most common issues:

• Running npm run dev from the wrong directory — must be the project root where package.json lives
• Node not installed — have a fallback plan ready; if this affects multiple students, pair them with a neighbor while you troubleshoot

Merge, Preview & Exit Ticket (10 Minutes)

Once a PR has been approved by a reviewer, the author merges it:

1. Go to the PR on GitHub
2. Click Merge pull request → Confirm merge
3. Delete the remote branch after merging (GitHub prompts this)
4. Clean up locally:

git checkout main
git pull origin main
git branch -d feature/your-page-name

Walk through this on the projector with the demo PR first, then have each student merge their own once their reviewer has approved.

If a PR has not been reviewed yet, that team waits. Reinforce this as a professional norm: nothing merges without a review.

After all merges are complete, have one student per team navigate to localhost:5173/pages/about.html (or whichever pages were created) in the dev server to confirm all pages are present and rendering.

Students submit written responses in Schoology before leaving:

1. “Why did we use branches instead of editing files directly on main?”
2. “What is the purpose of a pull request review — what problem does it solve?”
3. “What command do you run to start the Vite dev server, and where do you run it from?”

Common Issues & Instructor Notes