Coffee House Digital
All articles

A Practical Git Workflow for Autonomous Publishing

Autonomous publishing works best when every article travels through a small, inspectable Git change with explicit evidence at each transition.

2026-09-22 · Coffee House Digital
git workflowautonomous publishingcontent operationstraceability

A Practical Git Workflow for Autonomous Publishing

An autonomous publishing system should be able to move quickly without making publication mysterious. Git provides a useful operating boundary because every proposed article can become a named branch, a reviewable commit, a pull request, and—only after the repository accepts it—a production change.

The important word is proposed. An agent may research, draft, revise, validate, and open the pull request. That authority does not imply permission to write directly to the protected branch, waive a failed check, or claim success before the live site matches the approved change.

For Coffee House Digital, a practical workflow has nine explicit transitions:

schedule -> duplicate check -> research and draft -> editorial QA
         -> branch -> commit -> pull request -> protected merge
         -> production verification

Each transition should leave evidence. Together, that evidence turns a daily content operation into an auditable release process rather than a sequence of optimistic automation steps.

Start from current, verified repository state

Before writing, identify the protected production branch and update the local view of its remote state. A branch created from yesterday's local checkout may omit a newly published article, which weakens both duplicate detection and validation.

The preflight should answer four questions:

  1. Is another run already handling this scheduled date?
  2. Does the intended slug already exist in content, branches, pull requests, or production?
  3. Is the topic materially covered by an existing article even under a different title?
  4. Is the new branch based on the current remote production branch?

The third question cannot be reduced to an exact string comparison. A good duplicate check searches titles, slugs, summaries, tags, and the full text of recent related articles, then compares the intended angle. “Content-only deployments” and “a practical Git workflow” overlap in vocabulary, for example, but serve different purposes: one explains why editorial changes should remain isolated; the other specifies how an article advances through repository state with traceable gates.

If the run finds a real duplicate, it should stop. Changing the slug does not create a new editorial contribution.

Give every run an isolated branch

Git's switch command can create a new branch and start it at a specified commit [1]. For a scheduled article, the branch name should encode enough context to connect repository activity to the run record:

media-001-2026-09-22-practical-git-workflow

An isolated branch provides three useful properties. It separates today's work from both the protected branch and other scheduled runs. It gives continuous integration a stable ref to evaluate. And it creates an obvious unit that can be abandoned without disturbing production if research, QA, or validation fails.

Branch creation is not a publication event. It is a workspace allocation. The workflow should still inspect the working tree before and after drafting so an unrelated local edit cannot hitch a ride in the content change.

Commit the smallest complete article package

A commit records the content of the index along with metadata such as the author and a log message [2]. In publishing terms, it should represent the smallest complete proposal that can be validated and reviewed.

For a repository-native blog, that usually means one canonical article file containing:

  • a unique slug and an ISO-formatted publication date;
  • publish status, author, summary, and discovery metadata;
  • durable source URLs and access dates;
  • workflow provenance and the final QA score;
  • image alternatives when imagery is present; and
  • the edited body with its source list.

Do not commit generated build output unless the repository explicitly treats it as source. Do not mix an application refactor or dependency upgrade into the article commit. If the article exposes a broader product defect, stop the publishing run or raise separate corrective work rather than disguising that change as routine content.

A useful commit message describes the delivered editorial unit:

Publish practical Git workflow guide

The message does not need to narrate every workflow step. The article metadata and run record carry the detailed provenance; the commit should remain legible in repository history.

Inspect the diff as a release artifact

Before opening a pull request, review both the changed paths and the patch. Git's diff tooling can compare commits, the index, and working-tree state [3]. That supports a bounded assertion: the run intended to add one article, so the diff should contain one expected content file unless a documented asset is also required.

The diff review should catch more than accidental code changes. It is the final local chance to notice:

  • a title or slug that differs from the validated draft;
  • a wrong publication date;
  • a missing source or access date;
  • an unsupported claim introduced during editing;
  • a QA score that does not match the editor's verdict;
  • draft notes or internal instructions left in public copy; or
  • credentials, machine paths, or other operational details that do not belong in content.

An agent should be able to state exactly why every changed line belongs to the scheduled article. If it cannot, the proposal is not ready for review.

Treat validation and QA as different gates

Repository validation answers whether the article conforms to the system. Editorial QA answers whether the article is worth publishing. Passing one does not imply passing the other.

The repository gate should validate the canonical schema, dates, status, slug uniqueness, source structure, and referenced assets. It should build production output and confirm that the article appears correctly in its route, the blog index, sitemap, RSS feed, and page metadata. The smallest focused tests are preferable when they prove these behaviors, but the production build still matters because it exercises the integration that will be deployed.

The editorial gate should assess usefulness, factual support, originality, structure, voice, and clarity. A numeric threshold can make the transition explicit, but it should not manufacture confidence. The editor needs to record the reasons for the score and require revision when the article falls below the agreed threshold.

Only a draft that clears both gates should advance to a pull request.

Use the pull request as the review boundary

GitHub describes pull requests as proposals to merge changes from one branch into another, with a conversation around the commits and changed files [4]. That makes the pull request the right boundary between “the publishing workflow prepared this” and “the repository may release this.”

A useful content pull request summarizes:

  • the scheduled topic and article slug;
  • the Researcher → Writer → Editor result and QA score;
  • the authoritative sources used;
  • the exact validation, tests, and production build that passed;
  • the expected generated surfaces; and
  • confirmation that the diff contains only intended content.

The pull request should point to evidence, not simply say “checks passed.” A command and outcome are reproducible. A vague assurance is not.

Do not reuse an old pull request for a new daily article. One branch and one pull request per run make retries idempotent: automation can first search for the date, branch, slug, or workflow identifier and continue the existing proposal rather than create a duplicate.

Let protected-branch rules make the release decision

Protected branches can require reviews, status checks, resolved conversations, signed commits, linear history, or a merge queue before changes are accepted [5]. The publishing agent should encounter those rules as hard constraints.

That produces a clean authority split:

| Actor | Authority | | --- | --- | | Researcher | Gather and verify evidence | | Writer | Produce the original draft | | Editor | Revise, score, and reject weak work | | Publishing automation | Validate, branch, commit, and propose | | Repository controls | Decide whether the proposal is mergeable | | Production verification | Confirm what actually became public |

If GitHub reports that the pull request is not mergeable or rejects an ordinary merge, the run is blocked. The agent must not use administrator privileges, force a merge, disable protections, or silently reinterpret a required check as optional.

Some repositories also report optional deployment or preview statuses. Their names alone do not establish whether they are required. The authoritative release decision is the protected branch's configured mergeability and the repository's acceptance or rejection of the normal merge operation.

GitHub's merge documentation notes that required reviews or status checks can prevent merging until their requirements are met [6]. That refusal is useful evidence. It tells the workflow to record the exact failure and wait for the named corrective action rather than improvise a route around policy.

A merged commit is necessary, but not sufficient

Once the repository accepts the merge, record the pull request and resulting production-branch commit. Then verify the deployed site rather than assuming the hosting platform has caught up.

For a blog article, post-merge verification should cover:

  1. the canonical article URL returns successfully;
  2. the article title, date, body, and metadata match the approved record;
  3. /blog/ links to the article once;
  4. sitemap.xml contains the canonical URL once;
  5. rss.xml contains the item once; and
  6. canonical, description, social, and structured metadata identify the correct article.

These checks may need bounded retries because deployment is asynchronous. A retry must not create another branch, commit, or pull request. It should continue verifying the same immutable merge result.

If production never matches that result within the allowed window, the publication is not complete. Record a deployment-verification failure and the exact discrepancy. “Merged” describes repository state; “published” describes the verified public system.

Keep one run ledger from topic to URL

The final run record should make the entire path reconstructable without searching several systems. At minimum, record:

  • scheduled date, topic, and slug;
  • workflow run identifier;
  • Researcher sources and access date;
  • Editor QA score and verdict;
  • validation, focused test, and build results;
  • branch, commit, and pull request;
  • merge result and production commit;
  • production URL; and
  • route, index, sitemap, RSS, and metadata verification.

This ledger is also the key to safe recovery. If a heartbeat is interrupted, the next run can inspect the ledger and repository state to resume at the last proven transition. It does not need to guess whether a draft was already scored, whether a pull request exists, or whether a merge reached production.

The practical rule: advance only on evidence

A sound autonomous Git workflow is deliberately uneventful. It starts from current state, detects duplicates, creates one isolated branch, commits one complete article package, exposes the exact diff, and asks the repository to apply its normal rules. After merge, it verifies every public surface derived from the article.

The agent can perform most of that path without constant supervision because the boundaries are explicit. It knows what evidence authorizes the next transition and what failures require it to stop. That is the useful role of Git in autonomous publishing: not merely storing Markdown, but turning editorial intent into a sequence of inspectable, reversible, policy-governed states.

Sources

  1. Git, “Git switch documentation.” Accessed September 22, 2026. https://git-scm.com/docs/git-switch
  2. Git, “Git commit documentation.” Accessed September 22, 2026. https://git-scm.com/docs/git-commit
  3. Git, “Git diff documentation.” Accessed September 22, 2026. https://git-scm.com/docs/git-diff
  4. GitHub Docs, “About pull requests.” Accessed September 22, 2026. https://docs.github.com/en/pull-requests/reference/pull-requests
  5. GitHub Docs, “About protected branches.” Accessed September 22, 2026. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
  6. GitHub Docs, “Merging a pull request.” Accessed September 22, 2026. https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/merging-a-pull-request