How to Set Up Version Control for a SQL Server Database
Connect a SQL Server database to your source control system from within SQL Server Management Studio
Everyone knows that source code files belong in a version control system... but databases aren't typically stored in easily-versioned files. A significant portion of code is left unsecured simply because committing it takes too much time, too much work.
This article will demonstrate how to solve this problem using VersionSQL, Subversion, and SQL Server Management Studio 2016. The same steps apply to Git and SSMS 2012, 2014, and v17.0. All software has been installed and the test system has direct network access to both SQL and source control servers.
Bridging the Gap
Open SQL Server Management Studio and connect to a SQL Server instance. Right-click on your database in the Object Explorer pane and select "Connect to Version Control". This will open the "Connect Database to Version Control" dialog.
Type in the repository path under which the database scripts should be saved. If the subdirectory you specify does not exist, VersionSQL will create it for you the first time you commit.
After clicking OK you will be prompted for user credentials to your version control system.
That's it! Your database is now connected to source control. Continue on to check in your database scripts.
Saving Everything
A version control system connection does little good if nothing is ever checked in, so VersionSQL immediately prompts for a full commit after setup.
(Note: You can always initiate a full-database commit later by right-clicking on the database in the Object Explorer and selecting "Commit Entire Database")
Click Yes, optionally write a short log message in the window that appears, then click OK to begin sending data.
VersionSQL will script out all the objects in the database and send them to the version control system.
The database objects are saved as plain .SQL files, just as if you had exported them from SQL Server Management Studio
yourself.
Congratulations! You now have a version-controlled database. A quick commit from time to time during development will produce an audit trail of revisions -- a historical record of database schema changes tracking who made each change and why.