This is the advanced path. You've used GitQi and you want to know how it works, why it's built the way it is, and how to extend it. The source is yours to read.
Most website tools rent you an experience. GitQi gives you back control. If you decide to leave, take your HTML with you.
Your HTML is the database. Your Git repo is the history. Your browser is the editor. No servers. No paid services. Total freedom.
Git is infrastructure, not the interface. The interface is the page itself — click, edit, style, all from the browser. Git disappears once setup.
You should have the Right to Repair your website. Own it completely. Move it anywhere. Read every line. Fork it without asking.
GitQi is a single JavaScript file that activates only when
secrets.js is present beside your HTML. In public mode,
it doesn't exist — it's been stripped. Nothing to serve, nothing to
load.
Edit mode activates only when
secrets.js is detected — meaning only on your
machine. Public mode is the default: the published HTML contains
no editor code and no credentials. Your visitors see a static
page; you see a toolbar.
Editable regions are marked with
data-zone (whole sections),
data-editable (text), data-editable-image
(images),
and data-editable-video (YouTube).
The HTML is the schema — there's no separate config.
A tiny manifest called
gitqi-pages.json lists every page in your site. When
you add a page, rename a nav link, or restyle the nav or footer.
GitQi propagates the change to every other page on save.
GitQi writes your edits directly to your local folder using the browser's File System Access API. A Chromium-based browser is required for editing — Safari and Firefox don't support it. The published site works everywhere.
When you click Publish, GitQi serializes the current DOM,
strips the editor code and secrets.js, then pushes the
result via the GitHub Contents API. GitHub Pages does the rest.
Loading gitqi.js from
swill.github.io/gitqi is the easiest default, but it's
not the only option. Fork, version-pin, and self-host — you own the
whole stack.
swill/gitqi.https://your-user.github.io/gitqi/gitqi.js.
Each release publishes a versioned copy —
gitqi-1.2.0.js alongside the
evolving gitqi.js. Pin for stability; upgrade on
your own schedule.
Cutting a release is a single make target. Versioned file is
written, VERSION is bumped, a git tag is pushed:
make release VERSION=1.2.0 # writes gitqi-1.2.0.js # updates VERSION # tags v1.2.0 # pushes to origin
The evolving gitqi.js always mirrors the newest
release. If you don't pin, you get the latest.
GitQi is a single, annotated vanilla JavaScript file. No build step. No dependencies. What you read is what ships. Since it doesn't ship with the published site, we don't need to minify or compress. Inline comments make the code readable.
Reproduce locally against the single-file source, write the fix in plain JS, open a PR. Every line should earn its place.
Open an issue first with the user story. Small, focused changes that preserve the zero-dependency design requirements.
The README is canonical. Corrections, clarifications, and better examples are always welcome — especially from Get Key users who got stuck.
The bootstrap prompt is a structured brief: vibe, sections, tone, a
few inspiration images. You paste it into Claude, attach the images,
and get back a complete
index.html with data-zone attributes in
the right places — ready to edit in GitQi on first open.
Claude.ai with a free account is enough for most people to bootstrap a site. If you're comfortable paying for tooling, Claude Code gives you improved models inside a terminal with file-system access — ideal for larger refactors, multi-page regeneration, or automating updates across a whole site.
github.com/swill/gitqiThe bootstrap prompt lives in the repo as a markdown file. It's versioned, diffable, and forkable. Swap it for your own house-style prompt if you want every new site to feel familiar.