Git & the Command Line

1 The Hook

Mere had just written her first proper batch of automated tests for a Dunedin council web app — a week of work, twelve solid tests. She kept them in a folder on her laptop. On Friday she tidied up, renamed some files, deleted a couple she thought were duplicates, and saved over an old version to “keep things clean.” On Monday she realised two of the tests she had deleted were the only ones covering a tricky rates-payment edge case. They were gone. No recycle bin, no backup, no way to get them back. A week’s thinking, lost to a Friday tidy-up.

Across the room, a developer shrugged when she explained. “If they were in Git, you’d just roll back.” Every change he made to code was recorded — every version saved, every deletion reversible, every line traceable to who wrote it and why. He could stand on any point in the project’s history and walk back to it. Mere had been treating test code like a Word document; he was treating it like code, with a full, undoable history.

There was a second problem she had not even noticed yet. Her tests lived only on her laptop. Nobody else on the team could run them, review them, or build on them. The moment test work becomes a team asset — shared, reviewed, run on a build server — it has to live somewhere central, and that somewhere is a Git repository.

Here is the lesson hidden in that story: as soon as your tests are code, “a folder on my laptop” is not good enough. You need version control to track and undo changes, and a shared repository so the team can work together. Git gives you both, and you reach it through the command line. That is what this lesson teaches.

2 The Rule

3 The Analogy

4 The Terminal — Getting Around

The terminal (also called the command line) is a text window where you type commands instead of clicking. It feels intimidating at first, but for our purposes it is just a way to move between folders and run Git. The two commands you need to get around are tiny:

A typical opening move when you sit down to work looks like this — read it as “list what’s here, move into the tests folder, confirm where I am, list again”:

That is the whole of “getting around.” You move into the project folder with cd, check what is there with ls, and from inside that folder you run Git. You do not need to be a terminal wizard — you need to navigate to your project and back.

5 Why Version Control Matters for Test Code

Version control is a system that records every change to a set of files over time. Git is by far the most common one. For a tester moving into automation, three things make it non-negotiable the moment your tests become code:

• Nothing is lost. Every saved change (a commit) is kept forever. Deleted a test by mistake on a Friday? Roll back to Thursday. Mere’s whole disaster simply does not happen with Git.
• The team shares one source of truth. The tests live in a central repository everyone clones, so the whole team runs the same tests, reviews each other’s changes, and never wonders whose laptop has the latest version.
• Every change is traceable. Each commit records who made the change, when, and why (the commit message). When a test starts behaving oddly, you can see exactly what changed and who to ask — the hut logbook, signed and dated.

There is a fourth reason that arrives quickly: automated tests usually run on a build server (continuous integration). That server gets the tests from the shared repository — not your laptop — so if your tests are not in Git, the automation pipeline cannot even see them.

6 The Core Git Commands

You can do a great deal of day-to-day work with just six commands. Here they are in the order you naturally meet them, with what each one actually does:

The everyday rhythm is: pull to get up to date, do your work, add the files you changed, commit them with a clear message, then push to share. The one part that surprises newcomers is the two-step save: you add (choose what goes in) and then commit (save it). That separation lets you commit just the files you mean to, not every stray change in the folder.

7 Reading git status

git status is the command you will run more than any other, because it answers “what have I changed and what happens next?” Learning to read its output is the single most useful Git skill for a beginner. Here is a typical example after a morning’s work:

Read it from the top: you are on a branch called rates-payment-tests and you are level with the shared copy. Then three groups of files, which is the whole point of status:

• Changes to be committed — files you have added (staged). These will be saved when you next commit. Here, login.spec.js.
• Changes not staged for commit — files you changed but have not added yet. They will not be in the next commit until you add them. Here, payment.spec.js.
• Untracked files — brand-new files Git has never seen. They are not in version control at all until you add them. Here, the new refund.spec.js.

So to save all three, you would git add . to stage the two unstaged files, then git commit -m "...". Reading this output correctly is how you avoid the classic beginner trap of committing and pushing, then wondering why a file you changed never made it — you never staged it.

8 Branches — Working Safely

A branch is your own parallel copy of the project where you can work without disturbing anyone else. The team keeps a main branch (often called main) that holds the agreed, working version. When you start a piece of work, you make a branch off it, do your changes there, and only merge back into main once it is reviewed and working.

Why this matters for a tester: branches mean your half-finished test work never breaks the shared main branch that other people and the build server rely on. Your changes stay isolated until they are ready. It is the same instinct as testing in a safe environment rather than poking production — do your risky work somewhere it cannot hurt anyone, then merge once it is sound.

9 Common Mistakes

10 Now You Try

Three graded exercises — spot it, fix it, build it. Write your answer, run it for AI feedback, then compare to the model answer.

search.spec.js is: STAGED — it has been git add-ed and will be included in the next commit.

filter.spec.js is: MODIFIED BUT NOT STAGED — it has been changed, but not git add-ed yet, so it will NOT be in the next commit until it is added.

sort.spec.js is: UNTRACKED — a brand-new file Git has never seen. It is not in version control at all and will not be committed until it is added.

Commands to save all three:
git add .                          (stages filter.spec.js and the new sort.spec.js; search.spec.js is already staged)
git commit -m "Add sort tests and update search and filter specs"
git push                           (to share with the team)

Key point: if you committed right now WITHOUT git add ., only search.spec.js would be saved — the other two would be silently left out. That is the classic beginner trap, and reading git status is how you catch it.

What's wrong:
- Tests live in a desktop folder, not a Git repo — no history, no sharing, the build server can't see them, and a stray delete loses them for good.
- Working straight on main — half-finished work can break the shared, agreed version everyone relies on.
- Vague commit message ("stuff") — tells the team nothing later.
- Never staging properly / never running git status — likely commits the wrong files or misses changes, with no check of the state.
- Never pushing — nobody else ever gets their work; it only exists locally.
- Never pulling — they fall behind the team's latest changes and will hit conflicts.

Correct daily workflow (in order):
1. git pull                              — get the team's latest changes first.
2. git checkout -b login-tests           — make a branch named after the work, so main stays safe.
3. ... write tests ...  then  git status — check what changed before saving.
4. git add .  then  git commit -m "Add login tests for locked-account case"  — stage, then save with a clear, why-focused message.
5. git push                              — share the branch for review.

Core idea: code in Git, work on a branch, status before commit, clear message, push to share, pull to stay current.

A. git clone https://git.example.nz/msd-tests.git

B. cd msd-tests

C. git checkout -b eligibility-tests

D. git status

E. git add .
   git commit -m "Add eligibility tests for income-threshold cases"
   git push

Marking guide: full marks for the right command on each line. Common slips: forgetting cd into the folder (B) before running Git; trying to commit without git add first (E); a vague commit message instead of a why-focused one. The whole sequence A→E is a realistic first day on a new test repo.

11 Self-Check

Click each question to reveal the answer.

12 Interview Prep

Real questions asked in NZ QA interviews for junior automation roles. Read the model answers, then practise your own version.