A code map that only one developer has is a missed opportunity. When the whole team shares it, everyone gets the same structural understanding, the same impact analysis, and the same AI context. This guide shows how to adopt vg share across a team and keep the map healthy in version control.
Overview
vg share makes the code map committable and auto-updating. It installs a pre-commit hook to keep the committed map current, a deterministic merge driver so the graph reconciles cleanly across branches, and .gitignore entries that track the right files. The outcome: teammates get an up-to-date map simply by pulling.
Prerequisites
A Git repository and a built code map:
vg build
Step 1 — Enable sharing
Run the command once in the repository:
vg share
This sets up the hook, merge driver, and .gitignore rules. Commit the resulting changes so the configuration reaches everyone.
Step 2 — Onboard teammates
When teammates pull, they receive the committed map and the sharing configuration. They should confirm everything is wired up and current:
vg status
If they also use AI assistants, they can connect them to the local context server:
vg install
vg serve
Step 3 — Keep it fresh
The pre-commit hook keeps the committed map aligned with code as people commit. Periodically verify with:
vg status
If the graph drifts from the working tree, rebuild and commit:
vg build
Avoiding merge conflicts
The deterministic merge driver is what makes team sharing practical: it produces the same merged graph regardless of branch order, so parallel work does not generate noisy conflicts in the artifact. This is the key difference between committing a code map and committing an ordinary generated file.
Troubleshooting
If the committed map looks stale after a pull, run vg status to confirm, then vg build to refresh. For deeper issues, see troubleshooting graph export and share.
Related
- Make the map committable with
vg share. - Check freshness with
vg status. - Add the AI integration with
vg install.
Sharing keeps the map inside your own repository.