Version Control

Version control (or source control) is a system for recording changes to a set of files over time so that specific versions can be recalled, compared, and restored later, and so multiple people can work on the same codebase without overwriting each other's work. Git is the dominant distributed version control system today (replacing older centralized systems like Subversion and CVS for most new projects), typically hosted on platforms like GitHub, GitLab, or Bitbucket. Why it matters for AI/SaaS builders: version control is the substrate everything else in the modern dev toolchain sits on top of — CI/CD triggers off commits and pull requests, code review happens on diffs, deployments are tied to specific commits/tags so you can always answer "what exact code is running in production right now," and rollbacks are just "deploy the previous commit." Without it, collaboration is essentially impossible past one developer, and recovering from a bad change means manual archaeology instead of `git revert`. How it works: a version control system stores the full history of a project as a sequence of commits, each a snapshot of the files at that point plus metadata (author, timestamp, message, and a pointer to the parent commit(s)). Distributed systems like Git give every developer a full copy of the entire history locally, so most operations (viewing history, creating branches, committing) happen instantly offline; syncing with others happens via explicit push/pull to a shared remote. Branching lets you develop a feature in isolation from the stable `main` branch; merging brings that work back together, with the system automatically combining non-conflicting changes and flagging conflicts for a human to resolve. Worked example: a developer wants to add dark mode to a SaaS dashboard. They run `git checkout -b feature/dark-mode` to create a new branch off `main`, make changes across five files, and commit incrementally with `git commit -m "add theme context provider"` and `git commit -m "wire dark mode toggle into settings page"`. Meanwhile a teammate merges an unrelated fix into `main`. The developer runs `git pull origin main` (or rebases), Git auto-merges the unrelated changes since they touched different files, they push their branch and open a pull request, and after review it's merged into `main` — the full history of every intermediate commit remains inspectable forever via `git log`. Six months later, if a bug surfaces in the dark mode feature, anyone on the team can trace exactly which commit introduced it and what else changed alongside it, without relying on anyone's memory of what happened.