Interactive Rebase#

Interactive rebase rewrites commit history before merging a feature branch. It turns a messy series of “WIP”, “fix typo”, and “actually fix it” commits into a clean, reviewable sequence.

Start an interactive rebase covering the last 5 commits:

git rebase -i HEAD~5

Or rebase everything since the branch diverged from main:

git rebase -i main

Git opens your editor with a list of commits. Each line starts with an action keyword:

Devcontainer Sandbox Templates#

Devcontainers provide disposable, reproducible development environments that run in a container. You define the tools, extensions, and configuration in a .devcontainer/ directory, and any compatible host – GitHub Codespaces, Gitpod, VS Code with Docker, or the devcontainer CLI – builds and launches the environment from that definition.

For infrastructure validation, devcontainers solve a specific problem: giving every developer and every CI run the exact same set of tools at the exact same versions, without requiring them to install anything on their local machine. A Kubernetes devcontainer includes kind, kubectl, helm, and kustomize at pinned versions. A Terraform devcontainer includes terraform, tflint, checkov, and cloud CLIs. The environment is ready to use the moment it starts.

The Docs-as-Code Principle#

Documentation as code means treating documentation the same way you treat source code: stored in version control, reviewed in pull requests, tested in CI, and deployed automatically. The alternative – documentation in a wiki, a Google Doc, or someone’s head – drifts out of sync with the codebase within weeks.

The core workflow: docs live alongside the code they describe (usually in a docs/ directory or inline), changes go through the same PR process, CI builds and validates the docs, and a pipeline deploys them automatically on merge.

Why Code Review Matters#

Code review catches bugs, but that is its least important function. Reviews spread knowledge across the team, enforce consistency, and create a record of design decisions. A codebase where every change passes through at least one other set of eyes develops fewer dark corners that only one person understands.

The cost is time. A poorly structured review process adds days to every change. The goal is to make reviews fast, focused, and useful – not ceremonial.

The Fidelity-Speed Tradeoff#

Every local development environment sits on a spectrum between two extremes. On one end: running everything locally with no containers, maximum speed, minimum fidelity to production. On the other end: a full Kubernetes cluster with service mesh, maximum fidelity, minimum speed. Every tool in this space makes a different bet on where the sweet spot is.

The right choice depends on your answers to three questions. How many services does your application depend on? How different is your production environment from a single machine? How long can developers tolerate waiting for changes to take effect?

Testing Strategy Selection#

Choosing the right mix of tests determines whether your test suite catches real bugs or just consumes CI minutes. There is no single correct answer – the right strategy depends on your system architecture, team size, deployment cadence, and the cost of production failures.

The Testing Pyramid#

The classic testing pyramid, introduced by Mike Cohn, prescribes many unit tests at the base, fewer integration tests in the middle, and a small number of end-to-end tests at the top.