This article explains the --baseline flag on vg init and when to prefer it over running the two steps separately. It is aimed at developers onboarding an existing codebase.
Overview
Most projects need two things on day one: a Vibgrate setup and a starting point to measure drift against. vg init --baseline does both. It initializes the .vibgrate directory and configuration, then captures an initial baseline snapshot so later scans can report drift as a delta from where you started.
When to use it
Reach for vg init --baseline when you are adopting Vibgrate on an existing repository and want to start tracking change from today. If you are still exploring and not ready to commit to a reference snapshot, run a plain vg init first and create the baseline later.
Step by step
From the repository root, run:
vg init --baseline
This sets up the project and records a baseline in one pass. Then run a normal scan:
vg
Because a baseline now exists, you can compare future scans against it and gate on how far drift has moved.
Comparing against the baseline later
When you want to scan explicitly against a stored baseline file, point to it:
vg scan --baseline .vibgrate/baseline.json
This is the foundation of drift fitness functions: the baseline is the known state, and the scan reports the delta.
Tips
- Commit the baseline so your whole team and your CI compare against the same reference.
- Refresh the baseline deliberately after intentional upgrades, not on every change, so it stays meaningful.
Related
See the baseline creation and refresh guides for the full lifecycle, and the drift budget article to turn the delta into a pass/fail gate.