Git review for testers: workflow, alternatives and pitfalls

Git stores content as objects named by a hash of their contents: blobs for file contents, trees for directories, and commits that point to a tree and to their parent commits. A commit is a snapshot of the whole project, not a diff, and identical files are stored once however many commits contain them. Because names come from content, history cannot change silently: editing an old commit changes its hash and the hash of every commit after it. That is why a rebase produces new commits, why a rebased branch needs a force push, and why everyone who already pulled the old commits ends up with diverged history.

A branch is a name pointing at one commit, and HEAD records which branch you are on. Creating a branch costs nothing, and committing moves the current branch forward to the new commit. A merge either fast-forwards the pointer or creates a commit with two parents; a rebase replays your commits on top of another branch. Remote-tracking branches such as origin/main record what the remote looked like at your last fetch, which explains the most common confusion: Git does not know a colleague pushed until you fetch, so “up to date” in git status means up to date with your last fetch.

Git commits what is in the index, the staging area, not what is in your working files. git add copies the current content of a file into the index; editing the file again afterwards changes nothing that will be committed until you add it again. That is what makes selective commits possible, such as committing a page object fix without the debugging lines next to it. git diff compares your files with the index and git diff --staged compares the index with the last commit, so reading the staged diff before committing is the habit that keeps stray changes out of test commits.

A clone copies every object, so committing, branching, viewing history and diffing need no server. Push and fetch exchange objects between repositories, and the hosting service is simply a shared repository with access control, pull requests and CI attached. CI often cuts corners here: actions/checkout fetches a single commit by default, which is fast but leaves no history, so anything that compares against the base branch, describes a version from tags or blames lines needs a deeper fetch. Partial clone, with --filter=blob:none, is the middle ground for large repositories: full history, with file contents downloaded only when needed.

Whether tests live in the application repository or their own, two committed files prevent most of the noise. The .gitignore keeps generated output out: reports, traces, screenshots, videos, downloaded browsers and dependency folders. The .gitattributes normalises line endings, so a suite edited on Windows and macOS does not show every line as changed, and marks binary fixtures so Git does not attempt to diff them. Keep test data that must be versioned small and text-based where possible, such as JSON or CSV fixtures, and generate large data sets in setup instead. A short CONTRIBUTING file with the branch naming and commit message convention saves repeating the same review comments.

Short-lived branches merged into main within a day or two cause the fewest problems for test code, because tests depend on the application’s current behaviour and a test branch that lives for weeks is written against an application that no longer exists. Name branches by intent, such as test/ for test-only work and fix/ for test fixes, keep each pull request to one concern, and, where the team allows it, ship the test change in the same pull request as the feature it covers. Rebase your branch onto main before review so the reviewer sees only your changes, but never rebase a branch someone else is also working on; merge main into it instead. When you must force push your own branch, use --force-with-lease, which refuses if the remote has commits you have not seen.

actions/checkout fetches only the triggering commit by default, so any step that compares a branch with its base fails or silently compares nothing. Set fetch-depth: 0 when a job needs history: selecting changed specs, generating a changelog, or deriving a version with git describe. For pull requests, GITHUB_BASE_REF names the target branch, and the three-dot diff compares your branch with the point where it left the base, so changes merged to main since then are not included. Use this to run the specs a change touched first for fast feedback, and keep the full suite on main or nightly so nothing slips through.

When a test that used to pass now fails and nobody knows why, bisect is faster than reading the log. Mark the current commit bad and the last known passing release good, then hand Git a command that exits 0 when the test passes and 1 when it fails. Git checks out the midpoint, runs the command and halves the range until one commit remains. Build or install failures should exit 125 so Git skips those commits rather than blaming them. Run only the one failing test, not the suite, so each step takes seconds, and make sure the test is deterministic first: a flaky test sends bisect to a random commit.

Decide how binary test assets are stored before they accumulate, because removing them from history later means rewriting it for everyone. Git LFS replaces large files in the repository with small pointer files and stores the content on the hosting service, which keeps clones fast; git lfs lock gives exclusive editing of a file, which is the only practical way to share binary assets that cannot be merged. Every machine and CI job needs Git LFS installed, or it checks out pointer files instead of the real content. For repositories that are large because of size and history rather than binaries, a partial clone with a sparse checkout lets a test job fetch only what it needs.