In a recent blog post my colleague and SQL Server MVP Steve Jones said “It seems as though Git is taking the world by storm as the Version Control System (VCS) of choice. TFS is widely used in the MS world, but Git is growing, Subversion is shrinking, as are most of the other platforms.”

I am a test engineer on the SQL Source Control team at Redgate. For a bit of context; SQL Source Control is a software tool which enables you to link your database to your version control system, making database version control really quite easy. That’s what we hear from our users anyway…

So, what’s new? Given the increase in usage of Git over recent years we decided the time was right to improve our integration with Git. As of version 4.1.2 (released on October 14th) we now allow you to:

• Link to an existing Git repository on your local machine, and commit and apply changes.
• Push to a remote Git repository, using the Commit tab.
• Pull from a remote Git repository, using the Get Latest tab.
• View history for a database linked to Git.

And how is that different from/better than before? Previously you could save changes to a working folder or commit changes to your local Git repository using our command line hooks, but you’d have to go outside of SSMS to your Git client to push to and pull from your remote repository. Revision history also wasn’t available. So now it’s heaps easier.

I’ll show you more here, but for a shortened version of how to push and pull check out these short videos from Steve.

“How do I unlink my database from my current VCS / working folder etc?” If you already use SQL Source Control with another version control system, or with Git, via our command line hooks or working folder option, you can easily unlink from your database. Just click on the database in the Object Explorer, click Other SQL Source Control tasks, then Unlink database from source control… When prompted click Yes.

“How do I link my database to Git?” Just click on the database you want to link in the Object Explorer and follow the quick wizard in the Setup tab. In the first window select Link to my source control system and click Next.

Then you just select Git, click Next, specify a folder in an existing local Git repository where SQL Source Control will save your scripts, click Link, and then you’re ready to go.

The database icon in the Object Explorer changes to show that the database is linked. Very Handy:

“How do I get all of my database objects into version control?” Once you’ve linked your database to Git, you’re ready to make your first commit (or initial commit). This gets a copy of your database into version control.

To make the initial commit, go to the Commit changes tab. This tab lists database changes that haven’t been committed to version control yet:

To commit your database objects to version control make sure all the objects are selected, write a commit message (e.g. “Initial commit”), and click Commit.

The same goes for committing new changes. Video here.

Now for the clever bit… “How do I push my database objects from my local repo to my remote repo?” To get objects into your remote repository, you need to push after you’ve committed them.

To do this, find the blue banner above the commit grid and click Push. This pushes all commits from the local repository to the remote repository.

If it’s the first time you’ve done this then there’s a handy little warning box which pops up to tell you that pushing from your local to your remote repository will push all non-database files and any commits made, whether inside or outside of SQL Source Control, too.

You can mute this message but you should always be aware that SQL Source Control isn’t managing your Git repository, it’s linking to it.

“And when I want to make sure I’m working on the latest version of the database…?” Video here. Similarly, it’s now possible to pull changes straight from your remote repository, and then apply those changes to your database, to make sure you’re working on the latest version.

When changes are available in version control you’ll see a blue dot appear on the database icon in the Object Explorer. Simply go to the Get latest tab, and you’ll see your database changes waiting to be retrieved from the remote repo (if you don’t, just refresh).

Click Pull from remote repository and any changes from the remote repository will be pulled to your local repository.

Clicking Apply changes to database will deploy the changes from the local repository to the database. Again, you’re warned about non-database files being pulled too.

And now you’re all up to date!

“How do I see the history of changes of a specific object?” With the latest release you can now view the revision history of a database or database object, when liked to a Git repository.

In the Object Explorer, right-click the database or object and click View history. The History dialog box opens…

…and shows:

• each database revision in version control
• the author, date, and comment associated with each commit
• which objects changed in each commit
• the SQL differences for each object (before and after)

And that’s about it. These changes are the first part of our work towards more comprehensive Git support. If you’re interested in learning more about our plans then take a look at our roadmap.

And if you have any feature requests around our work on Git, or anything else in SQL Source Control we’d love to hear them. Visit our Uservoice site to vote on existing ideas or add new ones of your own.

And finally, if you’re reading this but you don’t own SQL Source Control yet then I suggest you download a free trial from our website.

More from me and the rest of the team soon.