I’ve worked with source control quite a bit over the years — everything from ye olde Visual Source Safe to Subversion to TFS. I even supported the Source Depot system at Microsoft as an engineer for a year back in the day!
These days I don’t use source control a ton. We keep repositories of scripts in GitHub to help manage our scripts as a team, but I don’t really use it often enough to learn the command line well.
Even so, I’ve learned the basics of branching and merging. Git can be really confusing because there’s a ton of features, but here’s an outline of how you can work with a team in an uber-simple branching scenario safely.
When I Say 101, I Mean 101
We’re talking GUI screenshots and simple concepts, here. I’m not talking about how to do source control for schema and diffs, I’m just talking about how to save all those scripts you wrote about checking for that weird thing that happens in production every third Tuesday.
1. Create a Branch
Branches are great, because they keep you safe. They give you a sandbox to work on your code where you don’t disrupt the main line of code. You can work in iterations and make multiple commits to your code, so you can do / undo incremental changes.
2. Check in Your Code (Commit to your branch)
You can make changes to multiple files. For this example, I made changes to just one file. Make sure that you’re committing to the new branch you created!
3. Create a Pull Request (to merge into another Branch)
Once all your commits are done and you’ve tested your code and you’re ready to roll, create a pull request. You’re essentially proposing your change for someone else to review and merge to a destination branch of your choice.
The big advantage to pull requests is that it makes it simple for your reviewer to see exactly the changes you’ve made and know clearly what will be impacted by merging.
Your pull request will automatically send out an email and notify other users of your repo that you’re ready for things to happen, and it’s time to review.
4. Reviewing the Pull Request (Someone else does this!)
Now it’s time for someone else to be responsible. The good news is, your pull request makes it easier for them to review your code. Here’s what it looks like in the GitHub web application:
To get into the details, it’s super easy to click on the “Commits” tab and see all the changes. The reviewer can easy open all the files, leave comments, and even edit changes if they really wanna get up in your business. Or they can push it back to you.
5. When the Reviewer is Happy, they Confirm the Merge
This pushed the change down to the branch you targeted, nice and easy.
6. Delete the Branch
Right after merging this, it’s very easy to delete the branch and cleanup. You can also leave the branch there if you want, and there’ll be a history of what happened with the pull request. No more wondering, “what happened with this branch?”
It’s so easy, even a manager can do it
You don’t have to be sloppy and save all your scripts in a file share!
Jeremiah says: pull requests make collaborative development easier – you can bundle up related changes, comment on why you did what you did, and collaborate with your team to get the best fix in place.
Doug says: This also answers a question we get frequently: “What can I use for source control for SQL Server?” It’s not integrated with SQL Server, but it’s free and not too shabby.
Is it possible to integrate SSMS with Git ? Maybe a 3rd party add-on ?
Red Gate has a tool named Source Control that I use and it works well for us. We’re not a shop that does a lot of development but I don’t see any reason that it wouldn’t work in an environment like that.
Great post! And super easy to follow.
Quick note: there are two “Step 4″s in this article.
I keep all my SQL changes in a SSDT project in Visual Studio which I then can easily commit to git. I can then see exactly what has been changed in git and I can easily deploy to production via Visual Studio. Visual Studio also has its own built-in tools for github, not quite part of SSMS but pretty close.
Cloud TFS is also a good option to store SQL scripts. It
s free for up to 5 users.s a good practice to wrap all your upgrade scripts into a transaction and mark each with version which ideally correlates with application build.
Storing an SSDT project in cloud TFS is also good. But this approach is usually feasible for not large databases.
Kendra, would be cool if you or maybe Doug the SSIS master do a post like this for SSIS packages and a good way to manage those with GIT. We are trying, but struggle as they are not scripts and doesn’t work great there are a lot of gotchas. Curious if you all have run into this.
We don’t do a lot of SSIS development here– if you’ve found a lot of gotchas, it would be awesome if you’d blog that for people! I bet it would come in handy for others.
Hey Keith, Are you still continuing GIT for SSIS packages? Could you please let me know if it works ? And how?