Simple Git CMS

English · 简体中文 · 日本語

Try it in your browser — the real editor, with a service worker standing in for GitHub. Nothing to sign in to.

A content editor for static sites that uses a GitHub repository as its backend. Articles are Markdown files in the repository; the editor is a plain static page that reads and writes them through the GitHub API, straight from the editor's browser. No server of your own, and no database.

It suits Astro, Hugo and friends: someone writes an article, drops in images and publishes; behind the scenes that is one git commit, and your existing CI builds and deploys the site.

What it does

• WYSIWYG editing (TipTap) that saves clean Markdown — open an existing article and save it again and the file is unchanged
• Images: paste, drop or pick several at once, compressed to webp in the browser; crop, rotate, caption, place side by side, replace
• Blocks of your own: a video, a notice box, a table with merged cells — anything your site already renders. Name the tag in config.json and it joins the insert menu with an editor of its own: a small form, the table editor, or its own HTML
• Code: inline code and fenced blocks, which keep their language and are left alone by everything else the editor does to text
• Tables: add and remove rows and columns, align a column left, centre or right — written out as a plain GFM table that lines up in the file. Anything beyond that, such as a cell spanning two columns, is an HTML table, which is a block your site defines
• Attachments: a PDF or anything else goes into the repository as it is, linked from the body under the name it came with, up to a size you set
• Nothing is quietly dropped: anything in the file the editor has no buttons for — an embed, a leftover <div>, a component your site expands itself — is shown as an HTML box whose source you can edit, and written back exactly as it was. A tag that is never closed is marked where it is, and saying so before saving, rather than shipped to wrap the rest of the page
• A cover image: taken from the pictures the article already has, or uploaded; replaced, cropped or removed in the article's own form, and written to a frontmatter field of your choosing — what a site uses for list thumbnails and share images
• Several kinds of article: news, notices, events — each in a directory of its own, with its own address on the site, cover field and preview page, switched between in the sidebar. Saving, publishing and deployment are the same for all of them
• Fields of your own: a venue, a price, a status — text, numbers, a choice from a list, a checkbox or a date, each with an input in the article form, written to the frontmatter as the type it is. A field nobody touched is left in the file exactly as it was
• Articles: title, date, tags, summary; draft / publish / revert / delete a draft. The open one is in the address bar, so reloading comes back to it and the link opens it for anyone else who can sign in
• Saving: the article and its new images go in as a single commit; if someone else changed the article while it was open, you are offered their version or yours
• History: every version of an article, one per commit that changed it, to look through as the site would show it — or in the site's own preview. Restoring one puts it in the editor; saving it is a new commit that says which version it came from, and leaves the article published or not as it was
• Nothing in progress is lost: what hasn't been committed is kept in the browser as you type — images that haven't been uploaded included — and offered back after a crash, a closed tab or a reload
• A long list stays quick: the list is read in two steps — which files there are, then their text in batches, newest first, so it appears without waiting for the last article. The text is kept in the browser under git's own hash of it, so opening the editor again downloads only what actually changed
• Preview: see the article in your own site's layout, at desktop or phone width, including changes and images you have not saved yet
• Deployment: draft saves get [skip ci] so they don't trigger a build; after publishing, the top bar follows the GitHub Actions run
• Action buttons (optional): buttons that start GitHub Actions workflows of your choosing — for example publishing a test site, where the editor lives, to the live site, which then needs no editor at all
• Sign-in: GitHub App sign-in (a full-page redirect, so it works on phones; the token only reaches repositories the App is installed on, and is refreshed automatically), or a fine-grained access token
• Permissions are just repository permissions — whoever can push can edit, and who changed what is in the git history
• Interface in English, 简体中文 and 日本語, switchable in place
• Light or dark, following the computer or chosen by hand

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗