Git & Version Control

7.1.1Definition

Version control is a system for tracking every change made to a codebase over time, allowing changes to be reviewed, reverted, and worked on in parallel by multiple people without overwriting each other's work. Git is the dominant distributed version control system, storing a full history locally rather than depending on a single central server for every operation.

7.1.2Why It Exists

Before version control, teams coordinated changes via emailed file copies or shared folders, making it nearly impossible to know what changed, when, or why, and effectively impossible for two people to safely edit the same file at once. Git exists to solve exactly this — a complete, queryable history of every change, plus a model (branching and merging) for working on parallel changes safely.

7.1.3Core Concepts

• Commit — a snapshot of the codebase at a point in time, with a message describing what changed and why.
• Branch — an independent line of development, letting new work happen without affecting the main codebase until it's ready to merge.
• Merge / rebase — the two primary ways to combine a branch's changes back into another, each with different effects on history shape.
• Remote — a shared copy of the repository (typically on GitHub or similar) that team members push to and pull from.

7.1.4Common Mistakes

• Massive, infrequent commits bundling many unrelated changes together, making history hard to read and problem commits hard to isolate later.
• Vague commit messages ("fix stuff," "updates") that give future readers — including one's own future self — no way to understand intent without re-reading the diff.
• Committing secrets or credentials directly into the repository, which then persist in history even after being "removed" in a later commit.
• Working directly on the main branch for anything beyond trivial changes, with no isolated branch to review before merging.

7.1.5Best Practices

• Commit small, logically-related changes with clear, specific messages describing intent, not just mechanics.
• Use branches for any non-trivial change, merged via review (7.2) rather than pushed directly to main.
• Never commit secrets; use environment variables or a secrets manager instead, and add sensitive file patterns to .gitignore from day one.