What Is Version Control and Why Testers Need It

You have been here. A folder called tests/ contains login-tests.js, login-tests-final.js, login-tests-final-v2.js, and login-tests-REALLY-final.js. None of them work and nobody remembers why. This lesson is about the system the entire software industry has agreed to use instead — version control — and why every QA engineer needs to be fluent in it from day one.

What version control actually is

Version control is software that tracks every change to every file in a project. Each saved snapshot — called a commit — records who changed what, when, and why. You can scroll backwards through that history, jump to any previous snapshot, and bring it back. Think of it as an unlimited, reliable undo for an entire project, not just one file.

Once you have history, you also have branches — parallel versions of the project where two people can work on different things at once and merge their work later without overwriting each other. And once you have branches, you have a way for your team to review changes before they hit the shared codebase. All of this is what version control quietly gives you.

The most popular version control system by an enormous margin is Git. Virtually every software team in the world uses it. Learning Git is not optional for modern QA work — it is the file system of your professional life.

Why QA engineers specifically need Git

Twenty years ago, testers wrote test plans in Word documents. Today, your test artefacts are code, and code lives in Git:

• Your automation code lives in Git — Cypress specs, Playwright fixtures, page objects, helper utilities. They sit in the same repository as the application itself, or in a sibling repo your team owns.
• You pull the latest code to test against it. Every morning your routine starts with git pull. The new build you're testing came from a Git commit; the build you tested yesterday is one commit away.
• You collaborate with developers through Git. They open pull requests for new features; you review them. You open pull requests for new tests; they review yours. The conversation happens on the diff.
• CI/CD runs your tests from Git. Every commit triggers a pipeline that checks out the repo, installs dependencies, and runs your test suite. If your tests aren't in Git, CI can't run them.
• Test data, configurations, and scripts all belong in Git. Fixture JSONs, .env.example files, GitHub Actions workflows, package versions — all version-controlled, all reviewable, all recoverable.

A QA engineer who cannot navigate Git is locked out of half the daily workflow.

Distributed, not centralised

Older systems (CVS, Subversion) were centralised — there was one server, and every operation talked to it. If the server was down, you couldn't commit. If you were on a plane, you couldn't see history.

Git is distributed. When you clone a repository, you get the full project including its complete history on your laptop. Commits, branches, and history operations all happen locally — the network is only involved when you push your work up to GitHub or pull someone else's down. This is why Git feels fast, and why you can keep working offline.

The vocabulary preview

You'll meet these words constantly. A quick map:

• Repository (repo) — a project folder tracked by Git. The .git subfolder inside it stores the entire history.
• Commit — a saved snapshot, with a message describing the change.
• Branch — a parallel line of development. main is the default; you'll create your own (add-login-tests) to work in isolation.
• Merge — combining the changes from one branch into another.
• Remote — a hosted copy of the repo (typically GitHub). You push your local commits up and pull other people's down.
• Pull request (PR) — a proposal to merge a branch's changes into another branch, opened on GitHub for review.

Don't memorise these — they'll re-appear in every lesson and stick by repetition.

Day 1 on a real team

Picture your first day as a QA engineer at a new company. The lead hands you a laptop and says: "Clone the repo, install dependencies, and run the tests. Then create a branch, fix the flaky search test on line 42, and open a PR. We'll review it after lunch."

That single sentence touches almost every concept you'll learn in this course — clone, branch, commit, push, pull request, code review. By the end of Chapter 3 you'll execute that whole sequence from muscle memory. For now, let's see how the pieces fit together.

The Git ecosystem at a glance

⚠️ Common mistakes

• Treating Git as just "the upload tool." Beginners think Git is for sending files to GitHub. It isn't. Git is a history database; GitHub is one place that database can be hosted. Many things you'll do (log, diff, branch, commit) never touch the network at all.
• Calling everything "the repo" without naming it. "The repo" might mean your local clone, the GitHub remote, or a specific branch. Be precise — local vs remote vs branch — when you ask questions; the right answer depends on which one you mean.
• Avoiding Git in favour of zipping folders. Every "let me just zip this and email it" reflex is a place Git would have done the job better. Resist the urge — using Git on every project, even tiny solo ones, is how it becomes second nature.

🎯 Practice task

No commands yet — just orientation. 15 minutes.

1. Open three real software projects on GitHub — for example github.com/cypress-io/cypress, github.com/microsoft/playwright, and github.com/jestjs/jest. For each, find the Commits view and scroll. Notice every change has an author, a date, and a message.
2. On any one of them, click the Branches tab. Count how many branches the project has open. (Big projects often have hundreds.)
3. Open the Pull requests tab on the same repo. Click into one open PR. Read the description, the file diff, and the review comments. This is what your team's daily Git collaboration looks like.
4. Bookmark the Git for QA cheat sheet — you'll come back to it as a quick reference once you start typing commands in the next lesson.

The next lesson installs Git on your machine and configures it, so the rest of the course can be hands-on.