Press "Enter" to skip to content

Category: Source Control

Working with Git in SSMS 22

Daniel Calbimonte answers a question:

In SSMS 22, there is Git integration to manage SQL code versions and repositories. How do you use this functionality?  Can you walk through a step-by-step example?

I’ll admit that I’m not too wild about using Git in SSMS. I don’t have anything against the idea, but I’ve always used separate tools like Visual Studio and VS Code for project and source control management.

Leave a Comment

Two Ways of Using Source Control

Mark Seemann notes that there are two very different approaches to source control:

Git is such a versatile tool that when discussing it, interlocutors may often talk past each other. One person’s use is so different from the way the next person uses it that every discussion is fraught with risk of misunderstandings. This happens to me a lot, because I use Git in two radically different ways, depending on context.

Should you rebase? Merge? Squash? Cherry-pick?

Often, being more explicit about a context can help address confusion.

I know of at least two ways of using Git that differ so much from each other that I think we may term them two different regimes. The rules I follow in one regime don’t all apply in the other, and vice versa.

Click through for depictions of both methods and how they differ.

Leave a Comment

A Data Model for Git

Julia Evans updates the Git documentation:

After a while working on the documentation, we noticed that Git uses the terms “object”, “reference”, or “index” in its documentation a lot, but that it didn’t have a great explanation of what those terms mean or how they relate to other core concepts like “commit” and “branch”. So we wrote a new “data model” document!

You can read the data model here for now. I assume at some point (after the next release?) it’ll also be on the Git website.

Click through for the documentation as well as some more thoughts on Git documentation in general and contributing to Git.

Leave a Comment

Source Control: A Call to Action

Steve Jones wants you (to learn about source control):

I have been surprised how many people aren’t comfortable with version control or Git. Many don’t have the habit, but are amenable to it. What I’m amazed by in 2025 is how many people don’t use it, given that so many tools we use to work with databases, and even other systems, will store items in Git. This isn’t just for development code, but also for infrastructure code. Lots of data tools and servers can store data in Git and use it to deploy changes to all kinds of systems. I’d have expected more people to know Git.

If you’re apprehensive about learning Git, check out tools like SourceTree and GitHub Desktop. You can even use the source control built into Visual Studio Code if that’s your tool of choice. These UIs make it significantly easier to work with Git.

Then, if you want to get rid of about 80% of the pain of Git, use feature branching. Here are takes on the topic from Olivier Van Steenlandt and Adron Hall, and I’m sure you can find plenty of other examples. Git can be a pain in the neck, especially when dealing with merge conflicts, but the benefit is well worth it.

Comments closed

Git Branching for Small Teams

Adron Hall takes us through a branching strategy:

Git. It’s the tool that makes some of us developers wonder why they didn’t become a carpenter. But let’s face it: Git is here to stay. And for a small team—like, say, 3-4 developers working on the same codebase—getting your branching strategy right can be the difference between smooth sailing and a storm of merge conflicts that will make you question every decision you’ve ever made in life.

So let’s dive into a “simple” strategy for keeping Git under control. No complex workflows, no corporate jargon—just a few solid, time-tested practices to keep you from drowning in source control hell. Because seriously, git is actually super easy and a thousand times better than all the garbage attempts at source control that came before.

Click through for Adron’s advice. Feature branches start making since once you have more than 2 or maybe 3 developers working in the same repo.

Comments closed

Source Control without a Budget

Kevin Hill is looking out for tightwads like us:

Every DBA has been there. Trying to keep track of database schema changes while developers have their fancy Git repositories and version control workflows. Meanwhile, database changes are often handled through a mix of manual scripts, backups, and maybe a SharePoint folder full of “final_final_v2.sql” files.

Did you know that SQL Server already has a built-in tool that can help you track your database schema changes, without spending a dime on third-party tools?

I hadn’t thought about Kevin’s solution that way, but it does make a lot of sense as a way of quickly getting files into a source control repo.

Comments closed

Git for the Power BI Developer

Paul Turley has a tutorial:

Both Azure DevOps and GitHub are supported Git hosts for Power BI and Fabric workspace integration. I will demonstrate using GitHub rather than Azure DevOps because, it is free for personal use. Getting started with GitHub is quite easy, and anyone can have a free GitHub account. Simply navigate to http://GitHub.com and sign-up for an account. You may create a personal or organizational account, and your personal account can be associated with multiple organizations.

Click through for the process.

Comments closed

Using GitHub in SSMS 21

Brent Ozar ties into a Git repo:

SQL Server Management Studio v21 added native Git support, making it easier to use source control natively inside SSMS.

This feature is for developers who are already used to working with Github to manage specific object changes as they work, and who are already accustomed to Git terminologies like branches, commits, pushes, and pulls. This feature is not for DBAs who think it’s going to automatically keep your SQL Server’s object definitions inside source control for you. I totally understand why you’d want that, for sure, and I do as well, but our princess is in another castle.

Read on to see how it works. As I went through the article, my thought was that this is almost exactly the same experience as what you get with Visual Studio. And on the whole, I’d consider that a good thing, as this isn’t some implementation of 10% of the total functionality.

Comments closed

A Mechanism for Change Management for DBAs

Terri Hurley shares one path:

Back in the day when I received an email from a developer who requested a Production Change, I would copy and paste SQL code from an email to SQL Server to run against a production database. I never bothered to save that code. But later when I was asked for a history of database changes, it was awkward to locate all the previous email requests asking for production changes. Fast forward to present day, most businesses have embraced Change Management Separation of Duties in companies of all sizes.

My preferred path to change management is:

  • All changes go into source control. You can either have the people making changes create the actual scripts to run, or generate them from base changes in source control, dealer’s choice.
  • Each changeset goes to a specific environment when it gets PR’d into the appropriate branch—that is, dev, QA, test, pre-prod, prod, post-prod, next-gen-post-dev-unprod, whatever.
  • DBAs are on pull requests, at least after a certain point. PR to dev? Let the team handle that code review. Once you move nearer to prod, at least one DBA performs a code review.
  • After PR gating happens, your CI/CD system automatically deploys the changes, assuming it passes any continuous integration tests.

This takes time to get right, but it’s very much worth the effort. I worked at a company where they built the release management processes on top of Git + Azure DevOps. You can also use tools like Flyway.

Comments closed