Review and commit changes

Every metadata edit you make lands on a branch, not on main. Review and commit is where you look over those pending changes and turn them into a commit. Switch to a feature branch first: on main the surface shows “Switch to a branch to see pending changes”, because main can only receive changes through a pull request, never a direct commit.

Settings changes are branch edits too: adjusting casing, naming patterns, system columns, Data Vault, or Data Mart settings, and clicking Apply platform defaults, all act on your active branch and reach main through this same commit and pull request flow. The target platform choice (and its dialect configuration) acts on the active branch in the same way: an edit on a feature branch reaches the main branch through the commit and pull request flow.

The branch’s changed entities appear in the tree on the left, one file per entity. Click any entry to see its before-and-after diff on the right, and toggle between the form view and the raw YAML with the view switch. Revert entity drops a single change; Revert all clears the branch. When the list looks right, click Commit….

The commit dialog, titled Commit branch, asks for one thing: a Message. Type a short description of what changed and click Confirm. DeltaVault serializes each changed entity to YAML, pushes a commit to your branch on GitHub, and opens a pull request against the default branch (or updates the existing one). The success toast carries a View PR link straight to it.

Commit progress

A commit touching dozens of files takes a few seconds, so the dialog shows you exactly where it is. Once you click Confirm, the button switches to Committing… and a live checklist appears below the message field with six ordered phases:

1. Compute changes
2. Validate
3. Serialize files
4. Push commit
5. Open pull request
6. Finalize

The active phase spins; finished phases get a check. Serialize files picks up a count once it starts, so it reads Serialize files (24 files) for a 24-file commit: a quick confirmation that the file total matches what you reviewed.

If a phase fails, its step is marked with an error icon and the error message is shown right under the checklist, so you can see exactly where the commit stopped and why. The commit dialog stays open after a failure with your message intact, so you can fix the cause and click Confirm again without retyping it. One thing to settle before you start: if the banner above the tree warns that GitHub is not connected, connect a repository first, because the commit can’t push without it. The banner’s own Configure repository link takes you there, and the destination is Settings → Source Control.

Reading the YAML reference companions in a pull request

When DeltaVault serializes your metadata to YAML, every reference between entities is written as a ULID, the portable identifier that stays stable across renames. ULIDs are precise but not human-readable, so each reference also carries a fully qualified name (FQN) companion next to its ULID:

• A column’s lineage (sourceColumns), its reference column, and its business attribute each gain a columnFqn or attributeFqn.
• A table’s business entity gains an entityFqn, and a table’s transformation carries sourceEntityFqn, dimTableFqn on each dimension reference, a columnFqn on each measure, and an index-aligned sourceTableFqns array beside sourceTableUlids.

These companions make a pull request diff readable at a glance: instead of an opaque identifier you see, for example, raw_mssql.AdventureWorks.dbo.customer.customer_id. The ULID stays authoritative; the FQN is a best-effort, human-readable hint. If you rename an entity, its embedded FQNs may go stale until the next commit or a reconcile sweep refreshes them, which is expected and harmless because DeltaVault resolves a reference by ULID first and only falls back to the FQN when the ULID does not resolve.