When I heard that Redgate had improved the Git support in SQL Source Control, I have to confess I got excited about it. I even tweeted about it. There’s a good reason for that too.
I fell in love with SQL Source Control the first time I used it in another company. Before it came along, we scripted out database objects, which is a pain. At one point in one company, we used the Visual Studio version, and that’s painful as well because you don’t get the immediate gratification of knowing what’s changed. You have to actually bring in the changes and then see what your changes are. I just found that very cumbersome.
SQL Source Control makes it a really easy process and defines all of your changes. It’s especially useful if you’re working on multiple projects and one project is sitting there for three weeks and you come back and look at the changes. You might think, for example, oh yeah, I was working on indexing and I should probably get those indexes into production. Using SQL Source Control, you can do it quickly and easily.
The missing link
As much as I love SQL Source Control, a niggle I’ve had has been its limited support for Git. Like many other people, I moved from Subversion to Git because its branching features are so much better, and adopted Atlassian Stash (now called Bitbucket Server) as the repository.
That’s where I had a difficulty because there was a gap between SQL Source Control and the Stash repository on the server. I tried a workaround using command prompts, but it was so painful and cumbersome I turned to Atlassian SourceTree instead. A free Git client, it provides a visual GUI to do the push and the pull between the server, Git, and the local repository.
At the beginning of October 2015, everything changed. That was when Redgate announced SQL Source Control users could now push to and pull from remote Git repositories.
And not just from within SQL Source Control – from within SQL Server Management Studio (SSMS).
I was thrilled because this one apparently small move eliminated an entire step in another application. No more closing this, opening that, moving this, quitting that, going back to the application you were happily working with before.
It also made things a lot clearer to team members who were new to using version control by taking the complexity out of the process.
You’re not out of the woods yet, Redgate
I use SQL Source Control every single day and I’ve now got my entire team checking in their changes using Git.
They can commit changes, get the latest changes, and do everything they need to do without complications. As well as saving time, it makes it easier for less technical staff who are new to using repositories. A glance at what it looks like in SSMS demonstrates how simple it is:
So it has made my life easier, but do you know something? There are still some improvements I’d like to see.
What branch am I on?
Top of the list would be to see which branch I’m on. Right now I can see which database I’m on, but not which branch
How many changes are ready to push or pull?
Near the ‘Push’ and ‘Pull’ buttons, it would be nice to know if there are files to pull or push, in case other stuff has been checked in from other users. A number on the buttons would work as well, to show how many items have been checked in locally and are ready to go up or come down.
The pull button is the more important one, to make sure you’re on the right version. Team keep forgetting to pull down changes that exist on the repository so this would be a real bonus.
What about conflict resolution?
Conflict resolution would be another great feature because sometimes it’s difficult. The developers don’t always remember to bring down the latest version and when they check something in, it causes a conflict. I think I spent an hour fixing that yesterday, and I still have to go back and deal with it on one of my team mate’s machines.
Right now, I use KDiff3 to merge our QA branch and personal branches to fix conflict resolution, but a feature within SQL Source Control would make things a lot simpler.
Finally, I’m looking forward to when SQL Source Control is incorporated with migration scripts. At that point, everything will become a breeze.
If, like me, you want to see some of these features added then visit the SQL Source Control UserVoice site and vote!