Lesson 1 of 85 min read
Why QA engineers need Git
Automation code, test data and even test cases live in Git. Every team expects testers to use it.
Key takeaways
- 1Git tracks every change to files, so you can see who changed what and go back in time.
- 2GitHub (or GitLab, Bitbucket) hosts the repository online so the team can share it.
- 3Testers use Git to store test suites, review developer changes and check which build has a fix.
Set up once
git --version
git config --global user.name "Asha Rao"
git config --global user.email "asha@example.com"
Go deeper
Expert notes beyond the basics
- 01
What actually lives in a test repository
A typical QA repository holds automation scripts (spec files), page objects or helper functions, test data fixtures, configuration files for different environments, and a .gitignore file. It does not hold node_modules, generated reports, screenshots from a failed run, or secrets like API keys. Keeping the repository lean this way means clones are fast and nobody accidentally commits a password. Knowing this structure before your first day on a team makes you look experienced in interviews and lets you navigate an unfamiliar repo quickly.
- 02
Why git log is a tester's best friend
Run git log --oneline --graph --all to see a compact history of every branch and commit. This is useful when a bug appears and you need to know what changed recently: git log -p -- src/checkout.ts shows the actual code changes to one file over time, and git log --since="2 days ago" filters by date. Instead of asking a developer 'what changed', you can answer it yourself in seconds, which saves everyone time and builds trust with the team.
- 03
Centralised vs distributed version control
Older tools like SVN kept one central copy of history on a server; every commit needed network access. Git is distributed: every clone has the full history, so you can commit, branch and review log entries offline, then sync later with push and pull. This is why Git clones can be large on first download but every later operation, like switching branches or viewing history, is instant and local.
- 04
Git in a CI/CD pipeline
Git is the trigger for almost every pipeline. A push or pull request fires a webhook that starts a CI job: the pipeline checks out the exact commit, installs dependencies, runs unit tests, then automated UI and API tests, and reports pass or fail back on the commit itself as a status check. Testers should understand this flow because when a pipeline fails, the first question is always 'which commit broke it', and Git's history is how you answer that.
Common mistakes to avoid
- - Assuming Git is 'a developer tool' and refusing to learn it, then struggling to find which build introduced a regression.
- - Cloning a repository and immediately editing files on main instead of creating a branch first.
- - Not configuring user.name and user.email, so commits show up under a generic or wrong author.
- - Confusing 'installing Git' with 'creating a GitHub account' - they are two separate things, a local tool and a hosting website.
Git basics cheat sheet
Keep this nearby for your first week using Git as a tester.
| Command | What it does | When QA uses it |
|---|---|---|
| git --version | Shows the installed Git version | Confirming Git is installed before setup |
| git config --global user.name/email | Sets the name and email attached to your commits | Once, when setting up a new machine |
| git clone <url> | Downloads a repository with full history | Getting the team's automation repo for the first time |
| git log --oneline | Shows a short list of commits | Checking what changed before testing a build |
| git status | Shows what files changed and are staged | Before every commit, to avoid committing the wrong files |
Try it yourself
Set up Git on a fresh machine and create your first local repository called qa-practice with one commit.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
How do you use Git as a tester?
Model answer
I keep automation code in a Git repository, work on branches, open pull requests for review, and look at commit history and pull requests to understand what changed in a build before testing it.
- Q2
What is a repository?
Model answer
A folder tracked by Git that stores all the files plus the full history of changes to them, including who changed what and when. It can live only on your machine or also be pushed to a hosting service like GitHub so a team can share it.
- Q3
Is Git the same as GitHub Desktop or VS Code's source control panel?
Model answer
No. Git is the underlying command-line tool. GitHub Desktop and VS Code's Git panel are graphical interfaces that run Git commands for you. Knowing the actual commands matters because not every environment, like a CI server, has a graphical tool available.
- Q4
Why would a QA engineer need commit history instead of just asking the developer?
Model answer
Developers move fast and may not remember every change, especially weeks later. Commit history is an exact, timestamped record: you can see precisely which lines changed, in which commit, by whom, and read the message explaining why. It is faster and more reliable than relying on memory.
Knowledge check
+5 points
What is the difference between Git and GitHub?