Review and Stretch Goals

You have a merged PR, a working pre-push hook, and a repo whose history you can navigate. Take a moment — that's a real, daily-use skill you built across six chapters. This last lesson is for review, reflection, and the optional extensions that turn the capstone from "it worked once" into something that scales to a real team. Pick the stretch goals that interest you; skip the ones that don't.

Self-assessment checklist

Run through each line. Answer yes or no. The aim isn't a perfect score — it's to know where the gaps are.

• You can clone a repo, create a branch, edit files, commit, and push without consulting any reference.
• You write commit messages that start with a verb in the imperative ("Add", "Fix", "Update") and describe the change in one scannable line.
• You can resolve a merge conflict by hand — finding the markers, choosing or combining the right lines, removing the markers, staging and committing.
• You can open a pull request with a description that covers What / Why / How to run / Test data dependencies.
• You can review someone else's PR and leave at least one substantive comment (not "LGTM").
• You can use git log (with --oneline, --graph, -- <path>) to investigate what changed and when.
• You can use git diff to see what's about to be committed and what's been left out of the commit.
• You can use git blame to find who last changed a line and surface the commit that did it.
• You can write a .gitignore that suppresses node_modules, test artefacts, and .env from a brand-new repo.
• You can articulate the difference between git revert (safe on shared branches) and git reset --hard (only on local commits) without checking notes.
• You understand why git rebase is powerful and why you shouldn't use it on shared branches yet.
• You can set up a Husky pre-push hook so the team inherits it on the next clone.

If any line is "no," that's a clear signal of where to invest the next 30 minutes. The cost of a gap shows up the next time you actually need it under pressure — better to find out now.

Reflection questions

Write your answers somewhere durable — a comment in your git-for-qa-capstone repo's README, a notebook, a personal wiki. They'll be useful in three months when you re-read them.

• Which Git command was hardest for you to internalise? Was it the staging area? Rebase vs merge? Resolving conflicts? Naming the harder areas surfaces what to revisit when you have time.
• Which commands do you think you'll use daily? A realistic answer is git status, git pull, git switch, git add, git commit, git push, git log --oneline. If your list is much longer, you may be over-using the command line where a Git UI would do.
• How confident do you feel reviewing a developer's PR? What would you check first — the test coverage, the code style, the diff size, the CI status? The order itself reveals what kind of reviewer you're becoming.
• What single Git habit do you want to make automatic? "git pull first thing every morning"? "Commit messages always start with a verb"? "Read git diff --staged before every commit"? Pick one. Make it a sticky-note on your monitor for two weeks.

Stretch goals

Pick whichever appeals. Each one extends the capstone and exercises a specific Git skill from the course.

1. Branch protection on main

On GitHub, Settings → Branches → Add branch protection rule. Match main. Enable:

• Require a pull request before merging (no direct pushes to main).
• Require approvals (at least 1).
• Require status checks to pass before merging (we'll set up a status check in stretch goal 4).
• Do not allow force pushes.

Try to push directly to main now — you'll be rejected. Try to merge a PR without approval — also rejected. This is the policy that makes "main is always stable" enforceable, not just aspirational.

2. Conventional Commits

Adopt a commit message convention. The most common is Conventional Commits: every commit message starts with a type prefix — feat:, fix:, test:, docs:, chore:, refactor:, perf:. Example:

feat: add discount-code edge-case tests
fix: stabilise flaky checkout test by waiting for network idle
test: add 5 search regression cases for empty/special-char/pagination
chore: bump cypress to 13.7.0

Add a commit-msg hook (Husky) that runs commitlint to enforce it:

npm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "module.exports = { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js
echo 'npx --no -- commitlint --edit "$1"' > .husky/commit-msg
chmod +x .husky/commit-msg

Commit a deliberately bad message — it should be rejected. Commit a feat: one — it should pass. The tool now teaches the convention to anyone who clones.

3. A CONTRIBUTING.md

Write a one-page guide for new joiners at the repo root. Cover:

• Branch naming convention (feature/, bugfix/, test/).
• PR description template (the four sections from Chapter 3 Lesson 3).
• Commit message convention (from stretch goal 2 if you adopted it).
• Local setup (npm install, how to run the smoke suite).
• Who reviews what (e.g., "Test changes need at least 1 QA approval").

Commit it. Whenever a new joiner arrives, that file saves you twenty minutes of explanation.

4. A GitHub Actions workflow

Add a tiny CI workflow that runs on every PR:

mkdir -p .github/workflows
cat > .github/workflows/test.yml << 'EOF'
name: test
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test
EOF
git add .github/workflows/test.yml
git commit -m "ci: add GitHub Actions workflow to run tests on every PR"
git push

Open a new PR and watch the green check (or red X) appear in the PR's status section. Combined with stretch goal 1, you now require this check to pass before merge — a real CI gate. The CI/CD for testers cheat sheet is your next reference if you want to extend this further.

Where to go next

Five concrete pathways depending on where your curiosity points:

• Ready for CI/CD? A natural follow-on. You set up one workflow file in stretch goal 4 — a full course on CI/CD pipelines, build matrices, secret management, and deployment gates is the next step.
• Ready for test automation? If you don't already write Cypress or Playwright daily, those are the highest-leverage skills next. The Cypress commands cheat sheet and Playwright commands cheat sheet make great starting points.
• Want to deepen your coding? JavaScript for QA and a TypeScript course will pay off the moment you start writing custom test helpers, page objects, or framework-level utilities.
• Want to deepen Git itself? Read the Pro Git book (free online). The chapters on internals (objects, refs, the index) demystify what's actually happening under the hood. You'll never be confused by Git error messages again.
• Want to lead? Read other people's pull requests. Pick a popular open-source repo, watch the PRs land for two weeks, and notice what the maintainers ask, what they don't, and how their reviews are structured. Reviewing well is a skill you can study.

What you've actually learned

A QA engineer who can do all the things on the self-assessment checklist is fluent in Git. You won't need a tutorial for daily work; you'll only reach for one when you hit something genuinely new (interactive rebases, submodules, advanced filter-branch). The course covered the 95% you'll use weekly — and gave you the vocabulary to read about the other 5% when you need it.

Skills earned in this course, mapped to daily QA work

Final word

The hardest part of Git was never the commands — it was building trust that you wouldn't break things irrecoverably. By now you know that almost every "mistake" is recoverable: stash if uncommitted, revert if pushed, reflog if reset. The fear is supposed to fade. It does. Welcome to the rest of your career — every commit, every PR, every line of test code from here on out lives in Git, and you can drive Git.