What is Source Control?
Definition
Source control works by recording every change as a commit: a timestamped snapshot of what changed, who made the change, and why. That history makes it possible to compare any two points in time, revert a specific change without touching others, and see exactly when a given line of code, or a given database change, was introduced. Applying this to a database means a ChangeLog lives in the same repository as the application code it supports. A schema change goes through the same pull request, review, and approval process as any other code change, instead of being applied directly to a database outside that process. The database's history becomes as traceable as the application's, and both can be reviewed, tested, and rolled back the same way.
Why source control matters
Without source control, a change exists only in the place it was applied and in whatever memory or notes the person who made it kept. Two people can make conflicting changes to the same file without knowing about each other's work until something breaks. There's no reliable way to answer basic questions later: what changed, when, why, and who approved it.
Source control solves this by making the repository the single record of truth. Every change is visible to the whole team, in order, with a reason attached. For database schema specifically, this closes a gap that has often been treated as separate from application code: instead of a database changing on its own timeline, disconnected from the code that depends on it, both move through the same history, the same review process, and the same release.
How source control works for databases
A ChangeLog file lives in the same repository as the application it supports, usually alongside the code that depends on the schema it describes. A new database change is added as a ChangeSet in a feature branch, reviewed through a pull request the same way a code change would be, and merged once approved.
From there, the same repository history that tracks application releases also tracks database releases: a tagged version corresponds to a known, reproducible set of ChangeSets, not a database state that has to be inferred after the fact. When a pipeline deploys a given commit, it can deploy the exact ChangeLog that commit points to, so the application and the database it depends on move forward together instead of drifting apart.
How Liquibase helps
Liquibase is built to read a ChangeLog directly from source control rather than from a separate change management system. ChangeSets committed to a repository can be picked up by a CI/CD pipeline the same way an application build is, so a database deployment becomes just another step in the same release process instead of a manual task running on a different schedule. Liquibase Secure adds Policy Checks that run against a ChangeSet before it deploys, so a change that violates a defined standard can be caught at review time, in source control, rather than after it reaches a database. The result is a database change process that lives inside the same workflow engineering teams already use for everything else.
