How We Built It, Preface: Opening a Repo

A short preface, inspired by ScriptHammer. Before you can clone this project, follow along, or open a ticket when the tutorial drifts, you need a repository — a home for code. If you have never made one, this is the two-minute orientation. If you have, skip to A Token Is an Identity and then Part 0.

What a repository actually is

A repository (“repo”) is a project folder with a memory. Under the hood, Git records every change you make — who changed what, when, and why — so you can review history, undo mistakes, and work with other people without emailing zip files around. There are two flavours of the same thing:

• A local repo lives on your machine. You get one the moment you run git init in a folder.
• A remote (or hosted) repo lives on a server — GitHub, a company's own Git host, wherever — so it survives your laptop dying, and other people (and their AIs) can reach it.

Most projects have both: you work locally and push to a remote. The rest of this post is about creating that remote.

GitHub: the common path

GitHub is where the most people are, which is why this series' demo repo lives there. Three ways to make one, from most-clicky to most-scriptable.

From the website: click New repository, give it a name, choose Public or Private, optionally add a README, and create it. GitHub shows you the exact commands to connect a local folder to it.

From the command line with the GitHub CLI, which is faster once you have done it once:

gh repo create my-project --public --clone

From an existing folder you already have code in — turn it into a repo, make the first commit, and push it up:

git init
git add -A
git commit -m "Initial commit"
gh repo create my-project --public --source . --push

One real decision hides in there: public vs. private. Public means anyone can read it, clone it, and — the point of this series — open issues against it. Private keeps it to you and people you invite. A tutorial or demo you want people to learn from and correct should be public; a client's production site (like the real Chattanooga.Digital) stays private. That is exactly why this series points its “open a ticket” prompts at the public gig-city-drupal demo, not at the private production repo.

You are not required to use GitHub

GitHub is a convenient default, not a law. The same Git you run locally pushes to plenty of other hosts, and choosing one is partly about who you want holding your code.

• GitLab — a full DevOps platform; strong if you want built-in CI/CD pipelines and a self-hostable option from the same vendor.
• Codeberg — a community-run, non-profit host built on the open-source Forgejo software. A good fit if you care about keeping your project on independent, ad-free infrastructure.
• Bitbucket — common in shops already living in the Atlassian (Jira) world.

Own the whole stack: self-hosting

This is the part that fits the Chattanooga.Digital ethos — community infrastructure you actually control. You do not have to hand your code to a big platform at all. You can run your own Git host:

• Gitea and Forgejo are lightweight, self-hosted Git servers — a GitHub-like web interface you run on your own box (or in a container, the same way we run everything else in this series). They are small enough to sit comfortably next to the other services a small organization already runs.
• If your organization already runs Nextcloud — and many community groups do, for files, calendars, and collaboration — you are already self-hosting the “own your data” way. A Git host like Forgejo slots neatly alongside it: same server, same backups, same “we control this” posture. Your code, your issues, and your files all live under one roof you administer.

The trade-off is honest: self-hosting means you run and update the server, which is real work. But it means no third party can change the terms, mine your project, or take it down — and for an organization whose whole point is member-owned infrastructure, that alignment is worth a lot.

Which should you pick?

A short rule of thumb:

• Contributing to others, or want the widest audience → GitHub. It is where the people and their AI tools already are.
• Own your data / community-infrastructure values → self-host with Gitea or Forgejo, next to a Nextcloud if you already run one.
• Somewhere in between → a community host like Codeberg gives you independence without running the server yourself.

Whatever you choose, the workflow the rest of this series uses — clone, edit, commit, push, open an issue — is the same everywhere, because it is just Git. Once you have a repo and (next) an identity your AI can act as, you are ready to build.

Next: A Token Is an Identity →