Most teams think of GitHub as a place to store code. We treat it as the place where everything lives — code, docs, blog posts, ideas, experiments, and the entire history of how Char evolves.
We didn't plan this. It just became obvious over time: if our work already happens in GitHub, why should publishing be anywhere else? The more we worked this way, the more natural it felt. Now it's just how we ship.
You Don't Need a CMS When You Already Have Git
Most CMS platforms solve two problems:
- where your content lives
- how your team edits it
Git already does both.
Content lives in plain files. Editing happens through commits, branches, reviews, comments, and diffs. There are no plugins, no migrations, no schema lock-in, and no surprise updates that break your content model.
You get Markdown, MDX, and a repo.
Everything is portable. You can zip the folder and move it anywhere. Modern CMS platforms hide your content behind their own formats — Git doesn't. That portability is real insurance.
PRs Are a Better Editorial Workflow
If you're a technical team, this clicks immediately.
A blog post becomes a pull request. Review comments become edits. A merge becomes publication. No ceremony, no separate editorial queue, no abstracted "content status," no dashboards reinventing what Git already does.
You get inline comments, suggested changes, clear diffs, commit history, revert ability, preview builds, CI checks for grammar and broken links, and permanent traceability. Every engineer already understands this system. No CMS collaboration feature matches that.
Content Is Just Code
Once blog posts live in the repo, everything becomes composable. Need a new MDX component? Ship it. Need to fix a typo? Commit it. Need to update metadata? It's frontmatter. Need to refactor how posts are structured? Write a script.
You're never stuck asking "How do I do this in the CMS?" Instead you ask "How do I want this to work?" That's a better question.
GitHub Scales With Your Team
Most CMS systems age poorly. Content models become rigid. Plugins break. WYSIWYG editors drift. Migrations become risky. Versioning becomes chaotic.
GitHub doesn't have these problems. As your team grows, its primitives become more valuable: branch-based workflows, code owners for reviewing specific areas, protected branches, required checks, automation bots, and auditability. GitHub solved these problems at global scale. Why rebuild them in a CMS?
Images, Assets, and Everything Else
CMS platforms market the convenience of dragging in an image and having it appear instantly.
You don't lose that with Git. You just do it differently. Drag images into GitHub's web editor, upload screenshots to Supabase or S3, paste the URL into MDX, or commit images to the repo. It takes seconds.
The difference is you own the storage and the URLs forever. They're not locked to whatever CMS you were using that year.
Portability Matters
Every CMS feels safe until you want to leave. Then you find proprietary block formats, hidden HTML, vendor-specific markdown, custom schemas, and migration scripts that only half-work.
A folder of .mdx files has none of that. If we move frameworks, hosting providers, or redesign everything from scratch, the content survives untouched. Portability isn't a convenience feature. It's insurance.
GitHub Works for Us
Writing should be simple. Shipping should be fast. Content should last. GitHub checks all three.
This is Part 2 of our publishing series.
