A code graph is only as useful as it is current. If the graph is stale, impact analysis and call trees describe code that no longer exists. This guide explains how to keep the graph aligned with your working tree.
Why freshness matters
Every graph query reads from the same artifact. If you refactored a module yesterday but never rebuilt, vg impact and vg tree will report the old structure. Keeping the graph fresh is what makes its answers trustworthy.
Rebuild incrementally
The simplest habit is to re-run the build after meaningful changes:
vg build
Because builds are incremental, this updates only what changed and is fast enough to run often. Treat it like recompiling: when the code moves, refresh the map.
Good moments to rebuild
- After pulling new commits from your team.
- After a refactor that moves or renames functions.
- Before opening or reviewing a pull request that depends on accurate impact analysis.
- Before an onboarding walkthrough so newcomers see the real structure.
Verify before you rely on it
When in doubt, rebuild and then spot-check a node you just changed:
vg build
vg show
If vg show reflects your recent edits — the right callers and callees — the graph is current.
Sharing freshness across a team
If your team relies on the graph collectively, making it committable and auto-updating keeps everyone in sync without manual rebuilds. The vg share workflow installs the hooks and merge handling that keep a shared graph current; see its dedicated documentation for details.
Common pitfalls
- Querying without rebuilding after a large merge — always rebuild after integration.
- Assuming a one-time build stays valid forever — it reflects the code at build time.
Related
Pair this with the guides on building your first code graph and interpreting impact output. For team-wide freshness, explore the vg share workflow.