Learning Objectives
By the end of this lesson you will be able to:
- Explain what version control is without using the word "developer"
- Name three QA artifacts that belong in a repository
- Describe what a commit records beyond the file contents
- Recognize the everyday failures that version control eliminates
The Problem, Before the Tool
Open any team's shared drive and you'll find the same graveyard:
regression-suite.xlsx
regression-suite_v2.xlsx
regression-suite_v2_FINAL.xlsx
regression-suite_v2_FINAL_olena_edits.xlsx
regression-suite_USE_THIS_ONE.xlsx
Every one of those files is a failed attempt to answer four questions: What changed? When? Who did it? Can I get the old one back?
Version control answers all four, permanently, without anyone having to remember to type _FINAL.
What Version Control Actually Is
A version control system records the history of a set of files. Not a copy — a history. At any moment you can ask it: show me this project exactly as it was three weeks ago, and it will hand that to you, then put everything back the way it was.
Git is the version control system that won. It's on virtually every software project on earth, it's free, and it runs entirely on your machine until you decide otherwise.
The unit of history in Git is a commit: a snapshot of the project at one moment, plus four things a filename can never carry —
- who made the change (name and email)
- when they made it (exact timestamp)
- why they made it (the commit message)
- what exactly changed, line by line
That last one is the tester's superpower, and we'll spend a whole module on it.
Why This Matters for QA Specifically
It's tempting to file Git under "developer tools". Here's why that's a mistake.
You test what's in the repository. The build on your test environment came from a specific commit. When you file a bug, "reproduced on commit a3f9c21" is an unarguable fact; "reproduced on the Tuesday build" is a conversation.
Your own artifacts have versions too. Test plans, test cases, checklists, environment configs, API request collections, automation scripts, saved test data. Every one of these changes over time, and every one of them has at some point been lost, overwritten, or silently reverted by a colleague. All of them belong in a repository.
It's how you find out what to test. A release note says "bugfixes". The repository says exactly which twelve files changed. One of those is a rumor; the other is evidence.
It's a hiring requirement. Look at any QA job posting — manual or automation. Git is on it. Not because you'll be writing features, but because you're expected to work inside the same workflow as everyone else on the team.
The difference, side by side:
SHARED DRIVE GIT HISTORY
──────────────────────────────── ────────────────────────────────────
regression-suite.xlsx 4f2a1c9 Add CVV boundary cases
regression-suite_v2.xlsx 91bd4e7 Update staging DB connection
regression-suite_v2_FINAL.xlsx c7f0a12 Remove flaky checkout wait
regression-suite_FINAL_olena.xlsx 4e9d331 Document BUG-441 repro steps
regression-suite_USE_THIS_ONE.xlsx 0b2c8a5 Add payments smoke checklist
Which one is current? Which one is current?
Ask around. The top one.
Who changed what, and why? Who changed what, and why?
Nobody knows. Every line above says so.
Can I get Tuesday's version? Can I get Tuesday's version?
Only if someone kept a copy. Yes. Always.
Both columns hold the same work. Only one of them can answer a question.
What Git Is Not
Two clarifications that save beginners weeks of confusion:
Git is not GitHub. Git is the tool on your computer. GitHub (and GitLab, and Bitbucket) are websites that host copies of Git repositories so teams can share them. You can use Git for months without ever touching GitHub — we do exactly that for the first three modules of this trail.
Git is not a backup system. It records the changes you tell it to record, when you tell it to. Nothing is in your history until you commit it. That's a feature — you decide what's worth remembering — but it means an uncommitted file is exactly as safe as any other unsaved file. Which is to say: not.
Pro Tip: Start a repository for your own test documentation this week, even if nobody asked you to. It's the fastest way to learn Git, and the first time you recover a checklist you thought you'd deleted, you'll never work any other way.
Key Takeaways
- Version control records a project's history — what changed, when, by whom, and why
- A commit is a snapshot plus authorship, timestamp, message, and a line-by-line record of the change
- Test plans, checklists, configs, and automation scripts all belong in a repository, not on a shared drive
- Git runs locally and is separate from GitHub, which merely hosts shared copies
- Nothing is protected until it is committed — Git is not an automatic backup