Git & GitHub

GitHub Actions is now a standard topic in QA automation, SDET and DevOps interviews. This guide covers fundamentals, security, intermediate features, pipeline design and troubleshooting scenarios, with concise model answers.

---

🎯 How to Use These Questions

GitHub Actions now appears in most QA automation, SDET and DevOps interviews. The questions below go from fundamentals to advanced design and troubleshooting. Practise answering out loud, and back each answer with something you built, ideally the CI/CD pipeline project.

---

🟢 Fundamentals

🤔 What is GitHub Actions?

GitHub’s built-in CI/CD and automation platform. Workflows defined in YAML in .github/workflows/ run on events such as pushes, pull requests or schedules, on GitHub-hosted or self-hosted runners (fundamentals).

🤔 Explain workflow, job, step, action and runner.

A workflow is the YAML file; it contains jobs; each job runs on a runner (a VM or container) and executes steps in order; a step runs a shell command (run) or a reusable action (uses).

🤔 How do jobs run: in parallel or in sequence?

In parallel by default. Use needs to create dependencies and pass outputs between jobs (workflow syntax).

🤔 What is the difference between uses and run?

uses calls an action (from the Marketplace, another repository or a local path); run executes shell commands on the runner.

🤔 What triggers have you used?

push and pull_request with branch and path filters, schedule for nightly regression, workflow_dispatch with inputs for manual runs, workflow_call for reusable workflows and release or tag pushes for deployments.

---

🔐 Secrets, Variables and Security

🤔 How do you handle secrets in GitHub Actions?

Store them as repository, environment or organisation secrets, reference them with secrets.NAME as environment variables, never echo them, and keep GITHUB_TOKEN permissions minimal (secrets and environments).

🤔 What is GITHUB_TOKEN and how do you limit it?

A short-lived token created for each run. Set permissions: at workflow or job level (for example contents: read) so it only has the access the job needs.

🤔 Why are secrets not available in pull requests from forks?

To prevent untrusted code in a fork from reading them. Workflows triggered by pull_request from forks run without secrets and with a read-only token.

🤔 How do you use third-party actions safely?

Prefer verified publishers, pin third-party actions to a full commit SHA, review their code, and let Dependabot update action versions (security).

🤔 What are environments used for?

Deployment targets with their own secrets and variables and protection rules: required reviewers, wait timers and allowed branches, which gives approval gates before production.

---

🟡 Intermediate

🤔 How do you run tests in multiple browsers or OS versions?

With a matrix strategy, fail-fast: false for test suites, and unique artifact names per combination (matrix, cache and artifacts).

🤔 Difference between cache and artifacts?

Caches reuse dependencies across runs to save time; artifacts store outputs of a run (reports, traces, builds) for later jobs or download.

🤔 How do you upload test reports even when tests fail?

Add if: !cancelled() or always() to the upload-artifact step, and record traces or screenshots on failure in the test framework.

🤔 How do you avoid duplicate runs when pushing several times quickly?

A concurrency group per branch or PR with cancel-in-progress: true (but not for deployments).

🤔 How do you skip CI for documentation-only changes?

paths-ignore on the trigger, for example **.md and docs/**.

---

🟠 Advanced Design

🤔 Reusable workflow vs composite action?

A reusable workflow reuses whole jobs (own runner, inputs, secrets, outputs) via workflow_call; a composite action reuses steps inside a job. I use reusable workflows for standard test and deploy pipelines and composite actions for shared setup (reusable workflows).

🤔 How do you design a pipeline for a large Playwright suite?

Fast PR gate (lint, type check, smoke tests in one browser), full regression on main and nightly across browsers with sharding and a merged report, traces on retry, artifacts and a published report, and required checks in a ruleset (Playwright in GitHub Actions).

🤔 How do you deploy safely with GitHub Actions?

Build once, deploy to staging, run smoke tests, then deploy to production behind an environment with required reviewers; use OIDC for cloud credentials and concurrency without cancellation (deployment).

🤔 When would you use self-hosted runners?

For special hardware, access to internal networks or test environments, or cost control on very heavy workloads; with ephemeral runners and care, because they persist state and run untrusted PR code if misconfigured.

🤔 How do you pass data between jobs?

Job outputs for small values (written to $GITHUB_OUTPUT) and artifacts for files.

---

🔴 Troubleshooting Scenarios

🤔 A workflow is not triggering. How do you investigate?

Check the YAML location and syntax, the event and branch or path filters, whether Actions is enabled, and for schedules that they run on the default branch in UTC. Also note that events created with GITHUB_TOKEN do not trigger new workflow runs.

🤔 Tests pass locally but fail in CI. What do you check?

Differences in environment (headless, viewport, time zone, OS), missing secrets or variables, dependency versions (use npm ci and the lock file), timing and test data. Download the traces and screenshots from artifacts.

🤔 A required status check never appears on the PR. Why?

The job name changed, the workflow did not run for that PR (path filters), or it was never run so it cannot be selected. Required checks must match the job name exactly.

🤔 Your workflow is slow. How do you speed it up?

Cache dependencies, run lint and smoke first, shard or use a matrix, skip irrelevant runs with path filters, cancel superseded runs, and avoid installing unnecessary browsers.

---

💡 Tips for the Interview

• Have a public repository with a working pipeline and green badges to show.
• Explain the why behind each design choice (speed, safety, cost).
• Know the common YAML keys well enough to write a basic workflow on a whiteboard.

---

❓ FAQ

🤔 What GitHub Actions questions are asked in QA interviews?

Triggers, running tests in CI, matrices for browsers, artifacts for reports, secrets, required checks on pull requests and debugging failing CI runs.

🤔 How do I prepare for a GitHub Actions interview?

Build a real pipeline for a test project, practise the questions on this page, and be ready to explain your YAML line by line.

🤔 Is GitHub Actions better than Jenkins?

For projects already on GitHub it is usually simpler: no server to maintain, tight PR integration and a large Marketplace. Jenkins remains common for complex self-hosted enterprise pipelines (Playwright with Jenkins).

---

🎯 Next Steps

• 🏗️ Project 2: CI/CD Pipeline for a Test Automation Repo
• 💼 Git Interview Questions for Experienced
• 📘 Git and GitHub Tutorial: full course

Experienced Git interviews test judgement, not just commands. This guide covers the questions asked of developers, SDETs and DevOps engineers with several years of experience, with model answers and real-world scenarios.

---

🎯 What Experienced Git Interviews Test

For freshers, interviewers ask “what does git pull do?”. For experienced candidates (3, 5 or 10 years; developers, SDETs and DevOps engineers), they ask why and what would you do: how you keep history clean, recover from mistakes, structure branches for a team and integrate Git with CI/CD. Answer with the concept, a command, and a real situation where you used it.

For basics, start with GitHub interview questions and answers.

---

🧠 Concepts and Internals

🤔 What actually happens when you run git commit?

Git writes blob objects for staged file contents (via the index), tree objects for directories, and a commit object that points to the root tree, the parent commit(s), author, committer and message. It then moves the current branch reference to the new commit. See Git internals.

🤔 What is the difference between HEAD, the working tree and the index?

HEAD points to the current commit (usually through a branch), the index (staging area) holds the snapshot for the next commit, and the working tree is the files on disk. Commands like reset --soft/--mixed/--hard differ exactly in which of these three they change.

🤔 What is detached HEAD and how do you get out of it safely?

HEAD points directly to a commit instead of a branch, for example after checking out a tag or during bisect. To keep work done there, create a branch: git switch -c rescue-branch; otherwise git switch main.

🤔 Why does rebasing change commit hashes?

A commit’s hash covers its content, metadata and parent. Rebasing gives commits new parents, so Git creates new commits with new hashes; the originals remain reachable via the reflog for a while.

---

🔀 Branching, Merging and Rebasing

🤔 Merge vs rebase: what do you use, and when?

I rebase my own feature branch on main to keep it current and linear, and integrate into main through a pull request, usually with squash or merge commits depending on team policy. I never rebase shared branches. See rebase vs merge.

🤔 What is the golden rule of rebasing?

Do not rebase commits that others have based work on. If I rebase my pushed feature branch, I update it with --force-with-lease, never plain --force.

🤔 Explain fast-forward vs three-way merge and –no-ff.

Fast-forward just moves the branch pointer when the target has no new commits. A three-way merge creates a merge commit using the common ancestor. --no-ff forces a merge commit to keep the feature visible in history (merge).

🤔 How do you handle a large merge conflict in a critical file?

Abort if unprepared (git merge --abort), understand both sides with git log --merge and the PRs, resolve in a 3-way merge tool, involve the other author, run the tests, then commit. To reduce future conflicts: smaller PRs and frequent integration (conflicts).

🤔 How would you squash 10 commits before merging a PR?

git rebase -i main (or HEAD~10), mark later commits as fixup or squash, then git push --force-with-lease; or use “Squash and merge” on GitHub (interactive rebase).

🤔 When do you use cherry-pick?

To backport a specific fix to a release branch without bringing other changes, using -x for traceability (cherry-pick).

---

🛟 Recovery and Undo

🤔 A teammate ran git reset –hard and lost a day of work. Can you help?

If the work was committed, yes: git reflog shows previous HEAD positions; create a branch at the lost commit. Uncommitted changes cannot be recovered this way (reflog).

🤔 How do you undo a bad commit that is already on main and deployed?

git revert <hash> (or git revert -m 1 <merge-commit> for a merge), through a PR, then deploy. Revert keeps history intact; reset plus force push on main is not acceptable (undo changes).

🤔 Someone committed an API key and pushed it. What do you do?

First revoke and rotate the key. Then remove it from the code, and if required by policy, rewrite history with a tool such as git filter-repo and coordinate a re-clone with the team. Prevent recurrence with .gitignore, secret scanning and push protection (security).

🤔 How do you find which commit introduced a regression in a 500-commit range?

git bisect with a known good tag and the bad HEAD, ideally automated with git bisect run and a reproducing test: about nine steps for 500 commits (bisect).

---

🌳 Workflows and Team Practices

🤔 Which branching strategy have you used and why?

Example answer: “GitHub Flow with short-lived branches and squash merges, because we deploy several times a week and our automated tests run on every PR. For our mobile app we used a lighter Git Flow with release branches for app-store releases.” (branching strategies)

🤔 How do you protect the main branch?

Rulesets requiring a PR, at least one approval, Code Owner review for critical paths, required status checks, conversation resolution, and no force pushes or deletions (branch protection).

🤔 How do you keep commit history useful in a large team?

Conventional Commits enforced by commitlint and Husky, small PRs, squash merges, linked issues and tags for releases, which also enables automated changelogs (commit messages, hooks).

🤔 How do you share code between repositories?

Prefer versioned packages; use submodules when you need another repository’s exact source at a pinned commit; consider a monorepo when projects change together (submodules).

---

🚀 Git in CI/CD (SDET and DevOps Focus)

🤔 How is Git connected to your CI/CD pipeline?

Pushes and pull requests trigger workflows; branch names, tags and paths control which jobs run; required checks gate merges; tags trigger releases and deployments (GitHub Actions workflow syntax).

🤔 Why use a shallow clone in CI, and when is it a problem?

--depth 1 (the default in actions/checkout) is faster. It breaks tools that need history, such as changelog generators, git describe or diffing against main; then use fetch-depth: 0.

🤔 How do you run only tests affected by a change?

Use path filters on workflow triggers, or compare changed files with git diff --name-only origin/main...HEAD and map them to test suites or tags.

---

🧩 Scenario Round

🤔 You pushed to the wrong branch. What do you do?

If it is a shared branch, revert the commit there and cherry-pick it to the right branch. If it is your own branch, reset it and force-push with lease after cherry-picking to the correct branch.

🤔 Two teams need the same hotfix in release/2.3 and main. How?

Fix on main through a PR, then cherry-pick with -x into release/2.3 through a second PR; tag the patch release.

🤔 Your PR shows hundreds of unrelated changes. Why?

Usually the branch was based on the wrong branch or main was merged in with different line endings. Check git merge-base, rebase onto the correct base, and fix line-ending settings (core.autocrlf or .gitattributes).

---

💡 Interview Tips

• Prepare two real stories: recovering lost work and fixing a painful conflict or broken pipeline.
• Show your public projects: the team workflow and CI/CD pipeline projects make excellent talking points.
• Be ready to type commands live without an IDE; keep the cheat sheet in your revision notes.

---

❓ FAQ

🤔 What Git questions are asked for 5 years of experience?

Merge vs rebase decisions, interactive rebase, reflog recovery, revert vs reset on shared branches, bisect, branching strategies, branch protection, leaked secrets and Git in CI/CD.

🤔 How should I prepare for a Git interview as an SDET?

Practise the commands hands-on, prepare stories about collaboration and recovery, and be ready to explain how tests are triggered and gated in CI on pull requests.

🤔 Which Git topics do DevOps interviews focus on?

Branching strategies, tags and releases, hooks, protected branches, CI triggers, shallow clones and history rewriting policies.

---

🎯 Next Steps

• ⚙️ GitHub Actions Interview Questions
• 💼 GitHub Interview Questions and Answers
• 📘 Git and GitHub Tutorial: full course

All the Git commands you need on one page, grouped by task: setup, committing, history, branches, merging and rebasing, remotes, undo, stash, tags, advanced tools and the GitHub CLI. Bookmark it and keep it open while you work.

---

📌 How to Use This Cheat Sheet

All the Git commands you use daily, grouped by task, with links to the full lessons in the Git and GitHub Tutorial. To keep a copy, use your browser’s Print, Save as PDF.

---

⚙️ Setup and Configuration

git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --global alias.lg "log --oneline --graph --decorate --all"
git config --list --show-origin
ssh-keygen -t ed25519 -C "you@example.com"     # SSH key for GitHub
ssh -T git@github.com                          # test the connection

Lessons: install, config, SSH keys

---

🧱 Start a Repository

git init                                   # new repo in the current folder
git clone <url>                            # copy a remote repo
git clone --depth 1 <url>                  # shallow clone
git remote add origin <url>
git push -u origin main                    # first push with upstream

Lessons: first repository, push an existing project

---

💾 Daily Work: Stage and Commit

git status                                 # what changed? (git status -s for short)
git add file.txt                           # stage one file
git add .                                  # stage everything here
git add -p                                 # stage parts of files
git commit -m "feat(login): add locked-out user test"
git commit -am "fix: update selector"      # stage tracked files and commit
git commit --amend --no-edit               # add staged changes to the last commit
git diff                                   # unstaged changes
git diff --staged                          # staged changes

Lessons: staging area, commit messages

---

📜 History

git log --oneline --graph --all
git log -n 5 --stat
git log --author="Asha" --since="2 weeks ago"
git log -S "waitForTimeout"                # commits that added/removed text
git log -- tests/login.spec.ts             # history of one file
git show HEAD~1                            # one commit
git blame -L 10,20 file.ts                 # who changed these lines

Lesson: log, show and diff

---

🌿 Branches

git branch                                 # list (-a all, -vv with tracking)
git switch -c feature/x                    # create and switch
git switch main                            # switch
git branch -m old new                      # rename
git branch -d feature/x                    # delete merged (-D force)
git push -u origin feature/x               # publish a branch
git push origin --delete feature/x         # delete on GitHub

Lesson: branches

---

🔀 Merge and Rebase

git merge feature/x                        # merge into current branch
git merge --no-ff feature/x
git merge --squash feature/x
git merge --abort
git rebase main                            # replay current branch on main
git rebase -i HEAD~3                       # squash, reword, reorder
git rebase --continue | --skip | --abort
git cherry-pick <hash>                     # copy one commit here

Lessons: merge, conflicts, rebase, interactive rebase, cherry-pick

---

🌐 Remotes: Sync with GitHub

git remote -v
git fetch                                  # download, do not merge (--prune to clean up)
git pull                                   # fetch + merge (--rebase to rebase)
git push
git push --force-with-lease                # after rewriting YOUR branch
git remote add upstream <original-url>     # forks
git fetch upstream && git merge upstream/main

Lessons: remotes, clone, push, pull, fetch vs pull, forks

---

↩️ Undo

Situation	Command
Discard edits in a file	git restore file
Unstage a file	git restore --staged file
Fix the last commit message	git commit --amend -m "msg"
Undo last commit, keep changes staged	git reset --soft HEAD~1
Undo last commit, keep changes unstaged	git reset HEAD~1
Throw away last commit and changes	git reset --hard HEAD~1
Undo a pushed commit safely	git revert <hash>
Remove untracked files	git clean -n then git clean -fd
Recover lost commits	git reflog then git reset --hard <hash>

Lessons: undo changes, reflog

---

📦 Stash

git stash push -m "WIP login"              # -u to include untracked files
git stash list
git stash pop                              # apply and remove
git stash apply stash@{1}                  # apply and keep
git stash drop stash@{1}

Lesson: stash

---

🏷️ Tags and Releases

git tag -a v1.0.0 -m "Release 1.0.0"
git push origin v1.0.0                     # or --tags
git tag -d v1.0.0 && git push origin --delete v1.0.0
gh release create v1.0.0 --generate-notes

Lesson: tags

---

🧰 Advanced

git bisect start; git bisect bad; git bisect good v1.0.0
git bisect run npm test                    # automate; git bisect reset when done
git submodule update --init --recursive
git check-ignore -v file                   # why is it ignored?
git rm --cached .env                       # stop tracking, keep the file
git cat-file -p HEAD                       # look inside a commit

Lessons: bisect, submodules, .gitignore, internals

---

⌨️ GitHub CLI Essentials

gh auth login
gh repo create my-repo --private --clone
gh pr create --fill
gh pr checkout 57
gh pr merge 57 --squash --delete-branch
gh run watch
gh run view <id> --log-failed

Lesson: GitHub CLI

---

🚫 Top 10 Mistakes to Avoid

1. Committing secrets or .env files.
2. Committing node_modules or test reports instead of using .gitignore.
3. Working directly on main in a team.
4. Force-pushing shared branches (use --force-with-lease only on your own).
5. Rebasing commits others already have.
6. Huge commits with messages like “update”.
7. Long-lived branches that drift far from main.
8. Using reset --hard without checking git status and git diff first.
9. Resolving conflicts without understanding both sides.
10. Ignoring failing CI on pull requests.

---

❓ FAQ

🤔 What are the most important Git commands for beginners?

git init, git clone, git status, git add, git commit, git log, git branch, git switch, git merge, git pull and git push.

🤔 Is there a Git cheat sheet PDF?

Use your browser’s Print, Save as PDF on this page to keep an offline copy.

🤔 How do I undo the last commit in Git?

git reset --soft HEAD~1 to keep the changes staged, or git revert HEAD if the commit is already pushed.

🤔 How do I see all branches?

git branch -a lists local and remote-tracking branches.

---

🎯 Next Steps

• 💼 Git Interview Questions for Experienced
• 📝 Module-wise Practice Assignments
• 📘 Git and GitHub Tutorial: full course

You learn Git by typing commands, not by reading about them. This page gives you a checkpoint exercise for every module of the Git and GitHub course, so you can prove each skill before moving on.

---

🏋️ How to Use This Page

Every lesson in the Git and GitHub Tutorial ends with its own assignment. This page adds one checkpoint per module: a slightly bigger exercise that combines the lessons in that module. Do it before moving on.

Rules:

• Use a dedicated practice repository on GitHub (for example git-practice).
• Do the tasks in the terminal first; use VS Code or the GitHub website only where the task says so.
• After each checkpoint, run git log --oneline --graph --all and make sure you can explain every line.

Level	Modules	Badge
🟢 Beginner	1 to 3	Git User
🔵 Intermediate	4 to 6	Team Collaborator
🟠 Advanced	7 to 10	Git and CI/CD Pro
🟣 Career	11 to 12	Interview Ready

---

🟢 Module 1 Checkpoint: Getting Started

Lessons: What Is Git and GitHub, Install Git, Install on macOS, Terminal commands, git config, SSH keys, GitHub fundamentals

1. Install Git, set name, email, editor, default branch main and the lg alias.
2. Create a GitHub account with 2FA and connect with an SSH key; prove it with ssh -T git@github.com.
3. Write a one-paragraph explanation of Git vs GitHub in your own words.

---

🟢 Module 2 Checkpoint: Git Basics

Lessons: init, add, commit, staging area, log and diff, .gitignore, undo changes

1. Create a repository with at least 6 meaningful commits.
2. Add a .gitignore that ignores node_modules/, .env and reports/; prove it with git check-ignore -v.
3. Commit something by mistake, then: amend a message, unstage a file, undo a commit with reset --soft, and undo another with revert.
4. Find a specific change using git log -S and show it with git show.

---

🟢 Module 3 Checkpoint: Remotes

Lessons: git remote, clone, push, pull, fetch vs pull, push an existing project

1. Push an existing local folder to a new GitHub repository.
2. Clone it into a second folder; push from one and fetch, inspect and merge in the other.
3. Create diverging commits and solve “rejected (fetch first)” once with merge and once with pull --rebase.

---

🔵 Module 4 Checkpoint: Branching and Merging

Lessons: branches, merge, merge conflicts, rebase, stash, cherry-pick, tags

1. Create three feature branches; merge one fast-forward, one with --no-ff and one with --squash; compare the graph.
2. Create and resolve a conflict by merge, then another by rebase.
3. Stash unfinished work, switch branch, fix something, and pop the stash.
4. Cherry-pick a fix from a feature branch to a release/0.1 branch.
5. Tag v0.1.0 (annotated), push it and create a GitHub Release.

---

🔵 Module 5 Checkpoint: Collaboration

Lessons: pull requests, code review, forks, issues and projects, README

1. Open two pull requests with good descriptions and Closes #n links; review one with a suggestion and Request changes.
2. Fork a public repository, sync it with upstream, and open a PR (to your own second repo if you prefer).
3. Create a Project board, labels and a milestone; move issues as PRs merge.
4. Write a complete README with badges, setup steps and a project structure section.

---

🔵 Module 6 Checkpoint: Team Workflows

Lessons: branching strategies, commit messages, Git in VS Code, best practices

1. Write a CONTRIBUTING.md choosing GitHub Flow or Git Flow, with branch names and Conventional Commits.
2. Simulate Git Flow with develop, a release branch and a hotfix.
3. Do one full cycle (branch, commit, push, PR, resolve a conflict) using only VS Code.

---

🟠 Module 7 Checkpoint: Advanced Git

Lessons: interactive rebase, reflog, bisect, hooks, submodules, internals

1. Turn a branch with 8 messy commits into 3 clean ones with rebase -i (squash, reword, drop).
2. Delete a branch and run reset --hard by “mistake”; recover both with the reflog.
3. Find a commit that introduced a bug with git bisect run.
4. Add a pre-commit hook (or Husky) that blocks test.only and a commit-msg check.
5. Follow a commit to its tree and a blob with git cat-file -p.

---

🟠 Module 8 Checkpoint: Security and Administration

Lessons: tokens, branch protection, CODEOWNERS and templates, security

1. Create a fine-grained token limited to one repository, use it, then revoke it.
2. Protect main with a ruleset requiring a PR, one approval and a status check.
3. Add CODEOWNERS, an issue form and a PR template.
4. Enable Dependabot, secret scanning with push protection, and CodeQL on a public repo.

---

🟠 Module 9 Checkpoint: GitHub Actions

Lessons: roadmap, fundamentals, workflow syntax, example pipelines, secrets and environments, intermediate concepts, matrix, cache, artifacts, reusable workflows, deployment, practice projects

1. Build a workflow with push, pull_request, schedule and workflow_dispatch triggers and two dependent jobs.
2. Add a matrix of 3 browsers with fail-fast: false, npm caching and an artifact per browser.
3. Move the test job into a reusable workflow and call it from two pipelines.
4. Create staging and production environments with an approval, and deploy a static page to GitHub Pages.

---

🟠 Module 10 Checkpoint: Tools and Ecosystem

Lessons: GitHub CLI, GitHub Pages, Codespaces, Copilot

1. Create a repo, open a PR, check CI and merge it entirely with gh.
2. Publish your portfolio at <username>.github.io.
3. Add a devcontainer.json and run a project’s tests in a codespace.
4. Use Copilot to draft a test and a PR description; review and improve both.

---

🟣 Module 11 and 12 Checkpoint: Projects and Interviews

1. Complete Project 1: Team Workflow and Project 2: CI/CD Pipeline and pin both repositories on your GitHub profile.
2. Practise the GitHub interview questions, Git questions for experienced and GitHub Actions questions out loud.
3. Keep the Git cheat sheet open while you work for a week, then try without it.

---

❓ FAQ

🤔 Where can I practise Git and GitHub for free?

In your own free GitHub repositories, using the module checkpoints on this page and the assignments at the end of each lesson.

🤔 Do I need a team to practise GitHub collaboration?

No. Use a second clone or a second GitHub account to simulate teammates, as in the team workflow project.

🤔 How long does it take to finish all checkpoints?

At about an hour a day, most learners finish them, including the two projects, in one to two months.

🤔 Are solutions provided?

Each linked lesson contains the commands and examples needed. Use git log, the GitHub UI and the cheat sheet to check your work.

---

🎯 Next Steps

• 📄 Git Commands Cheat Sheet
• 💼 GitHub Interview Questions and Answers
• 📘 Git and GitHub Tutorial: full course

In this capstone project you will build a complete, production-style GitHub Actions pipeline for a Playwright test automation repository: fast PR checks, cross-browser regression, manual environment runs, artifacts, Dependabot and documentation.

---

🎯 Project Brief

Build a production-style CI/CD pipeline in GitHub Actions for a Playwright + TypeScript test automation repository. When you finish, every pull request is tested automatically, results are easy to read, failures are easy to debug, and a nightly regression runs across browsers.

Time needed: 6 to 10 hours. Prerequisites: Modules 1 to 9 of this course and a Playwright project, ideally from the Playwright e-commerce framework project (any Playwright project works).

---

📋 Requirements

#	Requirement	Lesson
1	Lint and type-check on every PR	workflow syntax
2	Smoke tests (Chromium) on every PR, required to merge	branch protection
3	Full regression on main and nightly, across 3 browsers	matrix
4	npm caching and artifacts for reports and traces	cache and artifacts
5	Secrets and per-environment URLs	secrets and environments
6	A reusable test workflow used by all pipelines	reusable workflows
7	Manual run against a chosen environment	workflow_dispatch
8	Latest report published to GitHub Pages (non-sensitive project)	deployment
9	Dependabot for npm and GitHub Actions	security
10	CI badge and run instructions in the README	README

---

🗂️ Target Structure

.github/
├── workflows/
│   ├── pr.yml               # lint + smoke tests on pull requests
│   ├── regression.yml       # main + nightly, 3 browsers
│   ├── manual.yml           # workflow_dispatch against an environment
│   └── playwright-run.yml   # reusable workflow (workflow_call)
└── dependabot.yml

---

🔁 Step 1: The Reusable Test Workflow

# .github/workflows/playwright-run.yml
name: Playwright run (reusable)
on:
  workflow_call:
    inputs:
      project:   { type: string, default: chromium }
      grep:      { type: string, default: '' }
      base-url:  { type: string, required: true }
      artifact:  { type: string, default: playwright-report }

jobs:
  run:
    runs-on: ubuntu-latest
    timeout-minutes: 45
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: lts/*
          cache: npm
      - run: npm ci
      - run: npx playwright install --with-deps ${{ inputs.project }}
      - name: Run tests
        run: npx playwright test --project=${{ inputs.project }} ${{ inputs.grep != '' && format('--grep {0}', inputs.grep) || '' }}
        env:
          BASE_URL: ${{ inputs.base-url }}
          TEST_PASSWORD: ${{ secrets.TEST_PASSWORD }}
      - uses: actions/upload-artifact@v4
        if: ${{ !cancelled() }}
        with:
          name: ${{ inputs.artifact }}
          path: |
            playwright-report/
            test-results/
          retention-days: 14

---

✅ Step 2: Pull Request Pipeline

# .github/workflows/pr.yml
name: PR checks
on:
  pull_request:
    branches: [ main ]
concurrency:
  group: pr-${{ github.event.pull_request.number }}
  cancel-in-progress: true
permissions:
  contents: read

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: lts/*, cache: npm }
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm run lint

  smoke:
    needs: lint
    uses: ./.github/workflows/playwright-run.yml
    with:
      project: chromium
      grep: '@smoke'
      base-url: https://www.saucedemo.com
      artifact: smoke-report
    secrets: inherit

Make lint and smoke / run required status checks in your ruleset.

---

🌙 Step 3: Regression on main and Nightly

# .github/workflows/regression.yml
name: Regression
on:
  push:
    branches: [ main ]
  schedule:
    - cron: '30 20 * * *'          # 02:00 IST

jobs:
  regression:
    strategy:
      fail-fast: false
      matrix:
        project: [ chromium, firefox, webkit ]
    uses: ./.github/workflows/playwright-run.yml
    with:
      project: ${{ matrix.project }}
      base-url: https://www.saucedemo.com
      artifact: regression-report-${{ matrix.project }}
    secrets: inherit

---

🎛️ Step 4: Manual Run Against an Environment

# .github/workflows/manual.yml
name: Manual test run
on:
  workflow_dispatch:
    inputs:
      target:  { type: environment, description: 'Environment to test' }
      project: { type: choice, options: [ chromium, firefox, webkit ], default: chromium }
      grep:    { type: string, description: 'Tag filter, e.g. @smoke', default: '' }

jobs:
  info:
    runs-on: ubuntu-latest
    environment: ${{ inputs.target }}
    outputs:
      base-url: ${{ vars.BASE_URL }}
    steps:
      - run: echo "Testing ${{ vars.BASE_URL }}"

  run:
    needs: info
    uses: ./.github/workflows/playwright-run.yml
    with:
      project: ${{ inputs.project }}
      grep: ${{ inputs.grep }}
      base-url: ${{ needs.info.outputs.base-url }}
      artifact: manual-report
    secrets: inherit

Create environments qa and staging, each with a BASE_URL variable, and trigger runs from the Actions tab or with gh workflow run manual.yml -f target=qa -f grep=@smoke.

---

🤖 Step 5: Dependabot and README

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule: { interval: weekly }
    groups:
      playwright: { patterns: [ "@playwright/*" ] }
  - package-ecosystem: github-actions
    directory: "/"
    schedule: { interval: monthly }

Add the badges for pr.yml and regression.yml to the README and document how to run tests locally and in CI.

---

🌐 Step 6 (Optional): Publish the Latest Report

Add a job to regression.yml that downloads the Chromium report artifact and deploys it with actions/upload-pages-artifact and actions/deploy-pages (see deployment). Only for public, non-sensitive projects.

---

✅ Acceptance Checklist

• [ ] A PR with a failing smoke test cannot be merged
• [ ] Lint and type errors fail the PR
• [ ] Regression runs on main and nightly in 3 browsers; one browser failing does not cancel the others
• [ ] Reports and traces downloadable for every run
• [ ] No secrets in YAML; manual runs choose an environment
• [ ] npm cache hit on repeat runs
• [ ] Dependabot PRs appear and run the PR pipeline
• [ ] README shows green badges

---

🏅 Evaluation Rubric

Criterion	Weight
Correct triggers and required checks	20%
Reuse (reusable workflow, no copy-paste)	20%
Speed (cache, concurrency, smoke vs regression split)	15%
Debuggability (artifacts, traces, summaries)	15%
Security (secrets, permissions, Dependabot)	15%
Documentation (README, badges)	15%

---

❓ FAQ

🤔 Do I need a Playwright project for this?

Yes, any Playwright project works. The e-commerce framework from the Playwright course is ideal.

🤔 Why split smoke and regression?

Smoke tests give fast feedback on every PR; the slower full regression runs on main and nightly across all browsers.

🤔 Why use a reusable workflow?

All pipelines share one definition of how tests run, so a change (for example a new Node version) is made once.

🤔 How do I add this project to my CV?

Link the repository, mention the pipelines (PR gate, cross-browser nightly, manual environment runs) and show the green badges.

---

🎯 Next Steps

• 📝 Module-wise Practice Assignments
• 📄 Git Commands Cheat Sheet
• 📘 Git and GitHub Tutorial: full course

Time to practise Git and GitHub the way real teams use them. In this project you will set up a protected repository, plan work, build features in parallel, review pull requests, resolve a conflict, publish releases and ship a hotfix.

---

🎯 Project Brief

You will run a realistic team workflow on GitHub from start to finish: planning, branching, pull requests, reviews, conflicts, releases and a hotfix. Work with one or two friends (best), or simulate teammates with a second GitHub account or a second clone.

Goal: prove you can collaborate on GitHub the way professional teams do. This is excellent material for interviews: “Walk me through how your team uses Git.”

Time needed: 4 to 6 hours. Skills used: Modules 1 to 8.

---

👥 Roles

Role	Responsibilities
Maintainer (you)	Creates the repo, sets rules, reviews and merges, cuts releases
Contributor A	Builds feature 1, reviews feature 2
Contributor B	Builds feature 2, reviews feature 1, reports a bug

Solo? Play all roles, using a second clone (git clone <url> contributor-b) and, if possible, a second GitHub account for reviews.

---

🧱 Phase 1: Set Up the Repository (Maintainer)

1. Create a public repository team-qa-notes with a README and a Node or Python .gitignore (create and push).
2. Add collaborators: Settings, Collaborators, Add people.
3. Add community files:

• CONTRIBUTING.md with branch naming (feature/, fix/) and Conventional Commits.
• .github/CODEOWNERS making the maintainer owner of everything (CODEOWNERS).
• .github/pull_request_template.md and a bug report issue form.

4. Protect main with a ruleset: pull request required, 1 approval, no force pushes or deletions (branch protection).
5. Add a simple CI workflow that runs on pull requests (for example echo checks or a linter) and make it a required check.

✅ Checkpoint: a direct git push origin main is rejected.

---

🗂️ Phase 2: Plan the Work

1. Create a Project board with Todo, In progress, In review, Done (Issues and Projects).
2. Create a milestone v0.1.0.
3. Create issues and add them to the board and milestone:

– #1 “Add Git basics notes” (assign A) – #2 “Add GitHub Actions notes” (assign B) – #3 “Add a glossary to README” (maintainer)

---

🌿 Phase 3: Build Features in Parallel

Each contributor:

git clone git@github.com:maintainer/team-qa-notes.git
cd team-qa-notes
git switch -c feature/1-git-basics-notes          # B uses feature/2-actions-notes
# create docs/git-basics.md, commit in small steps
git commit -m "docs(git): add commit and branch notes"
git commit -m "docs(git): add undo commands table"
git push -u origin feature/1-git-basics-notes

Open pull requests with Closes #1 / Closes #2, filling in the template (pull requests).

---

👀 Phase 4: Review

• A reviews B’s PR and B reviews A’s: at least one line comment, one suggestion, and one Request changes (code review).
• Authors address the feedback with new commits, resolve conversations and re-request review.
• Before merging, each author tidies their commits with interactive rebase and git push --force-with-lease (their own branch only).

---

🧯 Phase 5: Create and Resolve a Conflict

1. Both contributors edit the same lines of README.md on their branches (for example the title line).
2. Merge A’s PR first (Squash and merge).
3. B’s PR now shows a conflict. B updates the branch locally:

git switch feature/2-actions-notes
git fetch origin
git rebase origin/main
# resolve README.md, then:
git add README.md
git rebase --continue
git push --force-with-lease

1. CI passes again; the maintainer merges (merge conflicts, rebase).

✅ Checkpoint: issues #1 and #2 closed automatically, board items moved to Done.

---

🏷️ Phase 6: Release

The maintainer:

git switch main && git pull
git tag -a v0.1.0 -m "First release of team QA notes"
git push origin v0.1.0
gh release create v0.1.0 --generate-notes

See tags and releases and GitHub CLI.

---

🚑 Phase 7: Hotfix

1. Contributor B reports a bug issue: “Typo in the undo commands table” using the issue form.
2. Contributor A fixes it on fix/4-undo-typo, opens a PR with Fixes #4, gets approval, merges.
3. Maintainer tags v0.1.1 and publishes a release.

---

🔄 Phase 8: Stay in Sync and Clean Up

git switch main
git pull
git branch -d feature/1-git-basics-notes
git fetch --prune

---

✅ Deliverables Checklist

• [ ] Protected main with required review and CI check
• [ ] CONTRIBUTING, CODEOWNERS, PR template and issue form
• [ ] Project board and milestone with linked issues
• [ ] At least 3 merged PRs with reviews, suggestions and resolved conversations
• [ ] One conflict resolved by rebasing
• [ ] Releases v0.1.0 and v0.1.1 with generated notes
• [ ] Clean history on main (one commit per PR)

---

🏅 Evaluation Rubric

Criterion	Weight
Repository setup and rules	20%
Planning with issues, board and milestone	15%
Quality of PRs and reviews	25%
Conflict resolution and clean history	20%
Releases and hotfix flow	20%

---

❓ FAQ

🤔 Can I do this project alone?

Yes. Use a second clone to simulate another developer, and a second GitHub account if you want real review approvals.

🤔 Why is main protected in this project?

Protection forces the team workflow: every change goes through a reviewed, tested pull request, exactly as in professional teams.

🤔 Should I merge or rebase to fix the conflict?

Either works. The project uses rebase on the contributor’s own branch to keep history linear; never rebase main.

🤔 How do I show this project in an interview?

Share the repository link and walk through the board, a reviewed PR, the conflict resolution and the releases.

---

🎯 Next Steps

• 🚀 Project 2: CI/CD Pipeline for a Test Automation Repo
• 📝 Module-wise Practice Assignments
• 📘 Git and GitHub Tutorial: full course

GitHub Copilot can speed up coding, testing and reviews when used well. In this lesson you will learn its main features and plans, set it up in VS Code, use practical prompts for test automation, and apply it responsibly.

---

🤖 What Is GitHub Copilot?

GitHub Copilot is GitHub’s AI assistant for software work. It suggests code as you type, answers questions in a chat, makes multi-file changes, reviews pull requests and can even work on issues by itself and open a pull request.

Feature	What it does
Code completions	Suggests the next lines or a whole function as you type
Copilot Chat	Explains code, writes tests, finds bugs, answers questions about your repository
Agent mode (in the editor)	Plans and edits several files, runs commands and iterates until a task is done
Copilot coding agent	Assign a GitHub issue to Copilot; it works in the cloud and opens a pull request
Copilot code review	Request Copilot as a reviewer on a pull request for automated feedback
Pull request summaries and commit messages	Drafts descriptions and messages from your changes

Copilot works in VS Code, Visual Studio, JetBrains IDEs, on github.com, in the GitHub mobile app and in the terminal.

---

💳 Plans

Plan	For
Copilot Free	Individuals; a limited monthly number of completions and chat requests
Copilot Pro / Pro+	Individuals who need more usage and premium models
Copilot Business / Enterprise	Organisations, with policy controls and admin features

Verified students, teachers and maintainers of popular open-source projects can get Copilot Pro for free. Limits and prices change, so check GitHub’s Copilot plans page for current details.

---

⚙️ Set Up in VS Code

1. Install the GitHub Copilot extension (Copilot Chat is included).
2. Sign in with your GitHub account and enable a plan (Copilot Free is available to most personal accounts).
3. Start typing to see grey suggestions: Tab accepts, Esc dismisses; Alt + ] shows the next suggestion.
4. Open the chat with Ctrl + Alt + I (Windows/Linux) or Ctrl + Cmd + I (macOS), and switch between Ask, Edit and Agent modes.

---

🧪 Copilot for Testers: Practical Prompts

Good prompts are specific about the tool, style and expectations:

Task	Example prompt
Write a test	“Write a Playwright TypeScript test for the login page in LoginPage.ts: valid login, locked-out user and empty fields. Use getByRole and web-first assertions.”
Generate test cases	“List boundary and negative test cases for the discount code field (max 10 characters, alphanumeric, case-insensitive).”
Create test data	“Generate 10 realistic test users as a TypeScript array matching the TestUser interface.”
Explain a failure	“Explain this Playwright error and suggest a fix” (paste the error and code)
Refactor	“Refactor this test to use the CartPage page object and remove the waitForTimeout.”
Review	“Review this test for flakiness risks.”

Copilot can also work with Playwright MCP in agent mode to explore a live page before writing tests, similar to Playwright Test Agents.

---

🔃 Copilot on GitHub.com

• Pull request summaries: click the Copilot icon in the PR description box to draft a summary (pull requests).
• Code review: add Copilot as a reviewer; it leaves comments and suggestions like a human reviewer (code review).
• Coding agent: assign an issue to Copilot; it pushes commits to a new branch and opens a draft PR for you to review. Treat it like a junior teammate: review everything before merging.

---

⚠️ Using Copilot Responsibly

• Review every suggestion. AI can produce code that looks right but is wrong, insecure or outdated (for example deprecated APIs or hard waits in tests).
• Run the tests. Generated tests must pass, fail when the feature breaks, and be readable.
• Protect secrets and private data. Do not paste credentials or customer data into prompts.
• Respect licences and policies. Organisations can block suggestions matching public code and set policies for which features are allowed.
• You own the result. Copilot is an assistant; the author and reviewers remain responsible for what is merged.

---

📝 Assignment

1. Enable Copilot (Free or another plan) in VS Code.
2. Ask Copilot Chat to explain a test file from your Playwright project.
3. Generate a new Playwright test with a detailed prompt, run it, and fix anything wrong.
4. Ask for boundary and negative test cases for a form field and compare them with your own list.
5. Use Copilot to draft a commit message and a PR description, then edit them to follow Conventional Commits.
6. Bonus: request a Copilot code review on a pull request and decide which comments to accept.

---

❓ FAQ

🤔 What is GitHub Copilot?

An AI assistant from GitHub that suggests code, answers questions in chat, edits files in agent mode, reviews pull requests and can work on assigned issues.

🤔 Is GitHub Copilot free?

There is a Copilot Free plan with limited monthly usage, and free Copilot Pro for verified students, teachers and popular open-source maintainers. Other plans are paid.

🤔 Can GitHub Copilot write Playwright tests?

Yes. With specific prompts and your page objects open as context, it can draft Playwright TypeScript tests, which you must review and run.

🤔 Can Copilot review pull requests?

Yes. You can request Copilot as a reviewer on a pull request to get automated review comments.

🤔 Is it safe to use Copilot at work?

Follow your organisation’s policies, review all output, avoid sharing secrets, and use business plans with admin controls where required.

---

🎯 Next Steps

• 🏗️ Project 1: Team Collaboration Workflow Simulation
• 🤖 AI Tools for QA Engineers
• 📘 Git and GitHub Tutorial: full course

Codespaces gives you a ready-to-code VS Code environment in the cloud, configured by your repository. In this lesson you will create a codespace, set it up with devcontainer.json, run Playwright tests, and keep usage under control.

---

☁️ What Is GitHub Codespaces?

Codespaces gives you a complete development environment in the cloud, opened in VS Code in your browser (or in the VS Code desktop app), in seconds. Each codespace is a container running on a GitHub-hosted virtual machine with your repository already cloned and your tools installed.

Benefit	Why it matters
No local setup	Start contributing on any computer, even a Chromebook or a locked-down laptop
Same environment for everyone	“Works on my machine” problems disappear
Configuration as code	A devcontainer.json in the repo defines tools and extensions
Powerful machines	Choose more CPU and memory for heavy builds
Great for training	Learners open a ready-made environment with one click

---

🚀 Create Your First Codespace

1. Open a repository on GitHub.
2. Click the green Code button, then the Codespaces tab.
3. Click Create codespace on main.

A browser tab opens with VS Code, a terminal and your files. Git is already configured with your GitHub identity:

git status
git switch -c feature/try-codespaces
# edit files...
git commit -am "Try Codespaces"
git push -u origin feature/try-codespaces

---

🧰 Configure the Environment with devcontainer.json

Add .devcontainer/devcontainer.json so every codespace starts with the right tools:

{
  "name": "Playwright TypeScript",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:22",
  "postCreateCommand": "npm ci && npx playwright install --with-deps",
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-playwright.playwright",
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode"
      ]
    }
  },
  "forwardPorts": [9323]
}

Key	Purpose
image	Base container image (or build with a Dockerfile)
features	Add tools such as the GitHub CLI, Docker or Python with one line each
postCreateCommand	Run once after creation (install dependencies and browsers)
customizations.vscode.extensions	Extensions installed automatically
forwardPorts	Ports to forward to your browser (e.g. a report server)

Commit the file; new codespaces use it. For an existing codespace, run Codespaces: Rebuild Container from the Command Palette.

---

🧪 Running Playwright in a Codespace

Codespaces have no physical screen, so tests run headless, which is exactly how they run in CI. To see results:

• HTML report: run npx playwright show-report --host 0.0.0.0; Codespaces forwards the port (9323) and offers to open it in your browser.
• UI mode: run npx playwright test --ui-host=0.0.0.0 --ui-port=8080 and open the forwarded port 8080.
• Traces: open trace.zip files with npx playwright show-trace or at trace.playwright.dev (Trace Viewer).

---

🔌 Ports, Secrets and Settings

• Ports tab: see forwarded ports, open them in the browser, and choose private (default) or public visibility.
• Codespaces secrets (Settings, Codespaces) store values such as TEST_PASSWORD as environment variables inside your codespaces, separate from Actions secrets (secrets).
• Dotfiles: link a dotfiles repository in your settings to apply your personal shell and Git configuration to every codespace.

---

💸 Managing Codespaces and Cost

• Codespaces stop automatically after a period of inactivity (30 minutes by default) and are deleted after a retention period when stopped.
• Stop or delete them from github.com/codespaces when you finish.
• Choose the smallest machine type that works (2 cores is enough for most test projects).
• Stopped codespaces still use storage; delete ones you no longer need.

---

⚖️ Codespaces vs Local Development vs CI

	Local	Codespaces	CI (GitHub Actions)
Interactive editing	✅	✅	❌
Setup effort	Per machine	Once per repo (devcontainer)	Once per workflow
Cost	Your hardware	Free quota, then usage-based	Free for public repos, minutes for private
Best for	Daily work	Onboarding, training, quick fixes, consistent environments	Automated builds and tests

---

📝 Assignment

1. Open a codespace on one of your repositories, make a change, commit and push it.
2. Add a devcontainer.json for a Playwright project with postCreateCommand and the Playwright extension, and rebuild.
3. Run the tests headless and open the HTML report through a forwarded port.
4. Add a Codespaces secret and print whether it is set (not its value) in the terminal.
5. Stop and delete the codespace from github.com/codespaces.

---

❓ FAQ

🤔 What is GitHub Codespaces?

A cloud development environment that runs VS Code with your repository and tools in a GitHub-hosted container, accessible from the browser or VS Code desktop.

🤔 Is GitHub Codespaces free?

Personal accounts get a monthly free quota of usage; usage beyond it is billed. Organisations can pay for their members.

🤔 What is devcontainer.json?

A configuration file in .devcontainer/ that defines the container image, tools, extensions and setup commands for a codespace or dev container.

🤔 Can I run Playwright tests in Codespaces?

Yes, headless. View the HTML report or UI mode through forwarded ports.

🤔 How do I stop a codespace?

It stops after inactivity automatically, or stop it from the Codespaces menu in VS Code or from github.com/codespaces.

---

🎯 Next Steps

• 🤖 GitHub Copilot for Developers and Testers
• 🏗️ Project 1: Team Collaboration Workflow Simulation
• 📘 Git and GitHub Tutorial: full course

GitHub Pages turns a repository into a website for free. In this lesson you will publish a portfolio from a branch, deploy with GitHub Actions, use Jekyll for Markdown sites, connect a custom domain and publish test reports.

---

🌐 What Is GitHub Pages?

GitHub Pages hosts static websites (HTML, CSS, JavaScript and files generated from Markdown) directly from a GitHub repository, with HTTPS and an optional custom domain. It is perfect for:

• Personal portfolios and resumes.
• Project documentation.
• Publishing test reports (for example a Playwright HTML report).
• Demo apps and landing pages.

---

🏷️ Types of Sites and Their URLs

Type	Repository name	URL
User site	<username>.github.io	https://<username>.github.io/
Organisation site	<org>.github.io	https://<org>.github.io/
Project site	Any name, e.g. portfolio	https://<username>.github.io/portfolio/

---

🚀 Option 1: Publish from a Branch (Quickest)

1. Create a repository (e.g. portfolio) with an index.html:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Asha Verma – QA Automation Engineer</title>
  </head>
  <body>
    <h1>Asha Verma</h1>
    <p>QA Automation Engineer · Playwright · TypeScript</p>
    <a href="https://github.com/asha-verma-qa">My GitHub projects</a>
  </body>
</html>

1. Push it to main.
2. Open Settings, Pages. Under Build and deployment, choose Source: Deploy from a branch, branch main and folder / (root) (or /docs), and click Save.
3. After a minute, the page shows “Your site is live at https://<username>.github.io/portfolio/”.

Every push to the branch republishes the site.

---

⚙️ Option 2: Publish with GitHub Actions (Flexible)

Choose Source: GitHub Actions when your site needs a build step (React, Vue, Astro, a documentation generator) or when you want to publish generated files such as test reports. The workflow uses actions/upload-pages-artifact and actions/deploy-pages; a complete example is in Deploy with GitHub Actions.

- uses: actions/upload-pages-artifact@v3
  with:
    path: ./dist            # or ./playwright-report
- uses: actions/deploy-pages@v4

---

📝 Markdown Sites with Jekyll

When publishing from a branch, GitHub builds the site with Jekyll, so a README.md or index.md is turned into HTML automatically, and you can pick a theme in a _config.yml:

# _config.yml
title: QA Notes
description: My notes on Playwright and Git
theme: minima

If your site is plain HTML or uses folders that start with an underscore, add an empty .nojekyll file to skip Jekyll processing. Markdown basics are in Markdown and README.

---

🔗 Custom Domain

1. In Settings, Pages, Custom domain, enter e.g. qa.example.com and save (this creates a CNAME file when publishing from a branch).
2. At your DNS provider, add a CNAME record pointing qa to <username>.github.io (for an apex domain such as example.com, use the A records listed in GitHub’s documentation).
3. Wait for DNS to propagate, then tick Enforce HTTPS.

---

🧪 For Testers: Publish Test Reports

Publishing the Playwright HTML report to Pages after every run on main gives the team a permanent link to the latest results. Only do this for non-sensitive projects: anything on Pages is public. See Playwright in GitHub Actions and reporters.

---

🐞 Troubleshooting

Problem	Fix
404 after enabling Pages	Wait a few minutes; check there is an index.html (or index.md) in the selected folder
CSS or images missing on a project site	Use relative paths; project sites live under /<repo>/, not the domain root
Build fails with Jekyll errors	Check the Actions tab for the “pages build and deployment” run; add .nojekyll if you do not need Jekyll
Custom domain not working	Check DNS records and the CNAME setting; HTTPS can take time to be issued

---

📝 Assignment

1. Create a repository portfolio with an index.html and publish it from main.
2. Create your user site <username>.github.io with a short bio and links to your Playwright and Git projects.
3. Switch a site to GitHub Actions as the source and deploy with a workflow.
4. Publish a sample (non-sensitive) Playwright HTML report to Pages.
5. Bonus: connect a custom subdomain if you own a domain.

---

❓ FAQ

🤔 What is GitHub Pages?

A free GitHub service that hosts static websites directly from a repository, with HTTPS and optional custom domains.

🤔 How do I host a website on GitHub for free?

Push an index.html to a public repository, open Settings, Pages, choose Deploy from a branch (main, root) and save. The site appears at username.github.io/repository.

🤔 Can GitHub Pages run a backend or database?

No. It serves static files only. Use client-side JavaScript or external APIs for dynamic features.

🤔 How do I use a custom domain with GitHub Pages?

Add the domain in Settings, Pages, create a CNAME (or A records for apex domains) at your DNS provider, then enable Enforce HTTPS.

🤔 Can I publish test reports to GitHub Pages?

Yes, by uploading the report folder with upload-pages-artifact and deploy-pages in a workflow, as long as the report contains no sensitive data.

---

🎯 Next Steps

• ☁️ GitHub Codespaces: Cloud Development Environments
• 🤖 GitHub Copilot for Developers and Testers
• 📘 Git and GitHub Tutorial: full course

The GitHub CLI brings pull requests, issues, Actions and releases to your terminal. In this lesson you will install gh, sign in, and use it for the daily tasks that otherwise need the browser, including checking out a developer’s PR to test it.

---

⌨️ What Is the GitHub CLI?

The GitHub CLI (gh) brings GitHub to your terminal. Git manages your repository; gh manages GitHub: repositories, pull requests, issues, Actions runs, releases and more, without opening the browser.

Task	Git	GitHub CLI
Commit, branch, merge	✅
Create a repository on GitHub		gh repo create
Open and merge pull requests		gh pr create, gh pr merge
Check CI runs and logs		gh run list, gh run view --log-failed
Create issues and releases		gh issue create, gh release create

---

📥 Install

Platform	Command
Windows	winget install --id GitHub.cli
macOS	brew install gh
Ubuntu / Debian	Add GitHub’s official apt repository, then sudo apt install gh (see the install instructions on cli.github.com)
Fedora	sudo dnf install gh

Check: gh --version.

---

🔐 Sign In

gh auth login

Choose GitHub.com, your preferred protocol (HTTPS or SSH) and Login with a web browser, then enter the one-time code shown in the terminal. gh can also configure Git to use it as a credential helper, so git push over HTTPS just works.

gh auth status          # who am I and which scopes?

---

📁 Repositories

gh repo create my-tests --private --clone        # new repo on GitHub and clone it
gh repo create --source=. --public --push        # publish the current folder
gh repo clone acme/qa-platform
gh repo fork acme/qa-platform --clone            # fork + clone + upstream remote
gh repo view --web                               # open the repo in the browser

See push an existing project and forks.

---

🔃 Pull Requests

gh pr create --title "Add login tests" --body "Closes #42" --reviewer ravi-kumar --label tests
gh pr create --fill --draft                # title and body from your commits, as a draft
gh pr list                                  # open PRs
gh pr status                                # PRs that involve you
gh pr checkout 57                           # check out PR #57 locally to test it
gh pr diff 57
gh pr review 57 --approve                   # or --request-changes -b "Please add a test"
gh pr checks 57                             # CI status
gh pr merge 57 --squash --delete-branch

---

🐞 Issues

gh issue create --title "Checkout total ignores discount" --label bug --assignee @me
gh issue list --label bug --state open
gh issue view 42 --comments
gh issue close 42 --comment "Fixed in #57"

---

⚙️ GitHub Actions

gh workflow list
gh workflow run ci.yml -f browser=firefox      # trigger workflow_dispatch with an input
gh run list --limit 5
gh run watch                                    # follow the latest run live
gh run view 123456789 --log-failed              # only logs of failed steps
gh run download 123456789 -n playwright-report  # download an artifact
gh run rerun 123456789 --failed                 # re-run failed jobs

These pair with workflow syntax and artifacts.

---

🏷️ Releases

gh release create v1.2.0 --generate-notes            # release from a tag with auto notes
gh release create v1.2.0 ./dist/report.zip --title "v1.2.0"
gh release list

See Git tags and releases.

---

🧰 Power Features

gh api repos/acme/qa-platform/pulls --jq '.[].title'   # call any REST endpoint, filter with jq
gh alias set prs 'pr list --author @me'                  # create shortcuts: gh prs
gh secret set TEST_PASSWORD                              # set an Actions secret (prompts for value)
gh variable set BASE_URL --body https://staging.example.com
gh extension install dlvhdr/gh-dash                       # extensions add new commands (here: a PR and issue dashboard)

Secrets and variables are explained in secrets and environments.

---

📝 Assignment

1. Install gh and log in with gh auth login.
2. Create a new private repository from the terminal with gh repo create.
3. Create a branch, commit, and open a PR with gh pr create --fill; check it with gh pr checks and merge it with gh pr merge --squash --delete-branch.
4. Create and close an issue from the terminal.
5. Trigger a workflow_dispatch workflow with gh workflow run and follow it with gh run watch.
6. Create an alias for a command you use often.

---

❓ FAQ

🤔 What is GitHub CLI?

The official command-line tool gh for working with GitHub: repositories, pull requests, issues, Actions, releases and the API from your terminal.

🤔 How do I install GitHub CLI on Windows?

Run winget install --id GitHub.cli (or download the installer from cli.github.com), then gh auth login.

🤔 How do I create a pull request from the command line?

Push your branch and run gh pr create (add --fill to use your commit messages).

🤔 How do I check GitHub Actions logs from the terminal?

gh run list to find the run, then gh run view <id> --log-failed or gh run watch.

🤔 Is GitHub CLI the same as Git?

No. Git works with repositories and history; GitHub CLI works with GitHub features such as PRs, issues and Actions. You use them together.

---

🎯 Next Steps

• 🌐 GitHub Pages: Host a Website for Free
• ☁️ GitHub Codespaces
• 📘 Git and GitHub Tutorial: full course