Your codebase has branches. Your context graph should too.

Problem

One graph, many realities

In part one, lgraph update kept a context graph in sync with ROOT — but only for one developer. Teams don't work that way: they're spread across devices, time zones, and above all branches. A graph indexed on Alice's laptop for main tells Bob nothing about the feature branch he's shipping, and neither of them anything about what the team in London is building. Because branches are isolated lines of development with their own structural reality, a branch-blind graph doesn't just go incomplete — it presents main's structure as truth for code that only exists on a branch. And lgraph update can't fix that: it's a single-graph, single-device operation.

That breaks down in three distinct ways:

C-04

Branches collide in one graph

Two efforts on different branches get reconciled into a single hybrid that reflects neither, so parallel prototypes can't each keep their own design.

C-05

Feature work flies blind

A graph that describes main can't see the abstractions being built on a feature branch, so the agent works against an architecture that isn't there yet.

C-06

No graph for new or remote devs

The graph lives with whoever ran lgraph init; everyone else either runs a full, expensive pipeline or works with no context at all.

Solution

Branch-isolated graphs with fast replication

Every branch now gets its own fully isolated context graph. A developer can fork a graph from any existing branch, receive a complete copy of all graph state in seconds, and then run incremental updates on that branch in isolation.

The key mechanism

Under the hood, every record in the graph is tagged with the branch it belongs to, and every read and write filters on that tag. Forking is just a copy: duplicate the source branch's records, stamp each with the target branch's name, and that branch has its own complete graph. Nothing is scanned, no LLM runs, no pipeline spins up — it's a data copy, not a re-index, which is why it finishes in seconds.

Branch graph replication · conceptual flow

main

the shared origin, always visible, and the source every new branch forks from

join 19 collections copied →

feature/auth

independent incremental updates, fully isolated

feature/team-b

a parallel effort with its own graph, never collides

How a branch is represented

Each branch is a document in a branch registry. The default branch (main) is created at project init; every other branch tracks where it came from, who created it, and whether it's been shared:

Branch registry document

{
  project_id:            "189e9b57-..."
  branch_name:           "feature/auth-rewrite"
  source_branch:         "main"          # copied from
  user_id:               "user_abc"      # who created this branch graph
  active_head_commit_id: "a3f82c..."     # last indexed commit
  is_default:            false
  pushed:                false           # false = private to creator
  created_at:            ISODate
}

What actually gets copied on join

When a developer joins a branch, 19 graph collections are replicated from the source branch to the new one. They fall into two groups:

7 object-store collections · manifest fast path

When the source commit has a manifest hash, these replicate by reference, reconstructed from a content-addressed snapshot rather than copied row by row.

drg_graph
codewiki_docs
codewiki_module_tree
codewiki_snapshots
codewiki_metadata
codewiki_tag_index
pr_insights

12 derived collections · always row-copied

Dependency and analysis state, copied directly with the branch field rewritten.

dep_dependencies
dep_dependents
dep_symbol_table
dep_raw_extraction
dep_unresolved
implicit_deps_map
implicit_dep_entry_points
implicit_dep_graph_nodes
call_graph
community_detection
file_index_snapshots
coupling_scores

After the collections, three metadata documents are replicated with rewritten keys: the pipeline baseline, carrying the last_commit SHA so the new branch knows exactly where to diff from on its first lgraph update; the implicit-dependency metadata; and the PR-insights watermark, so the child branch doesn't re-mine pull requests the source branch already processed.

That last group is what makes the copy genuinely useful rather than merely fast: the new branch graph arrives knowing its own history, ready for incremental updates from its first minute.

Private by default, shared by choice

Branch graphs start private to their creator (pushed: false). Only the branch creator or the project owner can promote a branch graph to team-visible (pushed: true).

Who can see it	State	Typical use
Creator only	`pushed: false`	Private iteration on a feature branch
All project members	`pushed: true`	Team-shared branch graph; shared context for PR review
All project members	`is_default: true`	`main` · always visible, the replication source for new branches

This gives individual developers a private space to iterate before exposing their branch context to the team, mirroring how branches work in git itself.

What this changes for a team

A new team member gets a complete, current graph in seconds instead of running a full pipeline, or going without. Feature work gets context that reflects the feature branch, not a description of main that stopped being true the moment the branch diverged. Parallel efforts stay parallel: each branch's graph evolves with that branch, and nothing merges until someone decides it should. And the main graph stays clean, since nothing on any feature branch touches it.

Try it

As a teammate, after being added as a contributor:

lgraph start                      # authenticate with your own key
lgraph join main my-feature       # copy main's graph in seconds, not a re-index
lgraph update                     # keep your branch's graph at your branch's ROOT
lgraph push my-feature            # share it with the team when you're ready

Prefer it hands-off? Wire these into your git workflow so they fire under the hood: lgraph update on every git commit, and lgraph push right alongside git push. Your branch graph then tracks your branches on its own, with no extra commands to remember.

Get started at lgraph.dev →

Part 3 of 3 · Read next

Your graph now travels with every branch. But it still only knows what the code is, never why your team built it that way.

What one agent learns, every agent knows →

Missed the start? Part one covered how incremental, diff-driven updates keep a single graph fresh: Code changes. Context graphs don't.