A code repository is where a project's truth lives: the code, its full history, the discussion behind every change, and the automation that ships it. GitHub is the dominant home for it — with GitLab, Bitbucket, and Codeberg as the serious alternatives. They turn Git from a local tool into a collaboration platform: pull requests, code review, issues, CI. And increasingly, the repository is the surface AI agents read, write, and ship through.
A repository ("repo") is a project under version control: the files, the complete commit history, and the metadata around it. Git gives you the repo locally. A code-hosting platform — GitHub being the largest — hosts a shared copy everyone (and every CI system, and every agent) syncs against, then layers collaboration on top.
That collaboration layer is the actual product. Pull requests turn "I changed something" into "here's a reviewable proposal." Issues track what needs doing. Actions run tests and deployments automatically. Releases tag shippable versions. Permissions control who can do what. None of that is Git — it's the platform — and it's why "where's the repo?" is the first question on any software project.
A well-run repo is the project's system of record: the source, yes, but also the docs (a README, an architecture note), the automation (CI config), the issue history, and the decision trail in pull requests. For an AI-era team it's also where prompts, agent definitions, and SKILL.md files live. Treat the repo as the single source of truth and everything else — the deployed site, the report, the running agent — is generated from it.
All four run on Git, so your repo is portable. They differ on ecosystem, hosting model, and politics. Honest positioning:
| Platform | Strengths | Watch out for |
|---|---|---|
| GitHub (Microsoft) | Largest ecosystem by far, best Actions/CI marketplace, Copilot + native agent tooling, where open source lives | Microsoft-owned; the default to the point of lock-in by gravity, not features |
| GitLab | All-in-one DevOps (CI/CD, registry, security baked in), strong self-hosting, enterprise-friendly | Heavier; smaller open-source community than GitHub |
| Bitbucket (Atlassian) | Tight Jira/Confluence integration; fits teams already deep in the Atlassian stack | Smaller ecosystem; momentum has faded vs GitHub/GitLab |
| Codeberg / Forgejo | Non-profit, open-source platform (Forgejo); no vendor lock-in, privacy-first, self-hostable | No first-party CI marketplace or agent tooling at GitHub's scale; smaller network |
For most teams in 2026 the pragmatic answer is GitHub — the ecosystem and agent tooling are simply ahead. Reach for GitLab when you want one integrated DevOps platform or strict self-hosting; reach for Codeberg/Forgejo when independence from a big vendor is a principle. Because it's all Git underneath, migrating later is annoying but never a trap.
The platform features map onto one workflow that every contributor — human or agent — follows.
A branch packaged for review: the diff, a description, and a discussion thread. Nothing reaches main without going through one.
Approvals, inline comments, and required reviewers. The human (or agent) gate before a change ships — and the record of why it was accepted.
Bugs, features, and tasks — linked to the commits and PRs that resolve them, so intent and implementation stay connected.
Tests, linters, builds, and deploys that run automatically on a push or PR. The gate that keeps main shippable.
This site runs exactly this loop: changes land on a branch, open as a pull request, CI builds a preview, and a merge to main auto-deploys to production via GitHub Actions. No manual upload step, every change reviewable, every deploy traceable to a commit. That's the whole point of the platform.
Beyond your own code, GitHub is the public commons of software. Almost every open-source library, framework, and tool you depend on is developed there in the open — issues, PRs, releases, and all. That makes the platform two things at once: your private system of record and the place you read the source of your dependencies, file bugs upstream, and judge whether a project is healthy (recent commits, responsive maintainers, open-issue ratio).
The automation layer — GitHub Actions and its marketplace — turns the repo into an execution surface. A push can run a test suite, build a container, publish a package, deploy a site, or kick off an agent. The repo stops being a passive store and becomes the trigger point for everything downstream.
CI that deploys is load-bearing infrastructure, and it has sharp edges. A real example from this very tree: Cloudflare's deployment API rejects non-ASCII commit messages (em-dashes, curly quotes, arrows) with an opaque error — so the deploy workflows pass an explicit ASCII --commit-message. The lesson: treat your CI config as production code, version it, and don't assume it'll keep working just because it worked yesterday.
If AI is just software, the repository is where AI does software. By 2026 the repo is the primary interface between coding agents and real systems.
Agents meet repositories in three ways. They read them — a coding agent clones the repo as its context, the way Claude Code or Copilot CLI reason over a whole codebase before proposing a change. They act on them through tools — the GitHub MCP server exposes repos, issues, PRs, and code search as callable operations, so an agent can open an issue or a pull request as a first-class action. And they ship through them — an agent's work lands as a branch and a pull request, runs the same CI, and waits for the same review as any human's.
This is the whole reason you can trust an agent with real code. Its changes don't touch main directly — they arrive as a reviewable pull request, the test suite runs against them automatically, and a human (or a second agent) approves before merge. Get it wrong and git revert undoes it cleanly. The repository's workflow is precisely the harness that turns "an AI edited our code" from a nightmare into a controlled, auditable, reversible operation. Without it, agent autonomy is reckless; with it, it's leverage.
The practical implication: getting an organisation "AI-ready" is mostly getting it repo-ready. Code in version control, a sane branch-and-PR workflow, tests in CI, reviewable changes. Teams with that discipline can hand agents real work tomorrow. Teams without it have to build the foundation first — which is the software work this whole branch is about.
A model is stateless — a brain in a jar with no memory and no access to your business. Everything that makes an agent durable, capable, and correct is files in a repository, versioned like code.
The model forgets everything between requests. Persistent memory is software writing notes back to the repo — a CLAUDE.md, an AGENTS.md, decision records, the PR trail — and reading them in next time. Versioned, reviewable, diffable.
An Agent Skill is a folder with a SKILL.md committed to the repo. Build a capability once, version it, and every agent on the team loads the same one. The canonical library, anthropics/skills, is itself a GitHub repo (~155k stars).
Agents go wrong when they guess. Keeping context — configs, schemas, runbooks, structured data — in version control means the agent reasons over the current truth of the business, not a stale snapshot, and you can see exactly what it saw.
This is why "AI memory" and "agent skills" aren't a separate product to buy — they're the repository discipline you may already have. Notes-to-self, packaged capabilities, and grounding context are all just committed files under review. The same pull-request workflow that gates code changes also gates what an agent knows and how it behaves, so memory and skills evolve with an audit trail instead of drifting in someone's chat history.
software/software-for-agents treats the repo as the agent's context, workspace and audit trail. agents/skills is the SKILL.md standard in full. agents/rearchitecture is the Ng × Chase case for grounded, structured data; agents/mcp is the seam where that grounded data reaches the agent. And software/ai-is-software is why a stateless brain needs all of it.
The open-source projects that turn the repo-as-memory idea into running infrastructure. Star counts are a health signal, not a recommendation — checked June 2026. A plain CLAUDE.md / AGENTS.md in your own repo beats all of them until you actually need scale.
Don't start here. Start with a CLAUDE.md and a SKILL.md folder in the repo you already have — that is memory and skills, versioned and reviewable, with nothing to host. Reach for a memory framework (mem0, letta) only when an agent needs durable, queryable recall across many sessions and users; reach for a temporal knowledge graph (graphiti, cognee) when facts change over time and "what was true when" matters. Grounding is the seam, not a store: modelcontextprotocol/servers is how the agent reaches your live, owned data — the part worth investing in first.
For South African businesses weighing "how do we start with AI," the highest-leverage first step usually isn't a model or a vendor — it's getting work into a properly run repository. Code, configs, and process rules in Git; changes through pull requests; CI running checks. It's unglamorous, it's affordable, and it's the precondition for safely deploying agents later. It also produces the change-control audit trail POPIA and FSCA reviewers ask for, as a free side effect.
On data residency: the repo platform (GitHub/GitLab) hosts code and history, not necessarily your production data — but for regulated workloads, check where the platform stores repos, keep secrets out of them (use a secrets manager, never commit keys), and consider self-hosted GitLab or Forgejo where source residency itself is in scope.