Project Brief — Collaborate on a Test Automation Repo Using Git/GitHub

You've reached the capstone. Five chapters of fundamentals, branching, remotes, day-to-day commands, and project hygiene — now stitched into one end-to-end project. The point isn't to learn anything new; it's to prove to yourself that you can run the workflow without a tutorial open in another tab. A QA engineer who's done this once is functionally fluent in Git. By the end of these three lessons, you will be that person.

The scenario

Pretend you've just started at Acme Tools, a small SaaS company. Your manager hands you a laptop and the URL of the team's Cypress test repo. The team has five existing tests for a todo application, a cypress.config.ts, a sensible .gitignore, and a few fixtures. Your job for the rest of the week:

1. Get the repo running on your laptop.
2. Add three new test cases to cover scenarios the team is missing.
3. Update .gitignore to handle a new artefact folder a tool started writing.
4. Survive a merge conflict when someone else edits the config you're editing.
5. Open a pull request with a description that wouldn't embarrass you.
6. Set up a pre-push hook so smoke tests run before code leaves your laptop.
7. Use git log, diff, and blame to answer three "what changed?" questions about the repo's history.

Every chapter you've worked through contributes to one of those steps. There is no new Git command to learn for this project — only commands you've already practised.

What "the team's repo" looks like

You don't actually need a real team. The capstone works just as well in a repo you create yourself, simulating a teammate by editing on a second branch. If you do have access to a real test repo, even better — use it. Two practical options:

Option A — your own GitHub repo (recommended for first-timers). Create a public repo on GitHub called git-for-qa-capstone. Initialise it with a README and a Node .gitignore. Add the minimum scaffolding: npm init -y, npm install --save-dev cypress, a starter cypress.config.ts, three placeholder test files in cypress/e2e/, two fixtures in cypress/fixtures/. Commit the lot to main. You're now the maintainer of "the team's repo."

Option B — a real test repo. If your team already has a Cypress or Playwright suite and you have permission, use it. Pick a small, scoped task (three additional tests for a feature you understand) and run the capstone steps as part of real work. The PR at the end becomes a real contribution.

Either way: the workflow is identical. The capstone is exercise, not theatre.

Your seven deliverables

Each deliverable maps to a chapter you've already covered. Here's what "done" looks like:

1. Set up

Clone the repo, install dependencies, run git status, run git log --oneline -10. You should be able to describe the last five commits and confirm a clean working tree. Targets Chapter 1, Lessons 2-4.

2. Add three new tests on a feature branch

git switch -c feature/todo-edit-cases. Write tests for three plausible todo scenarios — editing a completed todo, deleting a todo via keyboard shortcut, marking all complete. Commit each as a separate, well-named commit. Push the branch with -u. Targets Chapter 2 (branching) and Chapter 1, Lesson 4 (workflow).

3. Update .gitignore

Add a new pattern for a tool that started writing artefacts to cypress/visual-snapshots/. Confirm with git status that the folder is invisible. If you previously committed any of these files, run git rm --cached -r to untrack. Targets Chapter 5, Lesson 1.

4. Manufacture and resolve a merge conflict

On main, edit cypress.config.ts — change the defaultCommandTimeout value. Commit. Switch back to your feature branch and edit the same line to a different value. Commit. Try git merge main. Resolve the conflict. Commit. Targets Chapter 2, Lesson 3.

5. Open a pull request with a real description

Push the branch. Create a PR titled clearly (the four sections from Chapter 3, Lesson 3: What / Why / How to run / Test data dependencies). Add yourself as a "reviewer" if working solo, or a teammate if you have one. Targets Chapter 3, Lesson 3.

6. Set up a pre-push hook

Install Husky in the repo. Create .husky/pre-push running an echo plus a real check (lint or a fast smoke test). Push and confirm the hook fires. Commit the .husky/ folder so the next person who clones inherits it. Targets Chapter 5, Lesson 3.

7. Three forensics questions

Use git log, git diff, and git blame to answer:

• How many commits has cypress.config.ts had in its lifetime? (git log --oneline -- cypress.config.ts | wc -l)
• What's the diff between main and your feature branch in cypress/fixtures/? (git diff main..feature/todo-edit-cases -- cypress/fixtures/)
• Who last changed line 12 of cypress.config.ts, and in what commit? (git blame -L 12,12 cypress.config.ts, then git show <hash>)

Targets Chapter 4, Lesson 2.

Stretch goals (optional)

If you finish the seven and want more:

• Branch protection. On GitHub, Settings → Branches → Add branch protection rule for main. Require PR reviews; require status checks to pass; disallow force-push. This is the policy your team will actually run with.
• A team commit message convention. Adopt Conventional Commits — every commit prefixed with feat:, fix:, test:, docs:, chore:, refactor:. Add a commit-msg hook that enforces it via commitlint.
• A CONTRIBUTING.md. A one-page guide for new joiners: branch naming, PR description template, how to run the suite locally, who reviews. Commit it at the repo root. The act of writing it forces you to make every implicit team rule explicit.
• A GitHub Actions workflow. Add .github/workflows/test.yml that runs npm test on every PR. This is the doorway to the CI/CD for testers cheat sheet — and a preview of the CI/CD course you can take next.

How long this takes

A focused tester can do steps 1-7 in three to four hours. The stretch goals add another two to four hours. There's no time pressure — go at your own pace, repeat steps that felt shaky, and don't move on until each one is genuinely comfortable.

If you get stuck, the Git for QA cheat sheet is the single best reference for "I forgot the exact syntax." For deeper "why isn't this working?" debugging, re-read the relevant chapter — every command in this capstone is covered in detail somewhere in the course.

What "good" looks like at the end

By the time you finish, your repo should:

• Have at least 8 commits across main and your feature branch (5 starter + 3 you wrote).
• Have a clean git log --oneline --graph --all showing your branch, the main commits, and one merge.
• Show no untracked artefact folders or secret files.
• Have a .husky/pre-push script that fires on push.
• Have one closed/merged PR with a real description.
• Pass git status cleanly with no straggling work.

When all of that is true, you are demonstrably ready for daily Git work on a real team.

The capstone workflow at a glance

Before you start

Three preflight checks:

• Run git --version and confirm Git is installed (Chapter 1, Lesson 2).
• Run git config --list | grep user and confirm user.name and user.email are set.
• Run ssh -T git@github.com (SSH path) or confirm you have a Personal Access Token saved (HTTPS path). You'll be pushing repeatedly — silent auth pays off.

If any of those isn't set up, jump back to Chapter 3, Lesson 1 before continuing. Auth friction during the capstone makes it harder to learn from.

Project work

Read the next lesson — it walks through every step with exact commands. You can either follow it as you go (most learners do) or attempt the deliverables blind first and use Lesson 2 as a checked-answer key (the stronger learning move, if you're up for the friction).

Either way, the goal at the end of the next lesson is a finished, merged PR you actually built. See you there.