Git & GitHub for QA Engineers: A No-Fluff Tutorial

Test automation without Git means tests that only run on your machine, with no CI pipeline, no code review, and no way to collaborate with developers. Every QA automation role requires the same workflow: branch off main, write tests, push to GitHub, open a pull request, and let CI run the suite automatically. This guide covers the 10 commands you'll use daily, the branch-based workflow most teams follow, and how to wire a GitHub Actions pipeline to your test repository.

What Git does

Git tracks changes to files over time. Every change you save ("commit") is recorded with a description, a timestamp, and who made it. You can see the full history of every file, go back to any previous state, and work on changes without affecting the main codebase until you're ready.

For QA engineers: Git is how you save your test work, share it with developers, and run it in CI/CD pipelines. You can't have a CI pipeline without a repository.

Installing Git

Download from git-scm.com and install. During installation, select "Use Git from the command line and also from 3rd-party software."

Run xcode-select --install in Terminal. Git is included.

git --version
# git version 2.44.0

The 10 commands you'll use 90% of the time

Setting up (once)

# Tell Git who you are
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Starting or cloning a repository

# Initialize a new repository in the current folder
git init

# Clone an existing repository from GitHub
git clone https://github.com/username/repository-name.git

For most QA engineers, you'll clone more than init. You'll be joining an existing project.

Checking what changed

# See which files have changes
git status

# See the specific changes in files
git diff

Run git status constantly. It shows you exactly where you are.

Saving your work (the core workflow)

# Stage specific files (add them to the "to be committed" list)
git add tests/login.spec.ts
git add pages/LoginPage.ts

# Or stage all changed files
git add .

# Commit the staged changes with a message
git commit -m "Add login test cases with negative scenarios"

Stage → Commit. That's the save cycle. The message describes what you changed and why.

Syncing with the remote (GitHub)

# Get the latest changes from GitHub
git pull

# Send your commits to GitHub
git push

Working on features (branches)

# Create a new branch and switch to it
git checkout -b feature/add-login-tests

# See all branches
git branch

# Switch to an existing branch
git checkout main

A complete daily workflow

Here's what using Git looks like in practice on a typical day:

# 1. Start the day — get the latest changes
git pull

# 2. Create a branch for your work
git checkout -b test/payment-flow-automation

# 3. Write your tests in VS Code
# ... (tests/payment.spec.ts created/modified)

# 4. Check what changed
git status
# On branch test/payment-flow-automation
# Changes not staged for commit:
#   modified:   tests/payment.spec.ts
# Untracked files:
#   pages/PaymentPage.ts

# 5. Stage the files
git add tests/payment.spec.ts
git add pages/PaymentPage.ts

# 6. Commit with a clear message
git commit -m "Add payment flow tests: happy path and card decline scenarios"

# 7. Push to GitHub
git push origin test/payment-flow-automation

# 8. Open a pull request on GitHub (done in the browser)

GitHub: remote repository hosting

GitHub stores your repository online. The main things you'll do on GitHub:

1. Go to github.com → New repository

2. Give it a name

3. Choose Public or Private

4. Click Create

# After creating the repo on GitHub, connect your local folder to it
git remote add origin https://github.com/yourusername/your-repo.git
git push -u origin main

When you're done with work on a branch, you open a pull request on GitHub. This:

• Shows the changes you made
• Lets teammates review and comment
• Merges your changes into the main branch after approval

For QA engineers on a team: your test code goes through the same review process as developer code. Open a PR, get it reviewed, merge.

.gitignore: what not to track

Some files shouldn't go into Git: build output, secrets, node_modules. Create a .gitignore file in your repository root:

# Node modules (always ignored — install with npm install instead)
node_modules/

# Playwright test results and reports
test-results/
playwright-report/

# Environment files that may contain secrets
.env
.env.local

# OS files
.DS_Store
Thumbs.db

Playwright's npm init playwright@latest creates a .gitignore automatically. Check what's in it before committing.

Branches: why they matter for QA

Branches let multiple people work simultaneously without stepping on each other. Standard naming conventions:

main               # stable, production-ready code
feature/add-search # new feature being developed
bugfix/login-error # bug being fixed
test/checkout-flow # new test being written

The pattern used by most teams:

1. main branch is always stable

2. Everyone creates feature/test branches for their work

3. Work is reviewed in pull requests

4. Approved changes merge into main

5. CI/CD runs automatically when changes hit main

As a QA engineer, you'll create branches for new test suites, test updates, and bug reproductions.

Merge conflicts: what they are and how to fix them

A merge conflict happens when two people changed the same part of the same file and Git can't automatically combine them.

<<<<<<< HEAD
await expect(page.getByText('Success')).toBeVisible();
=======
await expect(page.getByRole('alert')).toHaveText('Success');
>>>>>>> feature/update-assertions

The <<<<<<< HEAD section is your version. The >>>>>>> feature/update-assertions section is the incoming version. You need to pick one (or combine them manually), delete the conflict markers, and commit.

Most conflicts in test repositories are easy to resolve. They happen most in shared files like playwright.config.ts or Page Object files that multiple people touch.

Git log: understanding history

# See recent commits
git log --oneline
# a3f2c1d Add payment tests
# b7e9a04 Fix login page locator after UI update
# c2d1f8e Add item creation test with validation scenarios

# See changes in a specific commit
git show a3f2c1d

# See who last modified each line of a file
git blame tests/login.spec.ts

GitHub Actions: your CI pipeline

Once your tests are in GitHub, GitHub Actions can run them automatically on every push. A basic workflow file:

# .github/workflows/playwright.yml
name: Playwright Tests
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

This is the file that npm init playwright@latest offers to create for you. Once it's in your repository, GitHub runs your tests on every push and pull request. The CI/CD article covers this in depth.

Commands cheat sheet

# Setup
git config --global user.name "Name"
git config --global user.email "email"

# Daily
git status              # see what changed
git pull                # get latest from remote
git add file.ts         # stage a file
git add .               # stage all changed files
git commit -m "message" # save staged changes
git push                # send to remote

# Branches
git checkout -b branch-name   # create and switch
git checkout main              # switch to main
git branch                     # list branches
git merge branch-name          # merge branch into current

# History
git log --oneline              # recent commits
git diff                       # unstaged changes
git show commit-hash           # changes in a commit

FAQ

Both work. VS Code has built-in Git support (the Source Control panel) that covers most daily operations without the command line. GitHub Desktop is another option. Command line is worth learning because you'll encounter it in CI/CD scripts and remote servers, but starting with a GUI is fine.

Git is the version control software that runs locally. GitHub is a website that hosts Git repositories remotely. GitLab and Bitbucket are alternatives to GitHub. Git works without GitHub; GitHub stores and shares your Git repositories.

Be specific. "Add login tests" is weak. "Add negative login tests: wrong password, empty fields, SQL injection" is useful. A good commit message answers: what changed and why (not how, the code shows how).

Don't panic. If you haven't pushed:

git reset HEAD~1  # undo the last commit, keep the changes
git checkout -b my-branch  # create a proper branch
git add .
git commit -m "message"

If you have pushed and your team uses a protected main branch, ask your tech lead. Never force-push to main without team consensus.

Yes, if you committed it before:

git checkout HEAD -- path/to/file.ts

This is one of Git's most useful features. You can recover anything that was ever committed.