Docs-as-code is the practice of writing and publishing documentation with the same tools and habits developers already use for source code: plain-text markup, version control, pull-request review, and continuous integration. A static site generator (SSG) is the engine that turns those plain-text files into a searchable, navigable website, and the choice between a React-powered tool like Docusaurus, a Python-based one like MkDocs or Sphinx, or a Go/Ruby-based one like Hugo or Jekyll shapes everything from how contributors write to how the site gets versioned and searched. These tools converge on a shared toolkit: Markdown or reStructuredText source files, a config file that drives navigation, a build step that emits static HTML, and a CI pipeline that publishes on every merge. The non-obvious part is that picking a generator is rarely about a single missing feature; it's about matching the tool's ecosystem and plugin community to the codebase the docs already sit next to, since most doc systems die from maintenance friction rather than a technical gap.
What This Cheat Sheet Covers
This topic spans 14 focused tables and 120 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Docs-as-Code Fundamentals & Workflow
Before touching any specific tool, it helps to understand the philosophy every generator in this cheat sheet was built to support: treating documentation as a first-class engineering artifact, not an afterthought written in a separate app.
| Practice | Example | Description |
|---|---|---|
docs/ folder tracked in the same Git repo as src/ | Writing documentation with the same plain-text markup, version control, and review tools developers already use for code. | |
Plain-text source format (Markdown / reST / AsciiDoc) | # Heading- bullet item | Source files are readable, diffable text rather than a binary format like .docx, so changes show up cleanly in a Git diff. |
git checkout -b docs/fix-typo | Doc changes go through the same branch → PR → review → merge cycle as code, catching errors before publish. | |
.github/workflows/docs.yml runs a build and link-check on every PR | A failing build blocks the merge, the same guarantee code CI gives; covered in depth in the CI/CD table below. |