Git 기반 CMS란? "DB 없이" 콘텐츠를 운영하는 가장 현실적인 방법

웹사이트를 만들다 보면 언젠가 이런 고민이 생깁니다.

• “블로그/문서/랜딩 페이지를 자주 업데이트해야 하는데, DB까지 운영하긴 싫다.”
• “콘텐츠가 바뀔 때마다 누가 무엇을 바꿨는지 추적하고 싶다.”
• “검수(리뷰) 후 배포되는 워크플로우가 필요하다.”

이럴 때 가장 깔끔한 해답 중 하나가 Git 기반 CMS(Git-based CMS) 입니다. 한 줄로 요약하면:

콘텐츠를 데이터베이스 대신 ‘파일(마크다운/JSON/YAML)‘로 저장하고, 수정은 Git 커밋(또는 PR)으로 남기는 CMS 입니다.

---

Git 기반 CMS의 핵심 개념

1) 콘텐츠는 “파일”이다

전통적인 CMS(워드프레스 등)는 콘텐츠가 DB에 들어갑니다. 반면 Git 기반 CMS는 보통 이런 형태로 저장합니다.

• content/posts/hello-world.md
• content/docs/getting-started.md
• data/products.json

즉, 저장소(repo)가 곧 CMS의 데이터 저장소 입니다.

2) 수정은 “커밋”으로 기록된다

콘텐츠를 수정하면 CMS가 Git에 커밋을 생성합니다. 그래서 자동으로 다음이 해결됩니다.

• 누가 바꿨는지(작성자)
• 언제 바꿨는지(시간)
• 무엇을 바꿨는지(diff)
• 되돌리기(revert)

“콘텐츠 변경 이력 관리”가 Git에 의해 거의 공짜로 따라옵니다.

3) 배포는 “빌드”로 이루어진다

대부분 Git 기반 CMS는 정적 사이트(SSG) 또는 하이브리드(Next.js/Astro 등) 와 잘 맞습니다.

흐름은 보통 이렇게 됩니다.

1. CMS에서 글 수정 → Git 커밋/PR 생성
2. CI/CD가 실행 → 사이트 빌드
3. 정적 파일이 배포됨(Vercel/Netlify/Cloudflare Pages 등)

---

왜 Git 기반 CMS가 좋은가?

운영 비용이 낮다 (DB/서버 관리 부담 감소)

• DB 백업/마이그레이션/보안 패치 같은 운영이 크게 줄어듭니다.
• “데이터”가 결국 파일이므로, 최악의 경우에도 Git repo만 있으면 복구 가능합니다.

협업/검수 프로세스가 자연스럽다

PR 기반으로 운영하면 콘텐츠도 코드처럼 리뷰할 수 있습니다.

• 초안 작성 → PR 생성
• 리뷰(교정/팩트 체크) → 승인
• 머지 후 자동 배포

콘텐츠 팀이 있는 조직일수록 이 구조가 강력합니다.

성능이 좋다

정적 사이트는 기본적으로 빠릅니다.

• 캐시/ CDN 친화적
• 서버 비용 절감

---

단점도 분명하다 (여기서 많이들 실패함)

1) “쓰기”가 많은 서비스엔 부적합

댓글, 좋아요, 주문, 장바구니처럼 사용자가 자주 데이터를 쓰는 서비스는 Git 기반 CMS로 버티기 어렵습니다.

• 커밋이 폭증함
• 동시 편집/경합으로 충돌 가능성 증가
• 빌드가 자주 돌면 배포 비용/시간이 커짐

2) 복잡한 검색/필터/관계형 데이터가 어렵다

“태그별 글 목록”, “인기순 정렬”, “관계형 데이터 조인” 같은 건 DB가 잘합니다.

Git 기반 CMS에서도 가능은 하지만 보통 이렇게 우회합니다.

• 빌드 단계에서 인덱스 JSON 생성
• 태그별 리스트 파일 미리 생성
• 검색 엔진(Algolia 등) 연동

즉, 성능은 좋아지는데 설계/구현 난이도는 올라갈 수 있습니다.

3) 콘텐츠 규모가 커지면 빌드 시간이 늘어남

글이 수천~수만 개가 되면 빌드/배포 시간이 무시 못 합니다. 이럴 땐 ISR(Incremental) 같은 하이브리드 전략이 필요합니다.

---

어떤 사이트에 가장 잘 맞을까?

Git 기반 CMS가 특히 잘 맞는 건 이런 유형입니다.

• 회사 소개/랜딩 페이지(마케팅 사이트)
• 블로그/뉴스룸
• 제품/서비스 문서(Documentation)
• 포트폴리오/사례(케이스 스터디)
• 정적 카탈로그(가격표/메뉴/코스 안내)

반대로, 아래는 “CMS만 Git”으로 하고 나머지는 다른 저장소를 쓰는 하이브리드가 보통 더 낫습니다.

• 회원/로그인/권한 관리
• 댓글/리뷰/게시판
• 결제/주문/재고

---

대표적인 Git 기반 CMS 선택지 (카테고리로 이해하기)

A) “사이트에 /admin 붙이는” 형태

• 정적 사이트에 CMS 화면을 붙이고, 편집하면 repo로 커밋하는 방식
• 장점: 구성 단순, SSG와 궁합 좋음
• 단점: 편집 UX가 프로젝트마다 다르고, 설정에 따라 제한이 있을 수 있음

B) “프레임워크에 통합되는” 형태

• Next.js/Astro 같은 앱에 CMS 기능을 통합
• 장점: 개발자 경험 좋고, 커스터마이징 쉬움
• 단점: 초기 세팅이 A보다 무거울 수 있음

C) “상용 서비스”

• 비개발자 편집 경험이 더 매끄러운 경우가 많음
• 협업 기능/권한/미리보기 등 제공
• 단점: 비용 발생, 벤더 종속 가능성

---

실전 아키텍처 예시 (가장 추천하는 형태)

“콘텐츠는 Git, 동적 데이터는 따로”

가장 현실적인 운영 방식은 이 조합입니다.

• 글/문서/페이지: Git 기반 CMS (파일 + 커밋)
• 좋아요/조회수/간단한 설정: KV 같은 서버리스 스토리지
• 회원/결제/트랜잭션: SQLite 또는 Postgres 같은 DB

즉, Git 기반 CMS를 “콘텐츠 영역”에만 쓰고, 서비스성 데이터는 목적에 맞게 분리합니다.

---

도입 체크리스트 (이거 안 보면 나중에 후회함)

1. 누가 편집하는가?
   • 비개발자 편집자가 많으면 UI/권한/미리보기가 중요합니다.
2. 리뷰가 필요한가?
   • PR 기반 검수 프로세스를 원하면 Git 기반 CMS의 강점이 극대화됩니다.
3. 업데이트 빈도는 어느 정도인가?
   • 하루 수십 번 이상 수정한다면 빌드/배포 비용을 고려해야 합니다.
4. 검색/필터/리스트가 핵심인가?
   • 빌드 인덱싱 또는 외부 검색 연동 계획이 필요합니다.
5. 콘텐츠 규모가 커질 가능성이 있는가?
   • ISR, 캐싱 전략, 빌드 최적화를 미리 생각하세요.

---

마무리: “DB 없이 운영”의 정답은 보통 Git 기반 CMS다

Git 기반 CMS는 “DB 없이 콘텐츠를 운영하고 싶다”는 요구에 꽤 정확하게 들어맞습니다.

• 변경 이력/협업/검수: Git이 해결
• 배포/성능: 정적 빌드+CDN이 해결
• 운영 비용: 낮음

단, 서비스성 데이터까지 억지로 Git에 넣으려 하면 망합니다. 콘텐츠에 집중해서 쓰고, 나머지는 KV/SQLite/DB로 분리하는 게 가장 안전합니다.

When building a website, you eventually hit questions like:

• "We need to update blog/docs/landing pages often, but we don’t want to run a database."
• "We want to track who changed what, every time content changes."
• "We need a workflow where content goes through review before going live."

One of the cleanest answers is a Git-based CMS. In one line:

A CMS that stores content as files (Markdown/JSON/YAML) instead of a database, and records every change as a Git commit (or PR).

---

Core Concepts of a Git-based CMS

1) Content lives in "files"

Traditional CMSs (e.g. WordPress) store content in a database. A Git-based CMS typically stores it like this:

• content/posts/hello-world.md
• content/docs/getting-started.md
• data/products.json

So the repo is the CMS’s data store.

2) Changes are recorded as "commits"

When you edit content, the CMS creates a Git commit. That gives you, for free:

• Who changed it (author)
• When (timestamp)
• What changed (diff)
• Rollback (revert)

"Content change history" comes almost for free from Git.

3) Deployment happens via "build"

Most Git-based CMSs pair with static sites (SSG) or hybrid setups (Next.js, Astro, etc.).

The flow is usually:

1. Edit in CMS → Git commit/PR created
2. CI/CD runs → site builds
3. Static assets deploy (Vercel, Netlify, Cloudflare Pages, etc.)

---

Why a Git-based CMS?

Lower operational cost (less DB/server burden)

• DB backup, migration, and security patching shrink or disappear.
• "Data" is just files; in the worst case, having the Git repo is enough to recover.

Natural collaboration and review

If you run on PRs, content can be reviewed like code:

• Draft → open PR
• Review (copy/fact-check) → approve
• Merge → auto-deploy

The more content editors you have, the more this structure pays off.

Good performance

Static sites are fast by default:

• Cache- and CDN-friendly
• Lower server cost

---

Downsides (where many go wrong)

1) Not a fit for write-heavy apps

Comments, likes, orders, shopping carts—apps where users write data often—don’t fit a Git-based CMS well.

• Commit volume explodes
• Concurrent edits and merge conflicts increase
• Frequent builds mean higher deploy cost and time

2) Complex search, filters, and relational data are harder

"Posts by tag," "sort by popularity," "relational joins" are what databases are good at.

You can work around this in a Git-based CMS, but usually by:

• Generating index JSON at build time
• Pre-building tag/list pages
• Plugging in a search engine (e.g. Algolia)

So performance can be great, but design and implementation get harder.

3) Build time grows with content size

With thousands (or tens of thousands) of posts, build and deploy time become significant. Then you need a hybrid strategy (e.g. ISR, incremental builds).

---

What kind of site fits best?

Git-based CMS fits especially well for:

• Company/marketing and landing pages
• Blogs and newsrooms
• Product or service documentation
• Portfolios and case studies
• Static catalogs (pricing, menus, course info)

For the following, a hybrid (Git-based CMS for content only, other storage for the rest) is usually better:

• Members, login, permissions
• Comments, reviews, forums
• Payments, orders, inventory

---

Types of Git-based CMS (by category)

A) "Add /admin to the site"

• Attach a CMS UI to a static site; edits create commits in the repo.
• Pros: Simple setup, works well with SSG.
• Cons: Edit UX varies by project; limits depend on configuration.

B) "Built into the framework"

• CMS features integrated into Next.js, Astro, etc.
• Pros: Good developer experience, easy to customize.
• Cons: Heavier initial setup than A.

C) "Commercial / hosted"

• Often smoother for non-developer editors.
• Collaboration, permissions, preview, etc.
• Cons: Cost and possible vendor lock-in.

---

Practical architecture (recommended pattern)

"Content in Git, dynamic data elsewhere"

A realistic setup is:

• Posts/docs/pages: Git-based CMS (files + commits)
• Likes, view counts, simple config: Serverless storage (e.g. KV)
• Users, payments, transactions: A proper DB (SQLite, Postgres, etc.)

So use a Git-based CMS only for content, and keep service data in the right store.

---

Adoption checklist (don’t skip this)

1. Who edits?
   If many editors are non-developers, UI, permissions, and preview matter a lot.
2. Do you need review?
   If you want PR-based review, a Git-based CMS shines.
3. How often do you update?
   If you change content dozens of times a day, think about build and deploy cost.
4. Are search, filters, and lists central?
   Plan for build-time indexing or an external search service.
5. Will content scale up?
   Think ahead about ISR, caching, and build optimization.

---

Bottom line: "Running without a DB" usually means a Git-based CMS

A Git-based CMS fits the goal of "running content without a database" very well:

• Change history, collaboration, review: Git handles it
• Deployment and performance: static build + CDN
• Operational cost: low

But forcing all service data into Git is a mistake. Use Git-based CMS for content only; keep the rest in KV, SQLite, or a proper DB.

做网站做到一定阶段，往往会遇到这样的纠结：

• 「博客/文档/落地页要经常更新，但不想再维护一套数据库。」
• 「希望每次内容变更都能追踪是谁改了什么。」
• 「需要先审稿再上线的发布流程。」

这时，Git 型 CMS（Git-based CMS） 是其中一种最干净的方案。一句话概括：

把内容存成「文件（Markdown/JSON/YAML）」而不是数据库，用 Git 提交（或 PR）记录每次修改的 CMS。

---

Git 型 CMS 的核心概念

1）内容是「文件」

传统 CMS（如 WordPress）把内容放在数据库里。Git 型 CMS 通常是这样存的：

• content/posts/hello-world.md
• content/docs/getting-started.md
• data/products.json

也就是说，仓库本身就是 CMS 的数据存储。

2）修改以「提交」形式记录

编辑内容时，CMS 会在 Git 里生成提交，于是自然得到：

• 谁改的（作者）
• 什么时候改的（时间）
• 改了什么（diff）
• 回滚（revert）

「内容变更历史」几乎由 Git 免费提供。

3）发布靠「构建」完成

多数 Git 型 CMS 搭配 静态站点（SSG） 或 混合方案（Next.js/Astro 等）。

流程一般是：

1. 在 CMS 里改内容 → 生成 Git 提交/PR
2. CI/CD 触发 → 站点构建
3. 静态资源部署（Vercel/Netlify/Cloudflare Pages 等）

---

为什么选 Git 型 CMS？

运维成本低（少管 DB/服务器）

• 数据库备份、迁移、安全补丁等运维大幅减少。
• 「数据」本质是文件，最坏情况只要有 Git 仓库就能恢复。

协作与审稿流程自然

用 PR 驱动的话，内容可以像代码一样走审稿：

• 写初稿 → 开 PR
• 审稿（校对/事实核查）→ 通过
• 合并后自动发布

内容团队越大，这种结构越有价值。

性能好

静态站天生快：

• 利于缓存和 CDN
• 服务器成本低

---

缺点也很明显（很多人栽在这里）

1）不适合「写多」的服务

评论、点赞、订单、购物车这类 用户频繁写入数据 的场景，用 Git 型 CMS 很难撑住：

• 提交量暴增
• 并发编辑、冲突增加
• 构建频繁则部署成本/时间上升

2）复杂搜索/筛选/关系型数据较难

「按标签列文章」「按热度排序」「关系型 join」是数据库的强项。

Git 型 CMS 也能做，但通常要绕一下：

• 构建阶段生成索引 JSON
• 预生成标签/列表页
• 接 Algolia 等搜索服务

也就是说，性能可以很好，但设计和实现难度会上去。

3）内容规模大时构建时间变长

文章到几千、几万篇时，构建和部署时间就不可忽视，需要 ISR 等混合策略。

---

最适合哪类站点？

Git 型 CMS 特别适合：

• 公司介绍/落地页（营销站）
• 博客/新闻站
• 产品/服务文档
• 作品集/案例
• 静态目录（价目表、菜单、课程说明等）

下面这些更适合「内容用 Git 型 CMS，其余用别的存储」的混合方案：

• 会员/登录/权限
• 评论/评价/论坛
• 支付/订单/库存

---

常见的 Git 型 CMS 类型（按类别理解）

A）「给站点加 /admin」型

• 在静态站上挂一个 CMS 界面，编辑后往仓库提交。
• 优点：结构简单，和 SSG 搭配好。
• 缺点：编辑体验因项目而异，配置可能有限制。

B）「和框架深度集成」型

• 在 Next.js、Astro 等里集成 CMS 能力。
• 优点：开发体验好，易定制。
• 缺点：初期配置可能比 A 重。

C）「商用/托管」型

• 非开发者编辑体验往往更顺滑。
• 提供协作、权限、预览等。
• 缺点：有费用，可能有厂商绑定。

---

实战架构示例（推荐形态）

「内容用 Git，动态数据分开」

比较现实的组合是：

• 文章/文档/页面：Git 型 CMS（文件 + 提交）
• 点赞/浏览量/简单配置：KV 等无服务器存储
• 会员/支付/交易：SQLite 或 Postgres 等数据库

也就是 Git 型 CMS 只用在「内容」这一块，业务数据按用途分开存。

---

引入前检查清单（不看容易后悔）

1. 谁在编辑？
   非开发者编辑多的话，UI、权限、预览很重要。
2. 是否需要审稿？
   想要 PR 式审稿流程，Git 型 CMS 的优势才能发挥。
3. 更新频率多高？
   一天改几十次的话，要考虑构建和部署成本。
4. 搜索/筛选/列表是否核心？
   需要规划构建期索引或外部搜索。
5. 内容规模会不会变大？
   提前想好 ISR、缓存和构建优化。

---

小结：「无 DB 运营」的答案通常是 Git 型 CMS

Git 型 CMS 很贴合「不想用数据库也能运营内容」的需求：

• 变更历史/协作/审稿：Git 解决
• 发布/性能：静态构建 + CDN 解决
• 运维成本：低

但把业务数据也硬塞进 Git 会出问题。内容用 Git 型 CMS，其余用 KV/SQLite/DB 分开存，最稳妥。

ウェブサイトを作っていると、いつかこんな悩みが出てきます。

• 「ブログ/ドキュメント/ランディングをよく更新したいが、DBまで運用したくない。」
• 「誰が何をいつ変えたか追跡したい。」
• 「レビュー後に公開するワークフローが欲しい。」

そんなときの答えのひとつが GitベースCMS（Git-based CMS） です。一言でいうと：

コンテンツをDBの代わりに「ファイル（Markdown/JSON/YAML）」で保存し、変更はGitコミット（またはPR）で残すCMS です。

---

GitベースCMSの核心概念

1）コンテンツは「ファイル」

従来のCMS（WordPressなど）はコンテンツをDBに格納します。GitベースCMSではだいたいこういう形で保存します。

• content/posts/hello-world.md
• content/docs/getting-started.md
• data/products.json

つまり リポジトリがCMSのデータストア です。

2）変更は「コミット」で記録される

コンテンツを編集すると、CMSがGitにコミットを作成します。これで自動的に：

• 誰が変えたか（作者）
• いつ変えたか（時刻）
• 何を変えたか（diff）
• 戻す（revert）

「コンテンツ変更履歴」がGitによってほぼタダでついてきます。

3）公開は「ビルド」で行う

多くのGitベースCMSは 静的サイト（SSG） や ハイブリッド（Next.js/Astroなど） と相性が良いです。

流れはだいたいこうです。

1. CMSで編集 → Gitコミット/PR作成
2. CI/CDが走る → サイトビルド
3. 静的ファイルがデプロイ（Vercel/Netlify/Cloudflare Pagesなど）

---

なぜGitベースCMSが良いか

運用コストが低い（DB/サーバー管理の負担減）

• DBのバックアップ/マイグレーション/セキュリティパッチといった運用が大きく減ります。
• 「データ」は結局ファイルなので、最悪でもGitリポジトリがあれば復旧できます。

協業・レビュープロセスが自然

PRベースで運用すれば、コンテンツもコードのようにレビューできます。

• 下書き → PR作成
• レビュー（校正/ファクトチェック）→ 承認
• マージ後に自動デプロイ

コンテンツチームがいる組織ほど、この構造が効きます。

パフォーマンスが良い

静的サイトは基本的に速いです。

• キャッシュ/CDNと相性が良い
• サーバーコストが抑えられる

---

欠点もはっきりしている（ここで失敗する人が多い）

1）「書き込み」が多いサービスには向かない

コメント、いいね、注文、カートのように ユーザーが頻繁にデータを書くサービス はGitベースCMSでは厳しいです。

• コミットが爆発する
• 同時編集・競合で衝突が増える
• ビルドが頻繁だとデプロイコスト/時間が膨らむ

2）複雑な検索/フィルタ/リレーショナルデータは難しい

「タグ別記事一覧」「人気順」「リレーショナル結合」はDBの得意分野です。

GitベースCMSでも可能だが、だいたいこういう迂回をします。

• ビルド時にインデックスJSONを生成
• タグ別リストを事前生成
• Algoliaなどの検索エンジン連携

つまり パフォーマンスは良くなるが、設計/実装の難易度は上がることがある ということです。

3）コンテンツ規模が大きいとビルド時間が伸びる

記事が数千〜数万になるとビルド/デプロイ時間が無視できません。ISRなどのハイブリッド戦略が必要になります。

---

どんなサイトに最も合うか

GitベースCMSが特に合うのは次のようなタイプです。

• 会社紹介/ランディング（マーケティングサイト）
• ブログ/ニュースルーム
• 製品・サービスドキュメント
• ポートフォリオ/事例（ケーススタディ）
• 静的カタログ（価格表/メニュー/コース案内）

逆に、以下は「CMSだけGit」にして他は別ストアを使うハイブリッドの方がよいです。

• 会員/ログイン/権限
• コメント/レビュー/掲示板
• 決済/注文/在庫

---

代表的なGitベースCMSの選択肢（カテゴリで理解する）

A）「サイトに /admin を付ける」形

• 静的サイトにCMS画面を付け、編集するとリポジトリにコミットする方式。
• メリット：構成がシンプル、SSGと相性が良い。
• デメリット：編集UXはプロジェクトごとに違い、設定によって制限がある場合あり。

B）「フレームワークに統合される」形

• Next.js/AstroなどにCMS機能を統合。
• メリット：開発者体験が良く、カスタマイズしやすい。
• デメリット：初期セットアップはAより重い場合あり。

C）「商用サービス」

• 非開発者の編集体験がよりスムーズなことが多い。
• 協業機能/権限/プレビューなどを提供。
• デメリット：コスト、ベンダーロックインの可能性。

---

実戦アーキテクチャ例（おすすめの形）

「コンテンツはGit、動的データは別」

現実的な運用はこの組み合わせです。

• 記事/ドキュメント/ページ：GitベースCMS（ファイル＋コミット）
• いいね/閲覧数/簡単な設定：KVなどのサーバーレスストレージ
• 会員/決済/トランザクション：SQLiteやPostgresなどのDB

つまり GitベースCMSは「コンテンツ領域」だけに使い、サービスデータは目的に応じて分けます。

---

導入チェックリスト（見ないと後悔する）

1. 誰が編集するか？
   非開発者編集者が多ければUI/権限/プレビューが重要です。
2. レビューは必要か？
   PRベースの検収プロセスを望むならGitベースCMSの強みが最大化します。
3. 更新頻度はどの程度か？
   1日に数十回以上編集するならビルド/デプロイコストを考慮してください。
4. 検索/フィルタ/リストが中核か？
   ビルド時のインデックス化や外部検索連携の計画が必要です。
5. コンテンツ規模が大きくなる可能性はあるか？
   ISR、キャッシュ戦略、ビルド最適化を前もって考えておきましょう。

---

まとめ：「DBなし運用」の答えはだいたいGitベースCMS

GitベースCMSは「DBなしでコンテンツを運用したい」という要望にかなりぴったりです。

• 変更履歴/協業/検収：Gitが解決
• デプロイ/パフォーマンス：静的ビルド＋CDNが解決
• 運用コスト：低い

ただし、サービスデータまで無理にGitに入れると失敗します。コンテンツに集中して使い、残りはKV/SQLite/DBで分けるのがいちばん安全です。

Al montar un sitio web, tarde o temprano aparecen dudas como:

• "Hay que actualizar blog/documentación/landings a menudo, pero no queremos mantener una base de datos."
• "Queremos saber quién cambió qué cada vez que cambia el contenido."
• "Necesitamos un flujo donde el contenido pase por revisión antes de publicarse."

Una de las respuestas más limpias es un CMS basado en Git (Git-based CMS). En una frase:

Un CMS que guarda el contenido en «archivos» (Markdown/JSON/YAML) en lugar de en una base de datos, y registra cada cambio como un commit (o PR) de Git.

---

Conceptos clave de un CMS basado en Git

1) El contenido son "archivos"

Los CMS tradicionales (p. ej. WordPress) guardan el contenido en una base de datos. Un CMS basado en Git suele guardarlo así:

• content/posts/hello-world.md
• content/docs/getting-started.md
• data/products.json

Es decir, el repositorio es el almacén de datos del CMS.

2) Los cambios se registran como "commits"

Cuando editas contenido, el CMS crea un commit en Git. Con eso obtienes de forma automática:

• Quién lo cambió (autor)
• Cuándo (marca de tiempo)
• Qué cambió (diff)
• Cómo deshacerlo (revert)

El "historial de cambios del contenido" viene casi gratis gracias a Git.

3) El despliegue se hace con un "build"

La mayoría de CMS basados en Git encajan bien con sitios estáticos (SSG) o híbridos (Next.js, Astro, etc.).

El flujo suele ser:

1. Editar en el CMS → se crea commit/PR en Git
2. Se ejecuta CI/CD → se construye el sitio
3. Se despliegan los estáticos (Vercel, Netlify, Cloudflare Pages, etc.)

---

¿Por qué un CMS basado en Git?

Menor coste operativo (menos DB/servidor)

• Backup, migración y parches de seguridad de la base de datos se reducen o desaparecen.
• Los "datos" son solo archivos; en el peor caso, con el repo de Git basta para recuperar.

Colaboración y revisión naturales

Si trabajas con PRs, el contenido se puede revisar como el código:

• Borrador → abrir PR
• Revisión (corrección/verificación) → aprobar
• Merge → despliegue automático

Cuanto más equipo de contenido tengas, más rentable es esta estructura.

Buen rendimiento

Los sitios estáticos son rápidos por naturaleza:

• Amigables con caché y CDN
• Menor coste de servidor

---

Inconvenientes (donde muchos fallan)

1) No encaja con apps con muchas escrituras

Comentarios, likes, pedidos, carritos: apps donde el usuario escribe datos con frecuencia no encajan bien con un CMS basado en Git.

• Los commits se disparan
• Aumentan las ediciones simultáneas y los conflictos
• Muchos builds implican más coste y tiempo de despliegue

2) Búsqueda, filtros y datos relacionales complejos son más difíciles

"Listado por etiqueta", "ordenar por popularidad", "joins relacionales" son lo que mejor hace una base de datos.

En un CMS basado en Git también se puede, pero suele hacerse así:

• Generar JSON de índice en el build
• Pre-generar páginas de listados/etiquetas
• Conectar un motor de búsqueda (p. ej. Algolia)

Es decir, el rendimiento puede ser muy bueno, pero diseño e implementación se complican.

3) El tiempo de build crece con el tamaño del contenido

Con miles (o decenas de miles) de artículos, el tiempo de build y despliegue deja de ser despreciable. Ahí hace falta una estrategia híbrida (p. ej. ISR, builds incrementales).

---

¿Qué tipo de sitio encaja mejor?

Un CMS basado en Git encaja especialmente con:

• Páginas corporativas y de marketing / landings
• Blogs y newsrooms
• Documentación de producto o servicio
• Portfolios y casos de estudio
• Catálogos estáticos (precios, menús, cursos)

Para lo siguiente suele ser mejor un híbrido (CMS basado en Git solo para contenido, otro almacenamiento para el resto):

• Miembros, login, permisos
• Comentarios, reseñas, foros
• Pagos, pedidos, inventario

---

Tipos de CMS basado en Git (por categoría)

A) "Añadir /admin al sitio"

• Se añade una interfaz de CMS al sitio estático; las ediciones crean commits en el repo.
• Ventajas: Configuración simple, buena combinación con SSG.
• Inconvenientes: La UX de edición varía por proyecto; puede haber límites según la configuración.

B) "Integrado en el framework"

• Funcionalidad de CMS integrada en Next.js, Astro, etc.
• Ventajas: Buena experiencia de desarrollo, fácil de personalizar.
• Inconvenientes: Configuración inicial puede ser más pesada que A.

C) "Servicio comercial / alojado"

• Suele ofrecer mejor experiencia para editores no desarrolladores.
• Colaboración, permisos, vista previa, etc.
• Inconvenientes: Coste y posible dependencia del proveedor.

---

Arquitectura práctica (patrón recomendado)

"Contenido en Git, datos dinámicos aparte"

Una configuración realista es:

• Artículos/documentación/páginas: CMS basado en Git (archivos + commits)
• Likes, contadores, configuración sencilla: Almacenamiento serverless (p. ej. KV)
• Usuarios, pagos, transacciones: Una base de datos adecuada (SQLite, Postgres, etc.)

Es decir, usar un CMS basado en Git solo para el contenido y mantener los datos de servicio en el almacén adecuado.

---

Lista de adopción (no la saltes)

1. ¿Quién edita?
   Si muchos editores no son desarrolladores, la UI, permisos y vista previa importan mucho.
2. ¿Hace falta revisión?
   Si quieres revisión basada en PRs, un CMS basado en Git encaja muy bien.
3. ¿Con qué frecuencia se actualiza?
   Si el contenido cambia decenas de veces al día, piensa en coste de build y despliegue.
4. ¿Son centrales la búsqueda, filtros y listados?
   Planifica indexación en el build o un servicio de búsqueda externo.
5. ¿Puede crecer mucho el volumen de contenido?
   Piensa con antelación en ISR, caché y optimización del build.

---

Conclusión: "Funcionar sin DB" suele significar un CMS basado en Git

Un CMS basado en Git encaja muy bien con el objetivo de "gestionar contenido sin base de datos":

• Historial de cambios, colaboración, revisión: lo resuelve Git
• Despliegue y rendimiento: build estático + CDN
• Coste operativo: bajo

Pero meter también todos los datos de servicio en Git es un error. Usa el CMS basado en Git solo para el contenido; el resto en KV, SQLite o una base de datos adecuada.