Version control systems such as Git and GitHub

Without version control, "fixing a test" usually means overwriting the old file and hoping you don't need the previous version back. Git solves that by keeping every version of every file it tracks: it lets you see exactly what changed, when, and — via a commit message — why, and it lets you undo a bad change safely instead of trying to remember what the code used to look like.

GitHub (or a similar host, like GitLab or Bitbucket) adds sharing and collaboration on top of plain git. It gives your code a home other people can find, clone, and read; it lets someone suggest a change via a pull request — a proposed diff you can discuss, review, and merge (or not) — rather than just emailing a new copy of a file back and forth.

This isn't abstract for this site: every demo repo linked from this site's examples and about pages is a real, public git repository. You can clone any of them and read the full history of how that testing code came to look the way it does — that's not incidental, it's how real testing code actually gets managed.

Learn more at git-scm.com and GitHub's own "Get started" docs, or watch GitHub's own "A brief introduction to Git for beginners" for a video introduction.

Examples you can ask AI

I've never used git before — what does 'committing' and 'pushing' actually mean, in plain terms, and why do I need either one just to write a test script?
I accidentally committed a change I want to undo — what's a safe way to undo it without losing other work?
How should a team structure git branches and pull requests specifically around test code, so a flaky or broken test doesn't block unrelated changes?