Version Control
Git, GitHub, CI/CD — how code gets from developer to live website.
What is Version Control?
Version control tracks changes to code over time. Imagine a complete history of every edit ever made: who changed what, when, and why. You can revert mistakes instantly, see who introduced a bug, and coordinate changes across a team without constantly emailing files.
Version control is non-negotiable in professional software development. If you're not using it, you're not doing it right.
Git: The Standard
Git was invented by Linus Torvalds in 2005 to manage the Linux kernel. It's distributed (every developer has the entire history locally), fast, and has become the de facto standard. Almost all professional code uses Git.
Key Git concepts:
- Commits: Snapshots of your code at a point in time. Each commit has a message describing the change.
- Branches: Parallel versions of the code. Develop features in branches, merge back to main when done.
- Pull Requests: Propose a change (from one branch to another). Team reviews, discusses, then merges.
- Blame: See who wrote each line and why (from the commit message).
- Rollback: Revert to any previous commit instantly if something breaks.
Git Hosting Platforms
Git is local. To collaborate, you need a central server. Popular platforms:
GitHub
Owned by Microsoft. Dominant market share. Excellent for open source. GitHub Actions (CI/CD) built-in. Free for public repos.
GitLab
Open source alternative. Can self-host. Excellent CI/CD. Growing adoption.
Bitbucket
Owned by Atlassian. Good for enterprise. Integrates with Jira.
CI/CD: Continuous Integration and Continuous Deployment
CI/CD automates testing and deployment. Every time you push code:
1. Continuous Integration (CI)
Code is tested automatically. Run tests, linters, security checks. If tests fail, reject the push.
2. Continuous Deployment (CD)
If CI passes, automatically deploy to production. Zero-downtime deploys, automatic rollback on failure.
Modern CI/CD Pipeline Flow:
- Developer pushes code to a branch
- GitHub/GitLab detects the push
- CI pipeline runs automatically: install dependencies, lint, run tests
- If all checks pass, allow merge to main
- When code is merged to main, CD pipeline runs: build, test again, deploy to staging
- Manual approval or automatic deploy to production
- Monitor for errors; rollback if needed
CI/CD Tools
GitHub Actions
Free, built into GitHub. Best if you're already on GitHub. Simple YAML configuration.
GitLab CI
Built into GitLab. Excellent features. More powerful than GitHub Actions.
CircleCI
Dedicated CI/CD service. Works with any platform. Good performance.
Jenkins
Open source, self-hosted. Enterprise standard. Steep learning curve.
The Staging Environment
Staging is a copy of production that isn't live. You deploy to staging first, test everything, then deploy to production. It catches mistakes before users see them. Many teams have multiple environments: development (local), staging (pre-production), and production (live).
Deployment Strategies
Blue-Green Deploy
Run two production environments. Deploy to the inactive one. Once ready, switch traffic. Instant rollback if needed.
Canary Deploy
Deploy to a small percentage of users first. Monitor for errors. If all good, roll out to 100%. Catches issues before full impact.
Rolling Deploy
Update servers one at a time. No downtime. If something breaks, rollback is manual.