Lots of DBAs have had a folder with scripts on their machines. This might be on a share, or it might be on each individual machine. How do I start getting our scripts organized? Let’s look at a short process to make this easy.

The steps to do this are:

• Get a consolidated version of scripts in one place.
• Convert this to a repository
• Push this to a central location
• Protect the main branch
• Have individuals clone this repository

In my case, I have a folder with scripts. There is also a subfolder in here with a few more scripts. You can see this below.

This article assumes that you have Git installed on each team member's machine. If you need help doing that, read my blog post on getting started.

Consolidating Scripts

The first thing to do is copy all the scripts to one place. If you have a share with scripts, this is easy. If these are on each person's machines, I'd start copying all the scripts into one folder, deciding how you handle conflicts. You might decide to keep the latest version of each script based on time, but I'd recommend that if you have name conflicts with different dates, rename one of those scripts to "scriptname2.sql". I know this seems counterintuitive as we want to ensure we have versions, not copies. However, to get started, don't lose any code. Maybe these are two different scripts

• one is "blockingchain.sql" for generic checks
• another is "blockingchain-killhead.sql" for handling things.

Once you have all the code in one folder, you can move forward.

In this article, I had all my scripts in a folder below the SQL Server Management Studio folder in my Documents folder. My path for this is: E:\Documents\SQL Server Management Studio\dbascripts

Convert Into a Repository

To convert a folder into a Git repository, you have a few choices. If I right-click in Windows Explorer, notice that I have a few Git options. I can open Git Bash or a Git Gui.

I almost always prefer the CLI, but some like the GUI. I've opened both from my folder so you can see what these look like.

I'll show you both ways of converting this folder into something we can track.

Only follow one of the next two sections to convert this, not both.

Git GUI

The Git Gui is shown in the left side of the image above. Since this is just a folder, I can click "Create New Repository" to convert this. When I do, I get the screen below, but with nothing in the edit box.

I clicked "Browse" to pick this folder. In the Browse screen, I selected the folder from the top bar, as shown below.

When I click Create, the folder becomes a repo and I get a new GUI view with my files.

Using Git Bash

I can accomplish the same thing as above at the CLI (command line interface) in Git Bash. Type "git init" and hit enter. You'll see these results.

In both cases, my folder now has a hidden .git folder, which makes this as a repository.

If I want to check status, I can run "git status" at the CLI.

If I haven't converted the folder, I'll get a different message. In this case, I'll change to the parent folder and you can see in the image below that this folder is not a repository.

Publish the Repo

We will copy this repository to GitHub, but before we do this, we need to save our files. They're saved in the file system, but not in Git. To save them, I'll use the Git Gui.

In the Git Gui, select the "Commit" menu and then choose "Stage Files to Commit" or hit CTRL+I.

When you do this, you'll get asked if you want to stage all the files. Staging means that Git will track changes to these files. When you add new files, you'll repeat this to track them. Click Yes

When this is done, you will see all your files in the green "staged" area. In the bottom right, enter a commit message. This allows anyone looking at this repo to know why this was changed. I usually enter "initial commit" the first time I do this in a new repo.

Click Commit to save these changes as the first version of these files.

At this point, nothing looks different. The folder looks normal (other than the hidden file) and the Gui shows nothing. That's good. We've got a version of these files saved.

Now, let's publish our repo elsewhere.

We need to create a repo. I'm using GitHub, but any other Git service works. I won't walk through this, but I have a blog post on creating an empty repo. Once I do that, the easiest thing to do is take the code on the screen from GitHub (or other service) and run it in your Git Bash CLi. For me, I added a new repo, called DBAScript. This gives me code that looks like the following for the "push existing repository". Note, I copied these one by one and ran them in Git Bash, which was open to my folder. I had to right click and "Paste" each line.

My results look like this:

My repository looks like this in GitHub now.

That's it to get my code into a repo. Now, let's see what else we need to do.

Protect the Main Branch

Each branch is a copy of code. For the most part, your team will just work with the code on the main branch, which is the code that's approved and should be the latest version. You can see your branch with the "Git branch" command, or in any of the client tools.

However, when we want to update scripts, what we really want to do is make changes in another branch, copy, and then let another team member approve those changes. The scope of that is beyond this article, but for now, we just want to prevent anyone from pushing code to our main branch/copy.

We do this as many new people using Git will just commit and push things in their current copy. We want to prevent that and ensure if someone is changing a script, they change this in a copy and someone approves the copy updating the script every one uses in the main branch.

To do this, go to the Settings tab in GitHub. The click the Branches item on the left. You should see a way to add branch protection.

Give this a name. I choose something easy.

Choose branches. I am using the default branch as that defaults to main in this repo.

I set the rule to block pushes from users and require a PR. I choose to require just one approver, as we have to trust people in the team. If someone does something silly, we have copies of the code and can restore them. This is really to get in the habit of not changing things without telling other people.

We're set up, now let's inform the team of DBAs.

Clone the Code for each DBA

The first thing we want to do is make sure every DBA deletes their own copies of the scripts. If they are using a share, stop doing that. Instead, we'll have them work from their local copy of the code from GitHub (or your Git server). The second thing is get git installed on each machine.

Now, let's assume that you want every DBA to work under the SQL Server Management Studio folder on their machine. It could be different for everyone, but consistency helps build a team. If you are a SQL Server team, you likely have this folder under My Documents. If you don't use SQL Server, or want a different place, I'd make a folder under which I want to store code.

Now, have each team member open a Command Prompt in the parent folder. So, if you are under the SSMS folder, your command prompt looks like this:

Have each DBA run "git clone" and add the URL of the repo git file. For GitHub, you can get this by clicking the green Code button under the code tab. For other services, it will be somewhere similar. I'm copying the path above the "Clone using the web URL" in the right side of this image below.

This copies the code down to each person's machine. They can now open and use these scripts as they normally do. They can even make changes, however, they can't get those changes to the team without learning a bit more about branches, commits, and PRs. That's for another article.

For now, you're versioning scripts and building skills.

Summary

This article covered the basics of how to convert an existing folder of scripts to a Git repository and save those scripts in GitHub. The process is similar for any Git service, where we create a repository where our scripts exist, create an empty repository in our service, and then push up our code. We also showed how to protect the main branch and allow other users to copy our code.

A future article will look at how we make changes to scripts and ask another DBA to review them.