Strategy 4: separating content (MCP) from structure (Git)
The problem
You have a Hugo site. You want to:
- Edit content via Claude.ai (publish an article, fix a typo, update a draft) without touching an SSH terminal.
- Version the structure (layouts, themes, hugo.toml, deploy scripts) in Git, like a serious dev.
First instinct: “everything in Git”. Articles too. The MCP commits, pushes, GitHub webhook triggers a rebuild. Clean, GitOps-philosophy.
Except it doesn’t work that well. Here’s why, and the simple solution I call Strategy 4.
Why “everything in Git” breaks in practice
Imagine your MCP git commits on every create_page. Naive strategy, often suggested. Here are the problems:
Problem 1 — MCP ↔ Git conflict
You push a new layout from your laptop (layouts/index.html modified). At the same time, the MCP is committing a new article version. Race condition: the MCP might git pull --rebase and fail, or worse, overwrite your local commit.
Problem 2 — MCP’s Git identity
Whose commits is the MCP making? With which GPG key? If you have a “signed commits required” policy, the MCP needs to manage a GPG key, which has to be secured, rotated, etc.
Problem 3 — Unwanted auto-commits
You’re testing, you create a draft article to experiment, you delete it. But the MCP already committed. Now you have a “wip test” commit in history, to rebase or squash manually.
Problem 4 — Asymmetric reversibility
A git revert repo-side has no effect on files the MCP already created. You end up with a desynchronized repo and filesystem state.
Strategy 4: separate the zones
The idea: MCP and Git never write to the same files.
| Zone | Who edits | Versioned in Git? |
|---|---|---|
content/**/*.md |
MCP only | ❌ NO (.gitignore) |
layouts/, themes/, static/, hugo.toml, deploy.sh |
Git push only | ✅ YES |
Repo-side .gitignore:
content/
public/
resources/Implications:
- The MCP can write to
content/whenever. No Git conflict possible. - You can
git reset --hardrepo-side with confidence —content/stays intact. - No need for the MCP to manage a Git identity.
- No “commit pollution”.
Trade-off: no content versioning
You lose Git versioning of content. That’s a real loss:
- No
git blameon an article to see who wrote what. - No
git log content/csp-nonce/index.fr.mdfor history. - No PR review for articles.
Mitigation: VM snapshots + daily encrypted content/ backup to QNAP. That covers disaster recovery, but not fine-grained versioning (who-changed-what-when).
For my personal homelab (single author, technical articles, no editorial validation workflow), it’s an acceptable trade-off. For a 10-contributor team blog, I’d reconsider.
