DataChomp

Chomping At The Bits

GIT and Red Gate SQL Source Control

This post is over 2 years old and dealt with early versions of the product. A lot has changed since then.

I am a huge fan of Red Gate SQL Source Control because it makes source controlling/deploying your database easier. I am aware of the MS Database Projects abomination application and the short version on that is that I have deemed them unworthy for my use. There are lots of tutorials and examples of using RG SSC with centralized version control systems like Subversion or TFS and it does work wonderfully with them. Recently, my workplace decided to ditch TFS and move to a more modern distributed version control named Git. Like most disruptions to your workflow, there are a few growing pains. This post is going to cover installing Git on Widows, hooking it up to github.com and showing some basic actions as we change our database.

Install Git:
Download the full installer for Git and install it.
While you are mindlessly clicking ‘next’ make sure you integrate with CMD. This is critical for RG SSC and just a convenient thing to do in general. The important part will look like this:
sourcecontrolcmd

Aside: I’m a converted fan of posh-git. Using things like the Git GUI or Tortoise GIT will be incredibly tempting, and perhaps for initial familiarization, it might be a good idea to use those to visualize some concepts. That being said, it is really in your best interest to move towards the CLI and posh-git is very helpful in that regard. It isn’t nearly as bad as you think once you get going.

Repo Hosting
Once you have Git installed, you will want to hook up to some hosting. An incredibly popular and easy to use one is Github.com but there are plenty of others.

Repo Man
In Github, you will want to create your repository and assign your SSH keys. This process can be a bit more than you are used to at first, but GitHub as great at giving you some hand holding instructions:
Once the repo is initialized, I like to create a folder for the App and a folder for the database like so:
folder layout
You don’t have to do it like that, but again, that is the way I currently like to do it.

Lets hook up the DB!
Why use the Adventure Works database? Since it is a bit of a marketing database used to show both neat and inane features, we’re hooking it up just to make sure all types of various objects work just fine with RG SQL Source Control.
From there, go to SSMS and link up the DB to your local repository:
repo linko repo linko

Command Line Interface … or whatever
Back in powershell (or whatever client you are using) create a new branch for updating our proc. git branch dbobjects Note: We don’t have to create a new branch. We could very easily just keep doing this in the ‘master’ branch. I find that creating of the branches to be a good habit and a handy organizational tool. Branching is one of those features that really shines in Git so lets put it to use.
Go into that branch: git checkout dbobjects
branchard

Now, we go back to SSMS and commit our changes:
no hands!
Cool! Our “dbobjects” branch has been committed locally, now we just need to merge it into our master branch!

From there, go back to master: git checkout master
and then merge into master our dbobjects branch: git merge master dbobjects
After we have merged, we can delete the branch we were working in by running:
git branch -d dbobjects and the process will end up looking like this:
master merge

If you look on Github, you will see that nothing has changed there. Why is that? That is because all the work we have done has been locally. This is the essence and the speed of a distributed control system. We can commit, fix, break all we want without getting everyone else mad. However, at some point, we will need to send our changes off so that others on the team can use (laugh) at them. We do this by “push”ing to the origin: git push -u origin master
origin

Now, if we look at Github, we see our changes in the main repository, and if we go to check it out again:
yay

We can see them there for people pulling down changes. You’ve done it. Now you too can participate in the source control fun with the AppDevs and make nerdworthy comments about rebasing, merging and pushing master.