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 the page.
Your HTML is the database. Your Git repo is the history. Your machine is the only place your credentials ever live. No servers. No accounts. No vendor relationship.
Git is infrastructure, not the interface. The interface is the page itself — clicked, typed, styled, lived in. The plumbing is Git, and you never have to think about it if you don't want to.
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), and data-editable-image (images). 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 link, or restyle the nav, 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. That's why Chrome, Edge, or any Chromium-based browser is required for editing — Safari and Firefox haven't shipped the API yet. 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 file. No build step. No transpiler. What you read is what ships. That's the whole invitation.
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 ethos land quickly.
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 regenerations, or automating updates across a whole site.
index.html directly — a natural complement to GitQi's in-browser editor.
The 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.