Skip to content

Starting with Git for Database Development

May 8, 2013

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 https://www.simple-talk.com/Simple 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.

git_a

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.

git_b

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

git_c

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.

git_d

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

git_f

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

git_e

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.

git_

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.

git_h

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

git_i

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:

git_j

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

git_k

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.

git_l

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.

sitc

About these ads

From → Blog

One Comment

Trackbacks & Pingbacks

  1. T-SQL Tuesday #42–The Long and Winding Road | Voice of the DBA

Comments are closed.

Follow

Get every new post delivered to your Inbox.

Join 4,537 other followers

%d bloggers like this: