Every change you introduce to a Repository—regardless of the change being a “content change” or a “schema change”—needs to be committed.
You can think of “commit” as your “publish action“. We chose the “commit” naming because the action itself is closely related to how Git works, and Git uses “commit”.
Before committing, you'll be able to see the changes you’re introducing via the Diff View.
A Commit records an immutable snapshot of your Repository at that specific point in time. Content that’s committed will never change, and that allows for the robust versioning capabilities that BaseHub is after: diffing, reverting, branching.
You’ll be able to see the history of your Commits in the “Commits” Tab (in the middle of the header). This is a great way of quickly checking out how your Repository is evolving.
What Happens at Commit Time
When you press “Commit”, we’ll check that all of your Blocks pass the validation you created via Constraints. This is our time to make sure your “Required” Blocks actually have values in them, so we can then confidently expose them via the Delivery API.
Additionally, we’ll update the Delivery API’s cache so that it targets this new commit. This diagram might provide more clarity of the whole flow: