Git for testers

Treat your test changes as reviewable product changes: small commits, a readable diff and a clear reason. This Bash lab was run on Linux with Git 2.53.0. All names and addresses are fake. Use one terminal and execute every block in order.

1. Start a disposable repository

lab=$(mktemp -d /tmp/qa-git-XXXXXX)
cd "$lab"
git --version
git init -b main
git config user.name 'QA Example'
git config user.email '[email protected]'
git config commit.gpgsign false
printf 'Login: valid credentials succeed\n' > cases.txt
git status --short
git add cases.txt
git diff --cached
git commit -m 'Record login happy path'

The local config affects only this repository. status initially shows ?? cases.txt: an untracked file. add selects the current file content for the next commit; diff --cached shows that selection. Editing again after staging does not automatically stage the later edit.

2. Add a negative test on a branch

git switch -c test/login-negative
printf 'Login: wrong password is rejected\n' >> cases.txt
git diff
git add cases.txt
git diff --cached
git commit -m 'Add wrong-password case'
git switch main
git merge --ff-only test/login-negative
git log --oneline -3
cat cases.txt

Both cases now appear on main. The fast-forward works because main has not diverged. --ff-only refuses a merge when a fast-forward is impossible; it does not resolve conflicts for you. On a team, follow the repository's pull request process before integrating changes.

3. Unstage without losing your work

printf 'Scratch note: investigate later\n' >> cases.txt
git add cases.txt
git restore --staged cases.txt
git diff --cached
git diff

The cached diff is empty but the ordinary diff still shows the note. That is the distinction between the index (next commit) and the working tree (files you edit).

The next command deliberately discards only the uncommitted scratch note in this lab. Inspect the diff first; do not use it on work you want to keep.

git restore cases.txt
git status --short

The status output is empty. The two committed cases remain.

4. Undo a committed mistake with a new commit

printf 'Login: wrong password succeeds\n' >> cases.txt
git add cases.txt
git commit -m 'Introduce a deliberately wrong expectation'
git revert --no-edit HEAD
git log --oneline -3
cat cases.txt
test "$(wc -l < cases.txt)" -eq 2
git status --short

The new revert commit reverses the last commit; the wrong expectation remains visible in history, with its correction. The line-count check succeeds and status is empty. This makes the correction easy to audit.

Explain it in an interview

“I put the new negative test on a branch, inspected the diff and committed the relevant file. I verified how the branch integrated with main. When an expectation was wrong after committing, I reverted it with a new commit so reviewers could see both the mistake and the correction.”

Follow-up: what if the revert conflicts? Stop and reconcile the intended test behaviour with the intervening changes; a conflict is not evidence that either side is correct. Conflict resolution and remote collaboration are outside this local lab.

The common mistake is staging every file without reviewing the staged diff. Generated results and local configuration often do not belong in the change. This exercise creates no remote, so the temporary repository can be deleted when finished.