Git Pull in SQL Source Control

I wrote recently on Git Push in SQL Source Control (SOC), and now wanted to add the other side of the story, pull. This process is even simpler.

I’ll be working with a new database, one that has two client systems set up already with Git support. I know I haven’t tackled that part of SOC and Git, but I’ll do that in a new post.

In this case, I’ve got a repository on Github for my Redgate and SQL in the City demos. It’s a sample database, but I’ve been making multiple changes to the database across time, using Version Control as a way of continuity, and then being able to rollback changes or see history.

I’ve got a connection in a VM to a second development machine. When I launch my VM, and SSMS, I go to the second SOC tab, the one that is labled “Get Latest.” You can see the image below, and notice that there are two buttons in the upper left. There is the familiar “Apply changes to database,” which has been the way that we pull changes from TFS and SVN, but now there is a new “Pull from remote respository.” This is the one specific to Git.

2015-10-22 23_19_54-OneNote

In this case, I’ve refreshed my database previously in sync with the local Git repo. Therefore the button is grayed out. However, I don’t know if there are remote changes until I click the other button.

I do that and get the familiar four step dialog from SOC that checks for changes and then compares them to the local database. However what you don’t see is that a “git pull” is issued first, pulling changes from the remote repo. In my case, I had one change I’d made in London, actually, and hadn’t synced with my VM.

2015-10-22 23_20_15-salesdemo-2015-02-25-1422-export-i-fgg5cstb - VMware Workstation

This is the familiar SOC actions now where I see the changes and can use the “Apply changes to database” to compile this code in my local database.

In some sense, this is less exciting then push, but it’s nice to be able to do this in the client.

I’ll write some more on the workflow as I develop changes in the coming posts, which are going to be aimed at building a small database in Azure SQL database and moving changes from my local system to Git for tracking, and then to Azure for production use.

Git Push in SQL Source Control

I’m excited. Git support is growing in SQL Source Control and the release recently contains Git push/pull support. If you don’t see the release of 4.1.x, you need to update. The update should be available for everyone.

I do like Git. I’m working with SVN, TFS, and Git on a regular basis. However I tend to prefer Git overall. Now I can do most things I want to do in SOC, which is exciting. No forgetting to push or the need to drop to the command line or another interface.

The Git Additions

In a previous post, I set up a link between a database and a Git repository. Let’s see how the Git push now works.

I’ve got this database on my local instance.


It’s linked with SQL Source Control to a local Git repository.


Let’s change something. I’ll pop open a stored proc.


Let’s make a simple, but real, change. I’ll add a NOCOUNT setting in there, which is a good idea.


In the Commit tab for SQL Source Control, I see my change. Note that most everything looks the same here and I can see the code differences like I always could.


Now I commit this change. In this case, it goes to my local Git repo, but isn’t pushed.

NOTE: In the real world, I’d pull before I commit to be sure I wasn’t causing a merge issue.

Once that’s done, my Commit tab changes.


SQL Source Control (SOC) detects the change and knows we have an unsynced Git repo. I can now push the “Push” button. Once I do this, I get a warning if I haven’t turned this off. I turn it off, but you should always be aware that SOC isn’t managing your Git repo. It’s linking to it. If you make changes in the repo with some other app, like Visual Studio, the entire repo is pushed, not just the change SOC committed.


Once this is done, I once again see a clean Commit tab.


However, if I go to the remote repo, which is on GitHub in this case, I see my change.


I love Git. I think it’s really cool, and it’s a great way to work with distributed Version Control. I am playing with TFS as well, but I prefer Git, and I think this support is great.

There are still things needed, things I want, and more, so be sure you add your votes to the SQL Source Control UserVoice page and let the SOC team know what’s important to you.

If you’re not using SQL Source Control, you might check it out and give it a try for a month:

SQL Source Control and Git–Getting Started

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.

As a result, I wanted to do a quick setup using SQL Source Control (SOC) and Git, showing you how this works. SOC supports Git in a few ways, so this is the primary way I’d see most people getting started.

Update: Since this was published, the SQL Source Control team released an updated version (v4.1) with support for Git that allows push/pull within the client. I’ve got an updated post here.


Here’s the scenario that I’ll use. I’ve got a database, WindowDemo, that has a few tables, some data, and a few procs. As you can see below this isn’t linked to a VCS.

2015-09-24 16_34_56-Cortana

I want to store my DDL code in c:\git\WindowDemo\trunk. I’ve got that folder created, but it’s empty. I’ll keep related database stuff (docs, scripts, etc) in c:\git\WindowDemo if I need it.

2015-09-24 16_37_36-Photos

Git Setup

The first thing you need to do is get your Git repository setup. There are many ways to do this, but I’ll use the command line because I like doing that. The commands in the various client GUIs will be very similar.

I’m going to set the git repository here at c:\windowdemo to keep all my database stuff in one place. To setup the repository, I run a git init in the command prompt. This initializes my repository.

2015-09-24 16_41_02-Photos

Now I have a git VCS, I need to get code in there.

SQL Source Control Setup

Now I move to SSMS to link my database to the repository. In SSMS, I right click my database and select “link database to source control”.

2015-09-24 16_42_27-Start

This will open the SOC plugin on the setup tab. I’ve filled in the path to the place in the repository I want the code to go. This is the trunk folder. I’ve also selected Git, using the “Custom” selection on the left and Git in the dropdown.

2015-09-24 16_43_54-Link to source control

Once I click the link button, I’ll get a dialog showing progress and then return to the setup tab.

2015-09-24 16_44_15-Start

Notice the balloon near the top. This lets me know the link is active and I have changes in my database that aren’t in the VCS. There’s a pointer to the “Commit changes” tab, so I’ll click that.

2015-09-24 16_48_00-New notification

In the image above, I see I have a number of “new” objects from the perspective of the VCS. I can see the name, and the type of object in the middle. At the bottom, I see the version in my database (highlighted code) on the left and the version in my VCS (blank) on the right.

This is where I commit my changes. I enter a comment at the top and click the “commit” button on the right (not shown). When I do that, I’ll get a clean “commit tab” that shows that my VCS is in sync with my database DDL.

2015-09-24 16_50_18-SQL Source Control - Microsoft SQL Server Management Studio

Inside Git

What’s happened in my VCS? Let’s look in the file system. Here I see my trunk folder.

2015-09-24 16_51_49-Photos

SOC has created a structure for my DDL code and included some meta data. If I look in one of these folders, such as Stored Procedures, I see

2015-09-24 16_58_56-Photos

This is the .SQL code that matches what’s compiled in my database. SOC stores the current CREATE statement for all my objects so that they can easily be examined.

Inside Git, I see a clean status with all my files as committed objects.

2015-09-24 17_02_57-Start

This is what I want. Now I can continue on with database development, tracking all my changes. I’ll look at the flow and tracking changes in another post.

Starting with Git for Database Development

One of the tools that Red Gate Software makes is SQL Source Control. It’s a plug in to SSMS that allows you to hook your database up to version control. I’ve used it a few times in the past in conjunction with Subversion to demo the product. However I hadn’t really used it for my own scripts since it’s primarily a single server system and not distributed. My own demos were on VMs with limited connectivity to the world.

A few weeks back, I was flipping through the Talk newsletter, and saw an article on Continuous Integration for SQL Server using Red Gate Tools, Atlassian Bamboo, and Github. I’ve had many people over the last few years ask me about Git support for SQL Source Control and I was curious to see how well we supported things. I read the article and started downloading things.

The first thing I downloaded was GitHub for Windows. I installed it and wasn’t thrilled to see it not working. However what was unclear in the article and the installation was that this is just a GUI for your Git installation. Since I hadn’t installed Git, I needed to do that. Once I had done that, and set up a Github account, things worked fine.

I have numerous databases that I use for talks, but I usually create and destroy them with scripts during the talks. Not quite the way that SQL Source Control is designed to work. It works with objects, not scripts. However I wanted to test things, so I decided to build a database with the objects in it already. I wasn’t sure this would work for demos, but it would be a good test.


As you can see above, there are a few objects in my database.

My next step was to pick a place on my local drive where I could store my Git data. Since I do a lot from Management Studio, and use quite a few VMs, I wanted a standard location I could use easily and chose a folder under my SSMS installation.


Once this was setup, I created a new repository on my drive.


This was the place I’d keep all my code. With a free GitHub account, you can’t keep your code private, but that’s OK for this project since I give all my code away after talks.

Once I’d created this, Git put the folder on my drive.


Inside the folder was nothing, just a few Git files.


And in my Github interface, there was nothing to commit.


The next step was to link this with Git. After selecting my database in the Object Explorer, I switched over to the SQL Source Control tab to link my database to source control. I entered the path of my Git folder (from above) and selected Git as my VCS.


I chose a dedicated database, meaning this is just my database. The Shared database model can work, but I don’t like it for teams, or even solo.

Once this was done, I could see my database linked in SSMS.


I clicked the “Commit Changes” tab, and could see my three objects listed there as new items to commit.


If you have an existing database, this is the situation you’ll find yourself in most of the time. You link it, and commit all the changes. Once you enter a comment (please enter real comments you’ll understand), and press Commit, the objects are added to your folder. If I look at the folder, I see more stuff:


Only a few folders have objects, and those contain the .sql files for those objects.


If I look at Github, I see my comment and the changes are committed, but unsynced. If I press the “publish” button at the top, these are sent to Github.


That’s it. Any changes I make to objects, which I’ll show in another post, will commit to Git, and I can sync them to GitHub.

Come learn more about these topics on the SQL in the City 2013 tour.