Foundations
Version Control
Version control is the single habit every professional engineer uses before they've written a single feature — the system that tracks every change to a codebase, lets teams work on the same project without overwriting each other, and makes it safe to experiment because nothing is ever truly lost. Git is the tool; GitHub, GitLab, and Bitbucket are where teams actually run it day to day.
Topic Map
Everything in this module, at a glance
In Depth
Every topic, explained — with real-world industry context
Core Git Concepts
Git tracks a project as a series of snapshots (commits), not a single overwritten file — understanding this model is the key to everything else in Git making sense.
- Repositories — the full tracked history of a project
- Commits — an atomic, described snapshot of changes
- The staging area — choosing exactly what goes into the next commit
- Local repository vs. remote repository (origin)
Real-World Industry Use Case
Every "I broke it, how do I get back to the working version?" moment is solved by Git's commit history — this is the single most common reason engineers reach for Git even on solo projects, before collaboration ever enters the picture.
Branching & Merging
Branches let you develop a feature or fix in isolation without touching the stable, working version of the code — the mechanism that makes safe, parallel work possible.
- Creating, switching & deleting branches
- Merging — combining the history of two branches
- Rebasing — replaying commits on top of another branch for a cleaner history
- Resolving merge conflicts when two changes overlap
Real-World Industry Use Case
A team of 10 engineers building the same app simultaneously only works because each person branches off, builds in isolation, and merges back — without branching, only one person could safely touch the codebase at a time.
Collaboration Workflows
Different teams organize their branches differently depending on release cadence and team size — these are the named, industry-standard patterns you'll be expected to already know on day one of a job.
- Git Flow — dedicated branches for features, releases & hotfixes
- Trunk-based development — everyone merges to a single main branch frequently
- The fork & pull request model used by open-source projects
- Choosing a workflow based on team size & deployment frequency
Real-World Industry Use Case
Google runs trunk-based development across more than 35,000 engineers in a single repository — proof these workflows genuinely scale. Most open-source projects on GitHub, meanwhile, run entirely on the fork-and-pull-request model, which is how outside contributors submit changes without ever having direct write access.
Git Hosting Platforms
Git itself is just the version-control engine — GitHub, GitLab, and Bitbucket are the platforms that host repositories in the cloud and add the collaboration layer: code review, CI/CD, issue tracking, and access control.
- GitHub — the largest platform, deeply tied to open source & modern CI/CD (GitHub Actions)
- GitLab — an all-in-one DevOps platform with built-in CI/CD pipelines
- Bitbucket — Atlassian's platform, tightly integrated with Jira & Trello
- Other tools in the ecosystem: Azure DevOps, SourceForge, self-hosted Gitea
Real-World Industry Use Case
A hiring manager checking a candidate's GitHub profile is now a standard part of technical recruiting. Companies already using Jira for project management very often choose Bitbucket specifically for that native integration — the platform choice is rarely arbitrary, it follows the rest of a team's toolchain.
Advanced Git
Beyond the daily commit-push-pull loop, Git has a set of precision tools for cleaning up history and recovering from mistakes — the commands that separate a comfortable Git user from an expert one.
- Cherry-picking — applying a specific commit from one branch onto another
- Stashing — temporarily shelving uncommitted changes
- Interactive rebase — rewriting, squashing & reordering commit history
- Git bisect — binary-searching through history to find which commit introduced a bug
Real-World Industry Use Case
When a critical bug appears and no one knows which of the last 200 commits caused it, `git bisect` finds the culprit in roughly log₂(200) ≈ 8 steps instead of checking every commit — a real, frequently-used debugging technique at companies with fast-moving codebases.
Best Practices & Code Review
Git is a tool; using it well as a team is a discipline — the conventions here are what make a repository's history actually useful months or years later.
- Writing clear, conventional commit messages
- .gitignore & keeping a repository clean of build artifacts and secrets
- The pull request & code review cycle before merging
- Protecting main branches with required reviews & passing CI checks
Real-World Industry Use Case
Every serious engineering team requires a pull request with at least one approval and a passing CI pipeline before code reaches production — this exact process is what this module prepares you to participate in from your very first day on a team.
Ready to learn this — live?
See how this module fits into the complete curriculum.