Code review is where the cost of a missed dependency shows up. Vibgrate Graph gives reviewers a structural view of every change so they can judge risk instead of guessing. This guide shows how to fold the graph into your review flow.
Start with a fresh graph
Build or update the graph so it reflects the branch under review:
vg build
Understand the blast radius
For any node a pull request changes, check what depends on it before approving:
vg impact
A small, contained blast radius is reassuring. A large one is a prompt to ask the author for more tests, a smaller change, or a clearer rollout plan. Because impact analysis is deterministic, the reviewer and author see the same picture.
Verify the immediate wiring
Use vg show on changed nodes to confirm their callers and callees match the intent of the change:
vg show
This catches surprises early — for example a function with far more callers than the author realized.
Surface the tests that should pass
Ask the graph which tests a change should exercise, and confirm the author ran them:
vg impact --tests
If the affected code has thin test coverage, that is a legitimate review comment.
Trace surprising connections
If a change touches two areas you did not expect to be related, confirm the link:
vg path
vg tree --callers
A lightweight review checklist
- Rebuild the graph on the branch.
- Run impact analysis on changed nodes.
- Confirm callers and callees with vg show.
- Check the relevant tests with --tests.
- Trace any unexpected connections with vg path or vg tree.
Related
See the articles on impact analysis before a change, interpreting impact output, and exploring the call tree with vg tree.