Version Control & Deployment

Version Control & Deployment

The difference between a team that ships features confidently and one that fears every deployment comes down to process: how they manage code changes, how they test them, and how they move them to production. Git and CI/CD are the infrastructure of that process.

Git Mental Model

Git tracks content, not files. Every commit is a snapshot of your entire repository at a point in time, identified by a SHA-1 hash. Commits form a graph — each commit points to its parent(s). Branches are just named pointers to commits.

The three key operations:

• commit: save a snapshot of staged changes with a message
• merge: join two branch histories together
• rebase: rewrite your commits as if they started from a different base

Understanding that branches are pointers (not copies of files) explains why creating, switching, and deleting branches is instantaneous regardless of how much code is in the repository.

Branching Strategy

Small teams (1–5 engineers) can use GitHub Flow: main is always deployable, every feature is developed on a branch, merged via pull request, and deployed immediately. This is simple and fast.

Larger teams with separate staging and production environments use GitFlow or trunk-based development:

• Trunk-based: everyone merges to main (trunk) at least daily, using feature flags to hide incomplete features from users. Requires strong CI and feature flag infrastructure.
• GitFlow: separate branches for features, release candidates, and hotfixes. More process, more merge conflicts, but clearer release control.

The most common mistake: letting feature branches live for weeks. Long-lived branches accumulate divergence from main, and merging them becomes a painful, conflict-ridden exercise. Branches should live for hours to days, not weeks.

Pull Request Discipline

A pull request (PR) is not just a code review — it is documentation of why a change was made. Good PRs:

• Are focused on one thing (do not fix three bugs and add a feature in one PR)
• Include a description of the problem, the solution, and how to test it
• Reference the issue or ticket they address
• Have passing CI checks before requesting review
• Are small enough to review in under 30 minutes

Reviewers should look for: correctness, security implications, performance implications, test coverage, and adherence to team conventions. Not just style.

CI/CD Pipeline Design

A typical pipeline for a Next.js application:

1. Trigger: push to any branch or merge to main
2. Install: npm ci (reproducible install from lockfile)
3. Lint: ESLint checks code style and catches common bugs
4. Type check: tsc --noEmit catches TypeScript errors without emitting files
5. Unit tests: fast tests that do not require external services
6. Build: next build verifies the app compiles
7. Integration tests: tests that run against a test database
8. Deploy to preview: every PR gets a unique preview URL (Vercel does this automatically)
9. On merge to main: deploy to production

The goal is a pipeline that runs in under 5 minutes. If CI takes 20 minutes, developers stop waiting for it and start merging without confirmation. Speed is a feature of your CI system.

Deployment Strategies

Rolling deploy: replace instances one at a time. At any moment during the deploy, some instances run the old version and some run the new version. Simple but means your app must be backward-compatible during the transition.

Blue-green deploy: run old and new in parallel, switch traffic atomically. No mixed-version period, but requires double the infrastructure during transition.

Canary release: send 5% of traffic to the new version, monitor error rates and latency, then gradually increase to 100%. Limits blast radius if the new version has a bug. Requires robust monitoring to work well.

Rollback Planning

Every deployment should have a rollback plan. For Vercel, reverting to the previous deployment takes one click. For database changes, rollback is harder: if your deployment includes a migration that adds a column, rolling back means deciding what to do with data written to that column. This is why database migrations should be backward-compatible — add columns before removing old ones, never rename columns in a single step.

The practice of deploying at 4 PM on a Friday is considered harmful not because deployments are inherently risky, but because your team's ability to respond to an incident decreases over a weekend. With strong CI/CD and monitoring, any time is fine — but teams without those guardrails should deploy when support is available.