Why this matters
Software engineering solved collaboration a generation ago. Many developers work on one codebase at once, review each other's changes, roll back a mistake in seconds and trace every line to the person who wrote it and the reason why. Most organizations manage their knowledge, their most valuable asset, with tools that offer less version control than a shared document.
What "GitHub for data" means
GitHub is not hosting. It is a workflow built on five primitives:
- Commit. A snapshot of everything at a point in time, with author, time and message. For data: a snapshot of the whole dataset, every node, edge and property, as an immutable signed checkpoint.
- Branch. An isolated line of work whose changes leave the main line alone. For data: an analyst, a pipeline or an agent can change anything without touching production.
- Diff. What changed between two versions, line by line. For data: which entities were added, changed or removed between two states.
- Pull request. A proposal to merge, inspected, discussed and approved first. For data: a steward reviews what an import, a transformation or an agent changed before it reaches the shared dataset.
- Merge. Integration of one branch into another, with conflicts flagged when both touched the same thing. For data: the same, at the level of entities.
GitHub for data means the whole workflow, not only versioning: branching, diffing, reviewing and merging, applied to datasets, knowledge graphs and data products.
Why not Git itself?
Git was designed for text files. It diffs lines, keeps the whole history on every clone and assumes files are small. Data breaks each assumption:
- Scale. A graph with billions of relationships does not fit a repository, and cloning or diffing it would be impractical if it did.
- Structure. Data is not lines. A useful diff understands entities, relationships and schema, not bytes.
- Queries. You cannot query a repository. "All suppliers in Europe as of last Tuesday" is not a question the log answers.
- Distribution. Git gives every developer a full copy. Data systems need each node to hold what it needs and no more.
What is needed is infrastructure that keeps Git's principles, immutable commits, cheap branches, content-addressed storage and cryptographic linking, and is built for data at scale. That is what Legra's history is.
In practice
A data engineering team receives a large dataset from a new supplier and has to fold it into the organization's graph.
Without the workflow: the engineer loads it straight into production. Half an hour later someone notices misaligned names and thousands of duplicate nodes. There is no undo. The team spends the day writing cleanup scripts and hoping they catch every bad record. Audit asks what happened; the answer is chat messages and memory.
With the workflow: the engineer branches from production and loads the data there. Production is untouched. A diff shows what the import would add: twelve thousand entities, a few hundred relationships and forty-seven records that conflict with existing ones. A steward reviews the diff, flags the conflicts and asks for corrections. The engineer fixes them on the branch and resubmits. The steward approves, and the branch is merged. Every step, who branched, what was loaded, who reviewed, when it merged, is a signed commit.
The same workflow is right for AI agents. An agent branches, works inside its branch and proposes its changes as a reviewable request. It can be bold there, creating entities, restructuring relationships, rebuilding subgraphs, because the branch is isolated. It needs no permission to merge. A person or a policy approves that, exactly like a pull request. On Legra, agents branch too. The branch boundary becomes the governance boundary, and the worst case is a discarded branch.
What it gives you
Freedom for agents, safely. Agents write freely inside their own branches. Permissions still matter, but the decisive constraint moves from what an agent may draft to where it may publish.
What-if on real data. Branch production and model a future: acquire a competitor and merge its catalog, drop a risky supplier, reorganize three departments. Each scenario is a branch of real, queryable data, not a spreadsheet approximation. Run the same reports against it. Merge it or discard it. Production is not touched.
Safe onboarding. Every new source, bulk import and migration happens on a branch. A bad import is a discarded branch.
Reproducible analytics. A report cites the commit it read. Months later anyone can check out that commit and reproduce it on identical data.
Audit by construction. "What did the data say on this date?" is one query. Every change is attributed, timed and signed, in the data itself.
Parallel work. Schema on one branch, ingestion on another, analytics on the stable line. No branch waits on another. Changes meet in explicit merges.
Rollback. Point the branch at the last good commit. No restore, no replay.
What it costs
Habits. Teams used to writing straight to the database learn to branch first. Branching and merging have to feel as natural as they do on GitHub.
Conflicts. Two branches that change the same entity need clear detection and a way to resolve it: automatic where a rule fits, human where it does not.
Tooling. Visual diffs, review screens and conflict viewers are what made GitHub usable. Building them for data, which is richer than text, is real work.
Scale. Branching and merging must stay cheap at millions of entities. Structural sharing, storing only what changed, is essential. A branch that copies the dataset does not scale.
What to ask
Are branches cheap? Creating one should be immediate and store nothing until something changes.
Can you diff two versions? Not "something changed" but which entities, relationships and properties: a diff you can review.
Is there review? Can a steward inspect a change before it reaches production, or is every write immediate and final?
Are commits immutable and signed? Can you check who changed what, and whether the past was rewritten?
Can you query past states? "The graph as of commit X" should be a query, not a replay.
Does it hold for machines? Agents, pipelines and jobs should follow the same branch-and-merge path as people. Any write that skips review is a hole in the model.
Try it in Legra
Try the review data changes tutorial: add a record on a proposal branch, compare query results, merge, and verify the shared data.