Git Kitchen: The Overcooked Codebase

A multiplayer role-playing game for learning Git collaboration, Pull Request hygiene, and surviving the chaos of a shared codebase.

---

Welcome to the Kitchen (Why Are We Here?)

Welcome to the Git Kitchen.

Before we write any code today, we need to talk about how modern software teams function. Imagine the client company is a massive, incredibly busy restaurant. Our software applications are the dishes we serve to thousands of hungry customers every day.

As Automation Testers, your job is vital: you write the automated recipes (test scripts) that ensure every single dish leaving our kitchen is perfect, safe, and up to standard.

The "One Giant Pot" Problem

But here is the problem: What happens when 20 different testers need to write, update, or fix those test recipes at the exact same time?

If everyone logs onto the same server and starts writing code in the same place, it's like 20 chefs crowding around one giant pot. Chef A adds salt for a login test. Chef B accidentally bumps the pot and spills in sugar for a checkout test. By the end of the day, the soup is ruined, the kitchen is on fire, and nobody knows whose fault it is. You would constantly be overwriting each other's work and breaking the test suite.

The Solution: Your Own Prep Station (Git)

To prevent total kitchen disasters, the software industry uses a system called Version Control—specifically, a tool called Git.

Git is the ultimate kitchen management system. Instead of everyone cooking in the same giant pot, Git gives every single tester their own isolated, private prep station.

At your Git prep station, you can chop, season, experiment, and totally ruin your local code... and it will never affect the restaurant's master menu! You are perfectly safe.

How the kitchen flows:

1. Prep Station (branch): You grab a copy of the master recipe book and take it to your private prep station to work on a new test setup.
2. Plating (commit): You frequently take snapshots of your dish as you cook so you never lose your progress.
3. Taste Test (Pull Request): When your test is flawlessly passing, you bring it up to the expo window and ask a Senior QA to taste-test your code.
4. The Master Menu (merge): Once approved, your recipe is officially folded into the team's master automation suite.

Why Are We Learning This?

We are learning Git because it is the industry standard for teamwork. It gives us:

• Safety: You can't accidentally delete your teammates' work.
• Traceability (The Receipt): If a perfectly good test suddenly breaks tomorrow, Git lets us look at the receipt and see exactly who changed the recipe and when.
• Collaboration: It lets us build a massive automation framework together without stepping on each other's toes.

🛒 Kitchen Prerequisites (What You Need Before We Start)

Before we start cooking, you'll need to make sure you have your basic kitchen utensils installed on your computer.

1. Git: The management system itself. (Download at git-scm.com)
2. A Code Editor: Your cutting board. We recommend VS Code (Download at code.visualstudio.com)
3. A GitHub Account: Your chef profile where our master menu lives.

Checking Your Setup: Not sure if you have everything? We've written a quick script that acts as a health inspector. Open your terminal (PowerShell for Windows, Terminal for Mac) and run:

• On Windows: .\verify-kitchen-setup.ps1
• On Mac/Linux: ./verify-kitchen-setup.sh

---

Service Schedule (Timeline)

• Service Begins (Kickoff): Right now! We're opening the kitchen together during this lunch hour to set up our prep stations.
• Service Ends (Deadline): Before the weekend. All test recipes must be cooked, reviewed, and officially merged into the master menu before we close shop for the week!

---

Things You'll Learn

By playing through Git Kitchen, you'll build real, hands-on experience mapping these kitchen workflows directly to your day-to-day work as an automation tester:

Git Skill	Kitchen Analogy	Automation Tester Reality	Where You Practice It
Cloning (git clone)	Getting a personal copy of the master recipe book	Downloading the team's master test automation framework (e.g., Cypress, Playwright) to your laptop	Round 1 — Prep Station
Branching (git branch)	Setting up your own isolated prep station to experiment	Creating a safe space to write a new checkout test without breaking the nightly regression suite	Round 1 — Prep Station
Committing (git commit)	Plating your dish and writing down what you changed	Saving a snapshot of your test script locally once you get it passing on your machine	Round 2 — On the Pass
Pushing (git push)	Bringing your finished dish from your station to the pass	Backing up your finished test script from your laptop to the team's repository (like GitHub or GitLab)	Round 2 — On the Pass
Pull Requests (PR)	Asking the Head Chef to taste-test before it goes on the menu	Asking a Senior QA to review your code before it gets added to the CI/CD pipeline	Round 2 — On the Pass
Fetching/Pulling (git pull)	Hearing the Chef call out menu updates so you stay in sync	Downloading new page objects or helper functions a teammate just wrote so your own tests don't fail	Round 3 — Mise en Place
Merging (git merge)	The Head Chef officially adding your recipe to the main menu	The team officially adding your newly written test into the master regression suite	Round 3 — Mise en Place
Merge Conflicts	Two cooks trying to add different salt amounts to the same soup!	You and another tester both tried to update the exact same line in login-page-object.js	Round 4 — Fire!

---

Roles

Head Chef (Maintainer)

The Head Chef owns the repository and is responsible for keeping the kitchen running smoothly. Their responsibilities include:

• Protecting the main branch (no direct pushes!)
• Reviewing and merging Pull Requests
• Resolving escalated merge conflicts
• Enforcing the Health Inspector Checklist (see PR template)

Line Cooks (Contributors)

Line Cooks are the contributors. Each cook works on their own branch and submits Pull Requests to add recipes to the menu. Their responsibilities include:

• Creating a new branch for every recipe
• Writing clear, descriptive commit messages
• Submitting one recipe per Pull Request
• Reviewing a fellow cook's PR before your own gets merged

---

Repository Structure

git-hygiene/
├── README.md                        ← You are here (the rulebook)
├── menu.md                          ← The shared menu (main dish)
├── cheat-sheet.md                   ← Quick Git command reference
├── recipes/                         ← Where your recipe files live
│   └── .gitkeep
└── .github/
    └── PULL_REQUEST_TEMPLATE.md     ← Health Inspector Checklist

---

Gameplay: 4 Rounds

---

Round 1 — Prep Station (Clone & Branch)

Get your workstation ready before service begins.

Analogy: You can't cook without a recipe book or a cutting board. git clone gets you a copy of the kitchen's master recipe book, and git branch sets up your own personal prep station where you won't bump into anyone else.

Goal: Set up your local development environment.

Steps:

1. Clone this repository to your local machine:

   git clone https://github.com/<head-chef-username>/git-hygiene.git
   cd git-hygiene

2. Confirm your remote is set up correctly:

   git remote -v

3. Create a new branch named after your recipe (use lowercase and hyphens):

   git checkout -b recipe/your-recipe-name

Round 1 Complete when every cook has a local branch ready.

---

Round 2 — On the Pass (Commit & Pull Requests)

Cook your dish and send it up to the pass for review.

Analogy: As you cook, git commit is like taking a snapshot of your progress. When it's perfect, git push brings it to the expo window, and a Pull Request is when you ring the bell and ask the Head Chef to taste-test your work before serving it to customers.

Goal: Add a recipe file and open a Pull Request.

Steps:

1. Create a new Markdown file for your recipe inside the recipes/ folder:

   # Example: recipes/classic-carbonara.md

2. Write your recipe using this template:

   # Recipe Name
   
   **Prep Time:** 15 minutes
   **Cook Time:** 30 minutes
   **Serves:** 2–4
   
   ## Ingredients
   - 200g ingredient one
   - 1 cup ingredient two
   
   ## Instructions
   1. Step one
   2. Step two

   Tip: Always include units for times (e.g. 15 minutes) and a number or range for servings (e.g. 2–4).

3. Stage and commit your file:

   git add recipes/your-recipe-name.md
   git commit -m "feat: add classic carbonara recipe"

4. Push your branch to the repository:

   git push origin recipe/your-recipe-name

5. Open a Pull Request from your branch to the main branch.
6. Fill out the Health Inspector Checklist in the PR description completely.
7. Request a review from another Line Cook.

Round 2 Complete when every cook has an open PR with the checklist filled out.

---

Round 3 — Mise en Place (Fetch & Pull)

Keep your workstation in sync while other cooks are working.

Analogy: While you were chopping onions, the Head Chef added 3 new dishes to the shared menu. git fetch and git pull are like checking the whiteboard to make sure you know what's going on before you try to serve your own dish.

Goal: Practice fetching and pulling upstream changes without overwriting your work.

Steps:

1. While your PR is under review, fetch the latest changes from origin:

   git fetch origin

2. Switch to your local main branch:

   git checkout main

3. Merge the latest changes into your local main:

   git merge origin/main

4. Switch back to your recipe branch and rebase it on the updated main:

   git checkout recipe/your-recipe-name
   git rebase main

5. Force-push the rebased branch (since history was rewritten):

   git push origin recipe/your-recipe-name --force-with-lease

Tip: git fetch downloads changes without applying them. git pull fetches and merges in one step. Prefer fetch + rebase to keep a clean history.

Round 3 Complete when every cook's branch is up to date with the latest main.

---

Round 4 — Fire! (Merge Conflicts)

Two cooks edited the same line. Now it's chaos. Resolve it.

Analogy: A merge conflict happens when two cooks try to edit the exact same line of a recipe at the precise same time. Git won't guess who is right—it stops everything and asks you (the humans) to decide which version makes it into the final dish!

Goal: Intentionally create and resolve a merge conflict in menu.md.

Steps:

1. The Head Chef will merge one PR into main first.
2. All other cooks must now fetch and pull the updated main:

   git fetch origin
   git rebase origin/main

3. If Git reports a merge conflict in menu.md, open the file and look for conflict markers:

   <<<<<<< HEAD
   Your version of the line
   =======
   The other cook's version
   >>>>>>> origin/main
   

4. Edit the file to resolve the conflict — keep both contributions if possible!
5. Stage the resolved file and continue the rebase:

   git add menu.md
   git rebase --continue

6. Push the resolved branch and update your PR.

Tip: Communication is the best merge conflict prevention. Use PR comments to coordinate who is editing which lines.

Round 4 Complete when all PRs are merged and menu.md lists every cook's recipe without conflicts.

---

Winning Condition

The kitchen wins together when:

• Every Line Cook has a merged PR
• menu.md lists all recipes with no duplicate entries
• All recipes are in the recipes/ folder
• No one pushed directly to main
• Every PR had at least one approval

---

Resources

• cheat-sheet.md — Quick Git command reference
• menu.md — The shared menu
• .github/PULL_REQUEST_TEMPLATE.md — Health Inspector Checklist
• Official Git Docs
• GitHub Docs: About pull requests