Git for QA engineers: the 20% you actually need

Git for QA engineers is a short list. Developers need the whole tool; we need the 20% that answers two questions: what changed, so we can target our testing, and which exact version am I looking at, so our bug reports mean something. Everything below is a command I actually run, learned while keeping a Maestro test workspace alive inside a busy mobile repo.

The Git survival basics

Three commands cover daily life. git clone <url> copies the repo to your machine once. git pull updates it. git checkout -b qa/fix-login-flow creates a branch when you want to change something, like a test script, without touching anyone else's work. If you can clone, pull, and branch, you can already work inside the repo instead of around it.

Finding what changed, so you know what to test

This is the part that changed how I plan testing. When a build lands, don't ask the developer what to check. Ask Git:

git log --oneline v2.3.0..HEAD
git diff v2.3.0..HEAD --stat

The first command lists every commit since the last release tag. The second shows which files changed and by how much. If the diff is all in the payments module, that's where my exploratory time goes, and the sanity pass over everything else can stay light. Risk-based testing gets a lot easier when the risk is listed for you.

git blame <file> shows who last touched each line and when. I don't use it to point fingers; I use it to find the right person to ask "what was this change for?" before writing a confused bug report.

Checking out the exact release build

Bugs get reported against releases, and releases are tags. To see the code, or run the automation suite, exactly as it shipped:

git fetch --tags
git checkout v2.3.0

Git will warn about a "detached HEAD," which sounds alarming and isn't. It just means you're viewing a snapshot rather than sitting on a branch. Look around, run what you need, then git checkout main to come back. Reproducing a customer bug on the tag they actually have beats guessing from the latest build every time.

Bisect: finding when a regression started

git bisect is the most underrated command in QA. You tell Git one commit where the bug exists and one where it didn't, and it walks you through a binary search:

git bisect start
git bisect bad HEAD
git bisect good v2.3.0

Git checks out the middle commit; you build, test, and answer git bisect good or git bisect bad. Repeat a few times and it names the exact commit that introduced the regression. A hundred commits takes about seven rounds. A bug report that says "broken since commit a1b2c3d" gets fixed in hours, because the developer already knows where to look.

Keep your test code in the repo

My Maestro flows live in the same repository as the app, not in a folder on my machine. That one decision does a lot of quiet work: tests are versioned alongside the features they cover, checking out a release tag gives you the matching tests for free, test changes go through pull requests where developers can review them, and CI can find everything it needs in one place. If your test scripts currently live in a shared drive, moving them into the repo is the highest-value Git thing you can do this week.

None of this requires understanding Git's internals. It requires treating the repo as what it is for a tester: a complete, honest changelog of everything that might have broken.