Commit
// Definition
A saved snapshot of changes in a Git repo, with a message describing what changed and a unique hash identifying it. Commits are the atomic unit of history — each one is a revertible, reviewable point you can return to. Good commits are small and focused; the message explains why, not just what.
// Why it matters
Commits are the unit QA reads when bisecting a regression ("which commit broke this test?") and the unit CI runs against. A clean commit history makes git bisect find a breaking change in minutes; a messy one (giant commits, vague messages) makes root-causing a failure far harder.
// How to test
git add tests/login.cy.ts git commit -m "test: cover login lockout after 5 failed attempts" # one logical change per commit → bisectable, revertable, reviewable git bisect start # later: find which commit broke a test
// Common mistakes
- Giant commits bundling unrelated changes (un-bisectable, un-revertable)
- Vague messages ("fix stuff") that explain nothing six months on
- Committing secrets/credentials (they persist in history even if deleted later)
// Related terms
Branch
An independent line of development in a Git repository — a movable pointer to a commit, letting you work on a feature or fix in isolation without touching the main line. Branches are cheap and disposable; the typical flow is branch off `main`, commit work, open a pull request, merge back.
Pull Request
A proposed set of commits opened for review before merging into a shared branch — the gate where code is reviewed, CI runs, and approval happens. Called a Merge Request on GitLab. The PR is where automated tests, linting, and human review converge before code reaches `main`.