Gitea Workflow: Peer Review, Iteration & Git History Surgery

What You'll Do Today

Today you build on every Git skill from the Pro Local Dev practicum, then add four new ones that professional teams use constantly: publishing to a remote, iterating on peer feedback, discarding unwanted changes, and surgically editing your project's history with git revert and git cherry-pick.

Learning Objectives

• 1. Create a Gitea account and a public repo named my_first_repo_lastname.
• 2. Build a small HTML / CSS / JS splash page (AI assistance permitted).
• 3. Push the page to the classroom Gitea server and view it live on a public URL.
• 4. Exchange peer feedback with another student and use that feedback to drive a real iteration loop, committing each change you like.
• 5. Practice discarding uncommitted changes you don't want (git restore).
• 6. Practice rolling back a specific past commit (git revert) and rebuilding a project from chosen commits (git cherry-pick).
• 7. Submit a deliverable with screenshots, peer-feedback notes, and a written reflection.

Pacing — Two Class Meetings, 360 Minutes Total

You have two full 180-minute class periods to complete this project. The deliverable is due at the end of Class 2. The blocks below are guideposts, not stopwatches — you'll have time to think, experiment, and revisit anything that didn't click the first time. If you finish a block early, use the extra minutes to polish your splash page, give better feedback, or start the Day 2 work early.

Class 1 — 180 minutes (Building, Publishing, Peer Review)

• Block 0 — Warm-Up: What Did You Already Learn? ~15 min
• Block 1 — Tour the Server, Make Your Account & Repo ~25 min
• Block 2 — Build & Push Your Splash Page ~60 min
• Block 3 — Peer Review & First Iteration Loop ~60 min
• Class 1 Wrap-Up — Commit-message audit & what to expect Day 2 ~20 min

Class 2 — 180 minutes (History Surgery, Experimentation, Submit)

• Block 4 — Discard Uncommitted Changes ~35 min
• Block 5 — History Surgery: Revert & Cherry-Pick ~60 min
• Block 6 — Open Experimentation Lab (choose your own) ~45 min
• Block 7 — Deliverable Assembly & Final Reflection ~40 min

Block 0 — Warm-Up: What Did You Already Learn?~15 min

1 Block 1 — Tour the Server, Make Your Account & Repo~25 min

Step 1.1 — Register on the classroom Gitea

1. Open a browser to http://10.12.6.236:3000/.
2. Click Register.
3. Use a username you'd be okay seeing in a URL (it'll appear in your repo's public address).
4. Use your school email so password resets work.
5. Sign in.

Step 1.2 — Create a public repository

1. In Gitea, click the + in the top-right → New Repository.
2. Name it exactly: my_first_repo_lastname (use your real last name, lowercase, no spaces, e.g. my_first_repo_johnston).
3. Set Visibility to Public. Public is required so the nginx server can serve your page on the web.
4. Leave Initialize Repository unchecked.
5. Click Create Repository.

Gitea will show a "quick setup" page with a clone URL that looks like:

http://10.12.6.236:3000/your-username/my_first_repo_lastname.git

Copy that URL.

2 Block 2 — Build & Push Your Splash Page~60 min

Step 2.1 — Clone the empty remote

1. Open Git Bash.
2. Move to (or create) a non-OneDrive folder:

   mkdir -p /c/Users/$USER/pit-projects
   cd /c/Users/$USER/pit-projects
   pwd

   The path you print should not contain the word "OneDrive." If it does, raise your hand.
3. Clone the empty remote (replace your username and last name):

   git clone http://10.12.6.236:3000/your-username/my_first_repo_lastname.git
   cd my_first_repo_lastname

4. Confirm the remote is wired up:

   git remote -v

   You should see origin pointing at the Pi.

Step 2.2 — Configure your Git identity (if you haven't already)

If you already did this in the Pro Local Dev practicum on this same machine, skip this step. Otherwise:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Use the same email as your Gitea account so commits get linked to your profile.

Step 2.3 — Build a splash page (HTML + CSS + JS)

Open the folder in VS Code:

code .

Create a file named exactly index.html. You may use the AI of your choice (ChatGPT, Claude, Gemini, Copilot) for the first draft. A starter prompt:

Generate a single-file index.html for a personal splash page.
Requirements:
  - My name as a big heading
  - A short bio paragraph (2-3 sentences)
  - A list of 3 things I'm working on this semester
  - Inline <style> with a clean color scheme (no external CSS)
  - Inline <script> that does ONE small thing on load
    (e.g. shows the current date, or a friendly console.log greeting)
  - No external scripts, no tracker pixels, no analytics

Paste the generated HTML into index.html, save, and open the file in your browser to make sure it renders before you push.

Step 2.4 — Add a .gitignore

Create a file named exactly .gitignore in your repo with at least:

# OS and editor junk
.DS_Store
Thumbs.db
desktop.ini
.vscode/

# Secrets
.env
*.key
secrets.json

Step 2.5 — Stage, commit, and PUSH

git status
git add .
git commit -m "Add initial splash page"
git push

Read git status before you stage. Only .gitignore and index.html should be listed.

Step 2.6 — See your page live on the public URL

1. Refresh your Gitea repo page — you should now see index.html in the file list.
2. Open the classroom web host in a new tab:

   http://10.12.6.236/

   You'll land on an index page that lists every public repo on the server. Find your username, click in, then click your repo — your splash page will load. The Pi's nginx is serving it like a real web host.
3. Once your page loads, look at the URL in the browser bar — it'll look like http://10.12.6.236/sites/your-username/my_first_repo_lastname/. That's the link to share with your partner in Block 3.

3 Block 3 — Peer Review & First Iteration Loop~60 min

Step 3.1 — Swap public URLs

Easiest way: both you and your partner open http://10.12.6.236/, navigate into your own repo, then copy the URL from the browser bar and share it. Or, if you prefer, just tell your partner your Gitea username — they can find your repo from the index at http://10.12.6.236/ themselves.

Step 3.2 — Write feedback for your partner

Open your partner's page in a browser. In a text doc, write them three specific pieces of feedback. "It's good" is not feedback. Examples of good feedback:

• "The contrast between the gray text and the white background is hard to read — consider darker text or a softer background."
• "Your bio mentions you like robotics but doesn't say what you've built — one concrete example would make it land harder."
• "The console.log greeting is cute but only shows up if I open dev tools. Could you make the greeting visible on the page itself?"

Send your three pieces of feedback to your partner (DM, paste in a doc you share, whatever method your class uses).

Step 3.3 — Iterate. Commit each improvement.

Pick at least two pieces of feedback you got. For each one:

1. Edit index.html in VS Code to address that piece of feedback.
2. Save the file.
3. Reload your local file in the browser to check it.
4. Once you're happy with the change:

   git status
   git add index.html
   git commit -m "Fix low-contrast text per peer feedback"
   git push

5. Reload the public URL — your partner can see the improvement.

Class 1 Wrap-Up~20 min

End-of-Day-1 checklist

• Run git status. It must say "nothing to commit, working tree clean." If not, decide: commit it, or discard it with git restore (covered tomorrow).
• Run git log --oneline. Re-read each commit message. Are they imperative, specific, and ~50 characters? Note any you'd write differently next time.
• Confirm your public URL still loads in a fresh browser tab.
• Add a short note to your draft deliverable: which feedback you've already acted on, what you might still want to change tomorrow.
• If a partner is absent on Day 2, you can do their peer feedback round asynchronously by leaving comments in a shared doc — flag this with the teacher today, not tomorrow.

Heads up for Day 2: tomorrow we work entirely inside Git history — discarding uncommitted changes, reverting a published commit, and cherry-picking a specific commit back. We'll also have an Open Experimentation Lab where you choose your own Git adventure.

4 Block 4 — Discard Uncommitted Changes~35 min

Step 4.1 — Confirm you're at a clean baseline

git status

You should see "nothing to commit, working tree clean." If you see anything else, commit and push it before continuing — we want this experiment to start from a known good state.

Step 4.2 — Make a mess on purpose

Open index.html in VS Code and intentionally make it worse:

• Change the body background color to hotpink.
• Change your heading text to all caps and add 10 exclamation points.
• Delete a section of your bio.
• Add a paragraph that says <p>I LOVE GIT SO MUCH</p> three times in a row.

Save the file (Ctrl+S). Open it in the browser locally to see the mess.

Step 4.3 — Look at what Git sees

git status
git diff index.html

git diff shows you exactly what changed since the last commit — red lines are removed, green lines are added.

Step 4.4 — Discard everything since the last commit

git restore index.html

That's it. Reload the browser — your splash page is back to the way it was at the last commit.

To verify:

git status   # should say "nothing to commit, working tree clean"
git diff     # should print nothing

5 Block 5 — History Surgery: Revert & Cherry-Pick~60 min

Step 5.1 — Set up the practice file with 4 commits

Inside your repo (same folder as index.html), do each step below in order, committing after each one. This gives us a history we can perform surgery on.

Commit A — Create a new file practice.html with this exact content:

<!DOCTYPE html>
<html>
<head>
  <style>
    body { background: lightyellow; font-family: sans-serif; }
  </style>
</head>
<body>
  <p>This is a practice file for Git history surgery.</p>
</body>
</html>

Then:

git add practice.html
git commit -m "A: Create practice file with yellow background"

Commit B — Add an <h1> heading inside <body>, above the existing paragraph:

<h1>Welcome to the Practice Page</h1>

Save, then:

git add practice.html
git commit -m "B: Add welcome heading"

Commit C (intentionally ugly) — Change the body background from lightyellow to purple:

body { background: purple; font-family: sans-serif; }

Save, then:

git add practice.html
git commit -m "C: Change background to purple"

Commit D — Add an h1 rule and a keyframes rule so the heading bounces. Replace the <style> block with:

<style>
  body { background: purple; font-family: sans-serif; }
  h1 { animation: bounce 1s infinite alternate; }
  @keyframes bounce {
    from { transform: translateY(0); }
    to   { transform: translateY(-10px); }
  }
</style>

Save, then:

git add practice.html
git commit -m "D: Add bounce animation to heading"
git push

Check the history:

git log --oneline

You should see D, C, B, A (newest first), each with a short hash. Open practice.html in a browser — you'll see a purple page (ugly!) with a bouncing heading.

Step 5.2 — git revert: undo a specific past commit, keep everything else

The purple background (commit C) is bad. The bounce animation (commit D) is good. We want to undo C while keeping D.

Copy the short hash of commit C from git log --oneline. Then:

git revert <hash-of-C> --no-edit
git push

Look at the file in the browser — the background is back to yellow, and the heading is still bouncing. Run git log --oneline again. You'll see a new commit at the top — something like "Revert "C: Change background to purple"". The original C is still in history; the new commit just undoes it.

Step 5.3 — git cherry-pick: grab a specific commit by hash

Cherry-pick is the inverse problem: instead of taking a commit out, you take a commit and apply it onto your current state.

Let's simulate a realistic case. Pretend we want to make a small detour: temporarily remove the bounce animation, then later re-apply only commit D's changes by cherry-picking.

Step 5.3a — Undo commit D so we can practice picking it back up. We'll use revert again:

git log --oneline   # find the hash of "D: Add bounce animation to heading"
git revert <hash-of-D> --no-edit
git push

Reload the page. The bouncing should stop — the heading sits still.

Step 5.3b — Now cherry-pick the original commit D back. Its changes were good; we just want them re-applied:

git log --oneline   # find the hash of "D: Add bounce animation to heading" (the ORIGINAL D, not its revert)
git cherry-pick <hash-of-D>
git push

Reload the page — the heading is bouncing again. Run git log --oneline one more time: you should see the cherry-picked commit at the top with the same message as the original D.

When would you use each?

6 Block 6 — Open Experimentation Lab (Choose Your Own)~45 min

Experiment menu

git checkout -b feature-fancy-button   # create + switch to a new branch
# edit practice.html, add a button
git add practice.html
git commit -m "Add fancy button"
git checkout main                       # switch back to main
git merge feature-fancy-button          # bring the branch's commits in
git push

git add practice.html
git commit                              # finishes the merge

git stash                # tucks all uncommitted changes away
git status               # working tree clean
# ...do the other thing, commit it...
git stash pop            # bring your half-done work back

git reflog               # shows EVERY HEAD movement, including the "lost" commit
git reset --hard <hash>  # bring it back

cd /c/Users/$USER/pit-projects
git clone http://10.12.6.236:3000/your-username/my_first_repo_lastname.git my_first_repo_lastname_2
# from the original folder: commit + push something
cd my_first_repo_lastname_2
git pull                  # the change you just pushed appears here

git diff <older-hash> <newer-hash> -- practice.html

git blame practice.html

Block 7 — Deliverable & Final Reflection~40 min

Required sections of the PDF

Submit a single PDF named LASTNAME_FIRSTNAME_GiteaWorkflow.pdf with these sections, in this order:

1. Cover page — name, date(s), period, lesson title.
2. Warm-up & Day 1 closeout reflections — the Block 0 prompts (what a commit is, why committing beats saving, most confusing thing prior) AND the short Class 1 wrap-up reflection (smoothest part, hardest part, what to remember tomorrow).
3. Gitea evidence — Checkpoint #1: your repo page on Gitea showing the public badge and repo name.
4. Splash page evidence — Checkpoint #2: your splash page rendered at the public URL (URL bar visible).
5. Peer feedback log — Checkpoint #3: the full text of the 3 pieces of feedback your partner gave you, followed by a short paragraph (3–4 sentences) describing which two you acted on and what you actually changed.
6. Iteration history — Checkpoint #4: git log --oneline screenshot showing your initial commit plus your peer-feedback commits.
7. Discard experiment — Checkpoint #5: before/after screenshots from Block 4, plus your one-sentence caption.
8. History surgery — Checkpoints #6 and #7: git log screenshots after the revert and after the cherry-pick, plus your mini-reflection comparing git restore and git revert.
9. Experiments — Checkpoint #8: at least two experiments from Block 6's menu (or your own). For each: which letter (or "self-proposed"), screenshot / terminal block of what you did, and 2–3 sentences on what happened and what you'd use it for in real work.
10. Final reflection — one well-developed paragraph (6–8 sentences). Address all of:
    • Which of the Git operations you practiced (restore, revert, cherry-pick, plus the plain commit/push cycle, plus whatever you tried in Block 6) felt most useful and why?
    • What surprised you about getting public peer feedback on your code?
    • Where outside of programming might the "version everything, never overwrite" mindset matter to your future career?

Rubric (100 points)

Quick Command Reference

# --- Everyday loop ---
git status                          # what is staged / modified / untracked
git diff                            # what changed since last commit
git add <file>                       # stage one file
git add .                           # stage everything (use after reading git status!)
git commit -m "Imperative message"  # snapshot the staged changes
git push                            # send commits to the remote

# --- Get a remote onto your machine ---
git clone <url>                     # copy a remote repo locally
git remote -v                       # show where origin points

# --- History surgery ---
git log --oneline                   # short history
git restore <file>                  # throw away uncommitted edits to file
git revert <hash> --no-edit         # undo a past commit by adding a new "undo" commit
git cherry-pick <hash>              # apply a specific past commit on top of HEAD

If Something Doesn't Work

• "fatal: not a git repository" — you're not inside the repo folder. cd my_first_repo_lastname first.
• "Permission denied" / "authentication failed" — your Git identity email doesn't match your Gitea account, or you cancelled the browser authorize step. Re-run git push and complete the browser prompt.
• "index.lock" / "unable to write" errors — you're inside OneDrive. Move the repo to a non-synced location (e.g. C:\Users\you\pit-projects) and clone again.
• Cherry-pick or revert says "conflict" — two changes touched the same line. Open the file, look for the <<<<<<< markers, edit to the version you want, then git add <file> and git cherry-pick --continue (or git revert --continue).
• Can't reach 10.12.6.236 — cellular or guest network. Connect to classroom Wi-Fi.
• Public URL shows 404 — check that the file is named exactly index.html (lowercase, no hidden .txt extension) and that the repo is set to Public on Gitea.
• Page loads but is blank — the AI may have given you incomplete HTML. View source; you should see <html>, <head>, <body>.

Document any error you hit — exact text, what you tried, what fixed it. That's the report you'd submit on the job.