Git for knowledge work: a version-controlled brain for small teams

Git and GitHub are a knowledge-management system that happens to host code. For a small team drowning in a Notion graveyard, here's why and when that matters.

Every small team has a graveyard. It is usually a Notion workspace, sometimes a Google Drive, occasionally a wiki nobody opens. It started clean. Then it accumulated: pages written once and never read, three versions of the same onboarding doc, decisions that live in someone's DMs, a "source of truth" that stopped being true around month four. New hires discover it in random order. Nobody can answer "what did we decide about X, and why" without interrupting the one person who was in the room.

The standard response is to reorganise. Better templates, a new top-level structure, a cleanup sprint. It buys a few weeks. The graveyard comes back, because the problem was never the layout. The problem is that the substrate has no memory. A Notion page does not know who changed what, when, or why. It shows you the current state and erases the path that got there. For knowledge work, that missing history is the whole game.

Software teams solved this twenty years ago, and the tool they used was never really about code. Git tracks the history of plain-text files: who changed which line, when, and with what explanation, all the way back to the first commit, with the ability to return to any point. GitHub puts that history in the cloud and adds a layer for working on it together. Most knowledge-work teams have never considered it because it arrived wearing a developer costume. Underneath the costume is the most honest knowledge-management system available, and for some teams it is the right one. This piece is about which teams, and why.

Git is a system that records the history of a set of files. You work in a folder it watches, and at meaningful points you save a snapshot called a commit, with a message explaining the change. Git keeps every commit forever. The result is not a backup of one state but a complete, ordered record of how the files came to look the way they do. You can see any past version, compare two of them line by line, and recover anything.

GitHub is a website that hosts these histories and adds collaboration on top: a place to discuss the work, assign it, plan it, and review changes before they land. The distinction is worth holding onto. Git is about versions of files. GitHub is about a team working on those files together. You can use Git alone on your laptop; GitHub is what makes it a shared brain.

The unit that makes it work for knowledge is the commit. A Notion page tells you it was "edited 2 days ago by Sam." A Git history tells you that Sam, on Tuesday, changed the pricing section from monthly to annual, and the commit message says why: "switch to annual billing after the March pricing review." That is provenance, and provenance is what turns a pile of documents into something a team can trust and reason about. When the source of truth carries its own reasons, you stop relying on the memory of whoever was present.

The fear is that Git is complicated. The honest version is that the everyday workflow is four steps, and the rest is optional machinery you reach for when you need it.

The history lives in two places: on your machine and on GitHub. Before you start working, you pull the latest version so you have everyone else's changes. You edit the files. When you finish a coherent piece of work, you commit it with a short description of what and why. Then you push, sending your commits to GitHub so the rest of the team sees them. Pull, edit, commit, push. That is the loop a writer or operator runs every day.

The one discipline that matters: pull before you work, push when you finish a chunk. Do not sit on changes for hours. A team that commits in small, frequent, well-described steps gets a readable history and almost never collides. A team that commits once a week with the message "updates" gets neither. The tool rewards the same habit good knowledge work rewards anyway, which is saying what you did and why while it is still fresh.

By default everyone works on the main line, called main, which holds the presentable state of the project. For most edits in a small team that is fine. Write the doc, commit, push, done.

When a change is large or risky, you make a branch, which is a parallel copy where you can work without touching the live version. You draft, commit freely, and break nothing that others depend on. When it is ready, you open a pull request, which proposes folding the branch back into main. The pull request shows exactly what changed, line by line, and gives the team a place to comment before anything lands. Only after review does it merge.

For a knowledge base, this is the difference between a wiki where anyone can quietly overwrite the page on data retention and a system where a change to a load-bearing document gets seen before it becomes the truth everyone reads. You do not need this ceremony for fixing a typo. You want it for the documents where being wrong is expensive.

Here is where GitHub stops being version control and becomes a team operating system, and where most teams underuse it badly.

An issue is a unit of work or discussion: a card with a title, a description, checklists, comments, an assignee. Treating issues as the single source of truth for "what needs doing" is the move that pulls tasks out of scattered docs and chat. The work and the conversation about the work live in the same place as the files the work changes. A label is a coloured tag for grouping issues, so you can filter to "everything blocking the launch" or "all the content tasks."

The two features teams confuse are milestones and projects, and the distinction is genuinely useful.

A milestone is a deadline bucket inside one repository. It groups issues toward a single date and shows a progress bar, so many of N done. An issue belongs to at most one milestone. It answers "what has to be finished in this repository by this date." A project is a planning board that sits above repositories. It pulls issues from many repositories into one view, as a kanban board or a table, with custom fields for status, priority, and dates. It answers "how is all my work laid out, across everything."

They are not directly linked. The connection runs through the issue. The milestone is a field stored on the issue; the project is a collection the issue was added to. The same issue carries both at once, so when it lands on the board it brings its milestone with it, and you can group the board by milestone. You cannot put a milestone into a project, because projects hold issues, not milestones, but a project can read and display the milestone of every card it holds. Milestone is "by when, in this repo." Project is "the whole picture, across repos." The issue is the bridge. Once that clicks, you can run a multi-project operation from one board and still keep hard dates per repository.

The quiet advantage underneath all of this is the file format. Git tracks plain text, and most teams write their knowledge in Markdown, which is ordinary text with light markup: hash marks for headings, dashes for lists, a few characters for bold and links and tables. GitHub renders it cleanly, but the file on disk is just text.

That has consequences a Notion workspace does not. You own the files completely; there is no export step and no vendor who can change the terms, raise the price, or shut down and take your knowledge with them. The content is greppable, scriptable, and diff-able, which means an AI agent can read and edit it directly without an API in the way. It survives tools: the Markdown you write today opens in any editor in ten years. For teams that care about data sovereignty, GDPR, or simply not being locked into a platform, plain text under version control is the most durable substrate there is. The knowledge outlives the software you happened to use this year.

This is the same reason it pairs well with AI. An agent working over a folder of Markdown sees the whole structure, edits files in place, and commits its changes with a message, leaving the same auditable trail a human would. The history does not care whether the commit came from a person or a tool. Provenance holds either way.

The pattern in the table is the honest summary. Git and GitHub win decisively on history, ownership, review, and machine-readability, and lose on real-time editing and approachability. Which column matters more depends entirely on your team, which is the next section.

Garden does not sell tools it would not use, and it does not pretend a good tool fits every team. Git is the wrong choice in several real situations, and recognising them saves you a painful migration.

It is wrong when the people who own the knowledge will not work in text. If your team thinks in documents with embedded tables, comments, and drag-and-drop, and the commit habit feels like friction they will route around, the system rots the same way Notion did, except now with a steeper learning curve. The tool only works if the team actually adopts the loop.

It is wrong for real-time, many-hands editing of a single document. Git merges parallel changes to text well, but two people typing into the same paragraph at the same second is exactly what Google Docs was built for and Git was not. For live co-writing, use the live co-writing tool.

It is wrong as the home for visual and binary work. Design files, spreadsheets with live formulas, slide decks, images as the primary artifact: Git stores them, but it cannot show you what changed inside them, which removes the main benefit. Keep those where their own history works, and keep text in Git.

And it is wrong when the real problem is that nobody has decided what the team should know in the first place. No substrate fixes an absence of conventions. If decisions are not being written down anywhere, moving the place they are not written down does nothing. The discipline has to exist before the tool can carry it. That ordering, conventions first and tooling second, is usually where the actual work is.

Do I need to know how to code to use Git? No. The daily loop, pull, edit, commit, push, is four actions, and modern editors give you buttons for all of them. The friction is the habit of committing in small described steps, not anything to do with programming. Teams of writers and operators run Git fine; the question is willingness, not technical background.

Is this just for software teams? No, and treating it as developer-only is the misconception that keeps useful teams away. Git tracks the history of any plain-text files, which includes documentation, decisions, research notes, and content. The collaboration and planning layer on GitHub is general-purpose. The code association is historical, not essential.

What is the difference between Git and GitHub? Git is the system that records file history, and it runs on your machine. GitHub is the website that hosts that history in the cloud and adds collaboration on top: discussion, review, issues, and planning. Git is the engine; GitHub is where the team meets around it. There are alternatives to GitHub, such as GitLab, that play the same role.

How is a milestone different from a project? A milestone groups issues inside one repository toward a single deadline and shows progress. A project is a board above many repositories that collects issues into one view with custom fields. The same issue can sit in both; the milestone is stored on the issue, and the project displays it. Milestone is a date inside one repo, project is the cross-repo picture.

Will this replace Notion entirely? Often not, and it should not have to. A common, honest setup keeps live collaborative docs and visual work where they belong and moves the durable, load-bearing knowledge, decisions, conventions, documentation, into version control. The point is to put the knowledge that must not rot onto a substrate with memory, not to win a tool war.

The version-controlled team brain is a good idea that fails on adoption more often than on technology. The substrate is sound; whether your team will live in it is the real question, and answering it honestly is more useful than another endorsement of the tool. That assessment, what your team actually knows, where that knowledge lives, what is worth moving to a substrate with memory, and what should stay where it is, is the first thing a Garden audit maps. If you are trying to work out whether your knowledge belongs in version control or somewhere else, that is the conversation we have. Email a@gardenresearch.eu.