Why content drafts should stay private until publish time

Keeping content drafts private until publish is one of those small editorial decisions that quietly protects your whole workflow. In a Git-backed setup, the moment a draft is committed — to a feature branch, a preview commit, or a "staging" file — it stops being private. It now lives in your repository history, readable by anyone with access, indexable by anything that crawls a preview deployment, and permanently woven into your commit log. This article explains why early commits cause clutter, confusion, and accidental indexing, how holding content drafts private until publish keeps Git history clean, and where the real trade-offs are.

If you run an agency, manage a marketing site on a static framework, or operate content for a team of writers and reviewers, the distance between "this is being worked on" and "this is live" is where a surprising amount of risk accumulates. Treating drafts as private app state rather than committed files closes that gap deliberately.

What "early commit" actually means

In a plain Git workflow there is no native idea of "this file is a private draft." Git tracks commits. The instant content exists as a committed file, it is part of history. Teams trying to manage drafts in Git usually reach for one of a few patterns, and each one leaks something.

Draft branches

A writer creates a draft/new-pricing-page branch and commits work-in-progress there. The content is not on the production branch, which feels safe. But it is fully present in the repository. Anyone with read access — a contractor, a freelancer, a client developer you added for one task — can check out that branch and read the unpublished material. For an agency holding several client repositories, that is a confidentiality problem hiding inside a normal-looking Git practice.

Preview commits

Another common pattern is committing drafts so a preview deployment can render them. Now the draft is not only in Git, it is on a public URL. Preview environments are frequently left unauthenticated, and search engines do find them. An embargoed announcement or a half-finished client page can get crawled and indexed before it was ever meant to exist. Removing it later means a commit to take it down, a redeploy, and sometimes a request to de-index — cleanup work created entirely by the early commit.

Half-written files on the main branch

The least disciplined pattern is committing unfinished Markdown straight to the working branch behind a flag or a draft: true frontmatter field, trusting the build to skip it. This works until a build config changes, a flag is misread, or someone deploys from the wrong commit. The "private" draft ships.

Why messy draft history is a real cost

It is tempting to dismiss draft clutter as cosmetic. It is not. A commit log full of "wip", "more edits", "fix typo again", and revived-then-abandoned branches has practical consequences.

• Reviewing real changes gets harder, because meaningful publish commits are buried under editing noise.
• git blame and history archaeology become unreliable when half the commits are scratch work.
• Reverting is dangerous, because a single "publish" rarely maps to a single clean commit.
• Onboarding a new developer to the repository takes longer when the history does not tell a clear story.

A repository whose history is a clean record of what was actually published is an asset. A repository whose history is a transcript of every keystroke is a liability you maintain forever, because Git history is effectively permanent.

How Acrosite keeps drafts private until publish

Acrosite is a Git-backed content publishing platform: your website content lives as Markdown or MDX with YAML frontmatter in your own GitHub repository, and non-technical people publish through the dashboard instead of editing files directly. The key design decision is that a draft is private app state, not a committed file.

When you create or edit a Content Item, the draft lives inside Acrosite. It is not committed to a branch, not staged, and not visible anywhere in your repository. Reviewers and writers can read and refine it in the app, but Git sees nothing yet. Publishing is the single moment the file is written: Acrosite validates the content, commits the Markdown or MDX file with its frontmatter to the connected repository on the configured branch and content path, and saves the commit SHA. The commit is the publish — there is no earlier copy in Git to leak or to clean up.

Scheduled publishing follows the same rule. A scheduled Content Item is held in the app, fully approved, and committed only at the chosen moment. There is no early commit to a branch and no hidden file sitting in history waiting for its release time. To understand the broader model, the GitHub publishing overview covers how the workspace-level GitHub App connection scopes commits to exactly the connected repository.

What this looks like in practice

When the draft is finally published, the file that lands in your repository is clean and complete — for example, a Post written to content/posts/:

---
title: "Spring Product Update"
slug: "spring-product-update"
date: "2026-04-02"
description: "What's new this quarter and what it means for your team."
draft: false
---

Our spring release focuses on faster builds and clearer reporting.

That single commit is the entire public footprint of the work. Every revision, comment, and false start that happened before it stayed inside Acrosite and never touched your branch.

The review workflow without leaking drafts

Review is where the private-draft model proves its value, because review is exactly when a draft is most likely to be shared with people who should not have repository access.

In Acrosite, Client Reviewers are invited per Project and see only the content assigned to them. They can read drafts, comment, and Approve or Request Changes. They have no GitHub access, no billing visibility, and no workspace settings access — so you can get sign-off on a draft without ever putting that draft in Git or handing out a repository invite. Internal Team Members track everything that is waiting for action in the Review Queue.

A typical flow looks like this:

1. A Team Member drafts a Content Item; it stays private in the app.
2. The item enters the Review Queue for internal checks.
3. A Client Reviewer is assigned and reviews the draft in the app, then Approves.
4. The Team Member publishes immediately, or schedules it for a chosen time.
5. Only at publish does Acrosite commit the file to the configured branch and path.
6. Publish Logs record the steps; Deployment Logs record the rebuild.

At no point in that sequence does an unpublished draft exist in your repository, and at no point does a reviewer need Git access to do their job.

Visibility without early commits

The fair objection to keeping drafts out of Git is that committing has a benefit: visibility. People can see what is in flight. Acrosite replaces that benefit with first-class records that do not require leaking anything.

• The Content Calendar shows what is drafted, scheduled, and published, so the editorial pipeline is visible without any content being committed early.
• Publish Logs record each publish attempt's steps — content validated, committed to GitHub, commit SHA saved, deployment triggered — without exposing tokens, hook URLs, or raw provider payloads. Failed publishing can be retried where it is safe.
• Deployment Logs record the results of each deployment trigger, giving you deployment visibility after the commit lands.

You get the operational transparency that early commits seemed to offer, minus the exposed drafts and the cluttered history.

The trade-offs, stated honestly

Holding drafts in the app is the right default, but it is a genuine choice with edges worth naming.

• No Git preview of unpublished drafts. Because drafts are not committed, you cannot use your repository's preview deployment to render a work-in-progress. You review inside Acrosite instead. For most teams this is a feature, not a loss — it is precisely why drafts do not leak — but developers who lean heavily on branch previews should know the model differs.
• The app is the source of truth for drafts. Until publish, the draft lives in Acrosite, not in Git. After publish, your repository holds the canonical file, exactly as a Git-backed site should.
• Discipline moves from branches to status. Instead of managing draft branches, your team manages draft and scheduled status in the dashboard. That is simpler for non-technical contributors and keeps developers out of routine content commits.

For agencies and content teams, those trade-offs land firmly in favor of privacy and a clean history. You can read more about the wider model in how it works, and about the underlying scheduled publishing approach in a companion article.