Git, branching and pull-request review
Not just commit and push. Rebasing, resolving conflicts, reading history to find when something broke, and leaving review comments that change the code. Testing work now arrives and departs as pull requests.
Most QA engineers use git as a place to pull code from, not a tool that answers questions during testing. That is a missed opportunity, because git history often explains why a bug exists faster than reading the current code does, and pull request review is one of the highest-leverage places a tester can catch a problem before it ships. This guide covers both: git as an investigation tool, and PR review as a QA discipline in its own right.
Git as an investigation tool, not just a delivery mechanism
git blame shows who last touched a line and in which commit, which turns "why does this code do this weird thing" into an answerable question instead of a guess. Following the trail back from a blame result to the actual commit message and its linked ticket often surfaces the original bug report or edge case the code was written to handle, context that has usually vanished from any comment in the code itself.
git bisect is the more powerful tool for QA specifically: given a known-good commit and a known-bad one, it automates a binary search through history to find the exact commit that introduced a regression. This turns "somewhere in the last three weeks of commits" into a fifteen-minute automated search, provided you have a reliable way to script the pass/fail check bisect runs at each step.
git bisect start
git bisect bad HEAD
git bisect good v2.4.0
# Runs the test script at each candidate commit automatically
git bisect run npm test -- --grep "checkout total"Reading commit history as risk signal
A commit history with small, focused commits and clear messages is easier to test against, because each commit describes one intended change you can verify in isolation. A history full of "wip," "fix," and "more fixes" squashed together tells you the change was iterated on live, possibly without a clear plan, which is itself a signal to test more broadly rather than trust the diff's stated scope.
Reviewing a pull request as a QA task
Reviewing a pull request is a different activity from reading a codebase and a diff in isolation, because a PR carries extra context: the description, the linked ticket, prior review comments, and CI status, all of which change how much scrutiny a change needs.
A few checks worth making standard practice before approving from a QA seat:
- Does the description match the diff: a PR titled "fix typo" that touches business logic is a mismatch worth a direct question, not a rubber stamp.
- Is CI actually green, not just not-red: a skipped or flaky test marked as passing is not the same as a test that ran and passed.
- Did test coverage change proportionally to the risk: a change to payment logic with zero new or modified tests is a gap worth naming explicitly in review, even if the author is confident.
- Are review comments resolved, not just replied to: a reviewer raising a concern that gets a reply but no code change is an unresolved risk, regardless of how the thread looks in the UI.
A worked example: bisect finding what code review missed
A mobile team shipped a release where a small percentage of users reported the app crashing on startup, but only on older Android devices, and only intermittently. Consider a scenario nobody could reproduce locally: the pull requests merged in the release window all looked unrelated to startup behavior, since none of them mentioned it.
The QA lead used git bisect against a nightly build pipeline, scripting the check as "install this build on a farm of older test devices, launch the app, check for a crash within ten seconds." Bisect converged on a PR that had added a new analytics SDK initialization call during app startup, buried inside a change whose description only mentioned adding a new dashboard event.
The SDK's initialization blocked the main thread briefly on older, slower devices, long enough to occasionally trip a watchdog timer. The original PR review had approved it because the diff was small and the description sounded low risk. The fix was to move the SDK initialization off the main thread, and the team added a rule to their review checklist: any change touching app startup gets explicit device-tier testing regardless of how small the diff looks.
FAQ
Questions people ask
Do I need write access to a repo to use git bisect for investigation?
No, bisect works on a local clone with read access, as long as you can check out commits and run your test script against each one.
How specific does a pass/fail script need to be for git bisect run?
It needs to exit with a non-zero code on failure and zero on success, nothing more. A single targeted test or a short shell script wrapping a manual check both work.
Should QA block a pull request over an unclear commit message alone?
Not by itself, but it is a fair reason to ask a clarifying question, especially if the change also lacks test coverage or touches shared code.
What is the fastest way to check if CI is genuinely green versus falsely green?
Open the CI run directly and check for skipped or flaky-retried tests, not just the overall pass/fail badge, which can hide individual skipped steps.