Editorial Workflow

GitCMS is built so writers, marketers, and reviewers can work in a familiar editorial model: Ideas → Draft → Review → Published. You use the content board and tasks, not branches, issues, or pull requests. Developers still get a real Git repository underneath; everyone else gets vocabulary they already know from docs tools and editorial calendars.

Enabling the editorial workflow

Open your site’s Settings and set Publishing mode to Review before publish (editorial_workflow in config).

Once enabled, the sidebar includes Content Board — a single place to see work moving across all collections.

How it works

1. Ideas

Start with an idea when you only have a title, brief, or rough notes. Ideas live in the first column on the content board so the team can see what might be written next without opening the editor yet.

You can add ideas from the board, then move a card into Draft when someone is ready to write.

2. Draft

While a task is in Draft, GitCMS keeps that work separate from your live site. You edit in the visual editor as usual; saves stay tied to that task until you choose to move forward.

You do not name branches, open tickets, or sync Git state — the workflow keeps each task’s changes isolated for you.

3. Review

When the copy is ready for feedback, move the task to Review (or use the action that submits it for review in your site).

In-app review (beta) — Open Review from the board or the task. Reviewers see the content in GitCMS, can discuss changes, and work through approval there. The experience is still labeled beta while we refine layout, wording, and approval flow, but it is available today.

Authors can keep editing from GitCMS while a review is open; updates stay attached to the same task.

4. Published

When review is complete and someone with publish access publishes, the content becomes part of your live site. The task moves to Published on the board.

GitCMS handles the transition; you don’t merge or reconcile Git state in the product UI.

The content board

The content board is a kanban-style view of every editorial task:

A quick speed-run of the board shows work moving across the editorial stages:

Each card represents one task and typically shows:

• Title and helpful labels (for example collection or locale).
• Who kicked it off and when it last changed.
• Actions to open the editor, continue the draft, or open review when relevant.

Drag cards between columns when your permissions allow, or use the same moves from inside the task — whichever fits your workflow.

Team collaboration

The editorial workflow fits:

• Solo builders pairing AI drafts with a clear “review before live” step.
• Startups aligning marketing and product on what ships and when.
• Developers handing off client content without teaching Git.
• Agencies separating who writes, who approves, and who publishes per site.

Roles in GitCMS

Workspace roles map to that model:

• Editors — create and update drafts and move tasks forward.
• Reviewers — comment and approve in the review experience.
• Publish access — publish approved work to the live site.
• Admins and Owners — manage members, sites, and workspace settings.

One person can hold multiple capabilities. See Roles & Site Access.

Staying in the loop

When tasks move to Review or Published, participants usually get updates through the same channels they already use with your Git provider (for example email or inbox notifications). GitCMS doesn’t replace your host’s notification system; it keeps the product language on tasks and stages, not on low-level repo events.

When to use the editorial workflow

Use it when:

• More than one person touches content before it goes live.
• You want an approval step and a shared view of what’s in flight.
• You care about who did what without exposing Git mechanics to the whole team.
• You want a single board across collections.

Use direct publish instead when:

• You’re the only editor and want every save to go live immediately (see Configuration).

You can change publishing mode in Settings; existing files are not rewritten.

Tips

• One task, one thread of work. Keeps review focused and publishing predictable.
• Review on a steady cadence. Stale review columns lose context — agree on turnaround inside your team.
• Check the board daily. Faster than hunting through folders for “where did that post go?”
• Use previews. Many hosts deploy preview URLs for in-progress work; reviewers can validate the real site experience when your setup supports it.

If you inspect the repository

You never choose branch names for editorial tasks in GitCMS — each task gets an isolated line of work in Git that the product manages for you. If you open the repo on GitHub, you’ll see commits and identifiers tied to those tasks; you don’t need to follow a naming convention in the CMS. Direct publish mode is simpler: edits land on your default branch only.