Skip to content
Professor Leads

My Second Brain Runs on Git

William DeCourcy · April 13, 2026

One Commit. Sixty Seconds. Every System Updated.

Last Tuesday I pushed a change to my content strategy. The change was a commit to a Git repository. Sixty seconds later, my website updated itself and every AI agent that touches my content picked up the new rule automatically.

One file. One push. Every system in sync.

That's a normal afternoon for me now. Two years ago it would have been science fiction.

The Problem With Productivity Apps

I've tried them all. Notion, Obsidian, Google Drive, Evernote (RIP).

They all collapse under the same weight as soon as you're running a real operation by yourself.

The storage is fine. The editing is fine. What breaks is the connective tissue.

You change something in one place and the other tools don't know about it. Your AI assistant doesn't know about it. Your future self doesn't know why you changed it.

Most productivity tools are built around the idea that the current state is what matters. Edit the page, save the page, move on.

That works for a recipe. It falls apart for a brand strategy.

A solo creator needs a place where every version is kept, every decision has a reason attached, every machine can pull the latest, and every agent can read and write to the same files.

One tool already does all of this. Developers have been using it for 20 years. It's free, and it's called Git.

What Git Actually Does (Without the Coding Part)

Strip Git down to the features that matter for a second brain and it's 4 things.

Version history. Every change you save is a commit. A commit has a timestamp, an author, and a one-line note about what changed. You can scroll backwards through every version of every file you've ever touched.

Sync across every device. Push a commit from your laptop; pull it from your phone, your desktop, a friend's computer, or an AI agent running in a sandbox. Every machine sees the same current state and the same history.

Undo anything. If you regret a change, revert it. If you want to see the version from 3 months ago, check it out. Nothing is permanently lost unless you delete it on purpose.

Work with agents. A Git repository is a folder of files on disk. Any AI agent, script, or tool that can read a file can read your repo. Any agent that can write a file can update your repo and push the changes.

There's more to Git than this (branches, merges, rebases, pull requests). To start, the only commands you need are commit, push, and pull.

Git began as a way for Linux kernel developers to coordinate thousands of contributors across dozens of time zones. The same design that made it work for that problem makes it work for a solo creator with a laptop and an iPhone.

The Second Brain Use Case

Developers use Git to store code because code is the kind of thing that lives across many files, changes constantly, and needs a history. That description fits a solo creator's operation too.

Think about what you're actually managing:

  • A brand voice that keeps evolving
  • A posting schedule that shifts every few weeks
  • A list of decisions you made and the reasons behind them
  • Drafts in various stages of completion
  • Rules for your AI agents
  • A calendar of what's going live when

That's 6 kinds of living documents. In a productivity app, they sit in 6 unrelated places. In a Git repository, they sit in one folder with one history.

Inside the Professor Leads Repo

The case study I know best is my own. The Professor Leads content operation runs on a single repository called professorleads.com. The repo hosts both the live website and the coordination hub for everything I produce.

Here's what lives in it:

  • hub/bible/project-bible.md: the master brand document. Strategy, target audience, content pillars, platform rules. A single file that every agent and every session reads at startup.
  • hub/pipeline/: per-week state files tracking which stage of production each week is in. Write scripts, film clips, process them, upload, schedule, draft the blog, draft the newsletter. Every stage has a status field.
  • hub/decisions/decision-log.md: every strategic call I've made, with the date, the context, and the reasoning. When I added TikTok. When I changed my posting schedule. When I cut a format. Each entry is a commit with a human-readable explanation.
  • reference/skills/voice-dna/SKILL.md: the rules for how every piece of content sounds. Banned phrases, paragraph length, sample writing. Every AI agent reads this before writing anything.
  • reference/skills/brand-standards/SKILL.md: the rules for how content is formatted and where it's posted. Hashtag order. Platform-specific copy rules. Account selection.
  • content/blog/: every published blog post, including this one.
  • content-drafts/: the staging area for posts that aren't live yet.
  • public/themes.json: a public JSON feed that external partners scrape to see what I'm working on.
  • scripts/: video scripts and production templates.
  • app/, components/, lib/, public/: the Next.js codebase for the website.

The website code and the content strategy sit side by side in the same tree. When I update a brand rule, I'm pushing the same kind of file change a developer makes to a component.

Git doesn't care. Vercel doesn't care. My agents don't care.

The Meta Moment

The blog post you're reading was drafted in the same repository as the website that's serving it to you. A commit pushed the draft into content/blog/, Vercel picked up the change, and 90 seconds later this page existed at a URL.

The whole publishing workflow is one command: git push. Vercel handles the rest.

The same repository also renders the live pipeline page. That page is a visualization of the JSON file that controls my content operation. When I add a stage to the pipeline, the diagram on the page updates automatically.

The page that explains my automation is, itself, automated. I didn't plan for it to work this way. It happened on its own when I started treating my strategy documents the same way a developer treats source code.

How to Start in 5 Steps

Three Git commands and the discipline to write down what you change. No coding required.

Step 1: Create a Private Repository

Sign up for a GitHub account. Create a new private repository called yourname-brain or yourbrand-hub or whatever you want. Mark it private unless you're sure you want the contents public.

Step 2: Write a Brand Rules File

Create a file called brand.md. In it, write down the things you keep repeating: your voice, your topics, your audience, your "don't do" list.

One page is enough. You can expand later.

Step 3: Start a Decision Log

Create a file called decisions.md. Every time you change something meaningful about how you work, add an entry at the top with the date, what changed, and why. After a month you'll have a history you can search.

Step 4: Move Your Drafts In

Create a folder called drafts/. Save your in-progress work there as plain markdown files.

Every save is a commit. Every commit is a version you can come back to.

Step 5: Point Your Agents at It

If you use Claude, ChatGPT projects, Cursor, or any agentic tool, point it at the folder on disk. Ask it to read brand.md before helping you write anything. Most tools do this without extra setup.

That's the minimum version. It takes 30 minutes to set up. Once you have it running, every new thing (rules files, templates, calendars, transcripts) just becomes another file in the same tree.

Frequently Asked Questions

Do I need to know how to code?

No. You need 3 commands: git add, git commit, and git push. Every other Git feature (branches, merges, pull requests) is optional for a solo creator.

GitHub Desktop and the VS Code interface will run those 3 commands for you through buttons, so you don't even have to use a terminal.

Isn't Git just for developers?

Git stores files with history, sync, and undo. None of those features are specific to code.

Writers, marketers, researchers, and solo operators can use it for the same reasons developers can. The tool is general; the audience has just been narrow.

What about privacy?

Private repositories on GitHub are free, invite-only, and encrypted in transit. If your content is sensitive, use a private repo. If it's public content like blog posts or marketing copy, a public repo works and gives you version history visible to anyone who wants to learn from your process.

Can AI agents actually read and write to a repo?

Yes. Agents that run on your machine (Claude Code, Cursor, the Claude Agent SDK) read and write files in a checked-out repo the same way you would. Cloud-based agents with file tools can also work with repos via GitHub's API.

This is one of the reasons Git wins for an AI-augmented workflow: the agents can participate directly in the same files you edit.

What if my content isn't text?

Git handles any file type. Images, PDFs, spreadsheets, audio, video.

The version history is most useful for text files (because you can see exactly what changed line by line) but the storage and sync benefits apply to everything. For very large binary files like raw video, Git LFS (Large File Storage) handles the weight.

The Organizational Operating System

Developers had a reason to pick up Git 20 years ago: they were managing large, changing codebases across teams. The rest of us had smaller writing workflows and assumed we didn't need the same kind of tool. We were wrong.

Git is free. It's stable. It's supported by every major tool in the AI ecosystem.

It's the closest thing to an operating system for the organization that a solo creator runs inside their own head.

Your second brain deserves a place where every idea, every change, and every decision has a record you can revisit. Git is already that place. It's been waiting for you.

Further Reading

On Professor Leads:

On Forbes:

William DeCourcy

William is the founder of Professor Leads and has spent 15+ years in performance marketing. He teaches B2B and B2C marketers how to make better decisions about lead generation.

Subscribe to the Newsletter