Voice of the DBA

Tag: Git

Using Git Prune–#SQLNewBlogger
As I’ve been working with SQL Saturday and managing changes to events, I’ve accumulated a lot of branches. Even though I’m a solo developer, I decided to use branches, as I expect others to share this load in the future. This post looks at how to start cleaning those up.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers. You can see all posts on Git as well.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

Finding Old Branches

When I ran the git branch command, I saw this. There are a lot of old branches in there.

I decided that I should reduce this number. After all, even removing stale branches means I have a lot of events in flight.

We use GitHub, and when I go on the site, I see lots of branches, some of which date back to last year. Those events are done, so I decided to delete some branches. In the image below, there are three branches. To the right, there are delete icons on the bottom two as I’ve already pressed the one to delete the remote branch on the top one.

Now, how do I delete the local branch? Let’s start by removing it.

Git Prune

There is a command to remove references to remote branches that are deleted: git prune. I deleted a few older branches, and then ran git prune for remotes, with the –dry-run option. This tells me what would happen. As you can see, a number of branch references would be deleted.

Nothing in here I’m worried about or that is active. I’ve deleted these on GitHub, so I’ll re-run the command without dry run. This removes the references.

Unfortunately, the local branches still exist. We don’t remove these, as it’s possible I have work on a local branch not sent to the remote, so doing this automatically, even if I do it, is dangerous.

I’ll do another post on removing the local branches.

Automating the Removal of Remote references

I might want to remove local references for branches that get deleted on the remote. This is useful if you delete branches on merge. I don’t in this case, as I’m often using the same branch for multiple changes for an event, rather than a new branch for every one.

One way to do this is to change the config with this:
```
git config remote.origin.prune true
```
This will then run the prune on each fetch or full. This helps keep things cleaner, though local branches still exist. However, if I commit to a local branch and push, I’ll get an error that I need to configure the upstream. That helps with me being aware of what’s active or not.

SQL New Blogger

Using version control is a core skill for anyone in technology. Even database people. You could write posts on how you use or learn about git (or something else) and showcase your skills.

This post took me about 15 minutes to write, even with screen shots.
April 17, 2024
Adding Git LFS Support – #SQLNewBlogger
I got this message recently while committing some changes:

This post shows my work in adding Git LFS support to GitHub.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers. You can see all posts on Git as well.

Downloading Git LFS

The first thing to do is follow the URL from above: https://git-lfs.com/

Once there, I clicked the download link. I also saw this message: Git LFS security update: Windows users should update to 3.1.3 or newer. I had never installed this, but there is a security issue, so if you are using this, or know someone, let them know to patch.

This is a simple install, so I ran it and the installed quickly completed. There are no choices here, just accept the EULA.

Once this is done, I followed the instructions from the site. First, I had to close and re-open my CMD window to detect this. Once I did this, I could run
```
git lfs install
```
This worked fine.

Once this was done, I changed to one of my repos where I have a large PowerPoint file. I added this for a conference that didn’t have download support, but I may do this in other repos to make it easy for attendees to see code and PPT together.

In the repo, I added lfs tracking for all PPTXs. I likely will add a few other decks in here for different conferences, so I’ll includes this as a general tracking item.

This alters the .gitattributes file, so that needs to be tracked and added to the repo. I’ll do that and commit my changes.

There you go. I’m not commited and tracking large files, or at least PPTXs with lfs support. Hopefully my laptop survives as I did this on an airplane :).

What is LFS Support?

This is an extension to git that makes storing large binary files, and diffing them, more efficient. Large files can be inefficient to transfer and store compared to small files, and many file systems, and tools, sometimes adjust the way they work to manage these differently. SQL Server did this with FileStream/FileTable, which works well for some sizes of files, but it inefficient for others. In fact, if you have smaller files (< 256kb I think), those are better just stored in varbinary columns and streamed through TDS.

The extension says this should allow you to keep your repo at a more manageable size. I’m assuming this means some sort of compression and diff storage for binaries, as opposed to complete copies of the entire file(s). This should be faster to push/pull as well.

SQL New Blogger

This post was interesting to me. As soon as I realized this was something that might improve the way git works for me, I decide to shoot some screenshots as I enabled this. I downloaded the binary and sketched a few sentences on this post before I got on a plane.

I’d saved the web page for the extension, and so I took about 15 minutes to do the install, shoot the screens, and then type up the above description.

This is s a good example of adding something to my development toolbox that might benefit my team, and make it easier for others do deal with large binary files. You can do this as well to show you’re learning and growing. Even more bonus points if you go through your IT group for permission, document some of those interactions, and show that you know how to work with other teams.

Fortunately, I don’t need to do that as this isn’t a domain managed laptop 😉
February 21, 2024
This is Why You Use Git for Scripts

Git has become a fantastic tool for me, and many other technologists, over the last ten years. It’s almost ubiquitous in most of my clients, and so many people are comfortable with it. Many others aren’t, which is why I started a Git series for DBAs (and other Ops people) on my blog.

Quite a few people asked me why I recommend git over a file share for storing code that a team of Ops people or DBAs might use. Why isn’t a global file share a better choice in an organization? I think I have a few good reasons, but if you disagree, let me know in the discussion for this piece.

First, I’ve worked with a lot of file share tech over the years. Microsoft has done a good job of trying to ensure that a “file server” works well for organizations. I’ve used simple file shares on a particular server, I’ve had mapped drives to a file share appear on every desktop in the org, and I’ve even had to work with large orgs that use DFS (or something similar) to ensure we can replicate files across multiple servers for backup and speed.

All of those work, but they have a complexity, and a dependency on the team managing the file share. They also require a network connection to the share in order to see the files, which isn’t always as reliable and solid as we would like, especially in this modern world of working at home, databases in the cloud, and a widely dispersed workforce that uses BYOD devices. Don’t get me wrong, those aren’t bad things, but they complicate the idea of having a single global location for stuff.

Second, I want to version scripts because sometimes one team member alters a script for their piece of work, but it causes issues with another member’s use of the script. If we catch this quickly, we can usually CTRL+Z or revert the script, or we can copy the script to a new file and then try to edit it for a different purpose. The challenge is we don’t always catch it quickly. We also sometimes don’t know what was in the old script. While I wish most of you always logged the results of all executions, at the very least, save the script you ran. That’s not easy to do in a file share, and it’s something we don’t think about. Getting used to committing code helps us remember to do this, or at least, get the history of the files.

Third, in the case above, the last writer wins. In a busy team, I’ve seen person A save changes to the script, and then run it, while person B saves changes to the same script and runs it. Person A might get a “reload” notification and re-save theirs. Person B might also do that, or they might reload Person A’s changes and lose theirs. It’s a nightmare. Imagine group work in Google Docs, trying to edit scripts with others while you try to execute them and complete some tasks. That would be frustrating and it’s a really good reason to use Git. Let’s not step on each other’s toes.

Lastly, with a file share, I’m dependent on some other group for backup and recovery. If they have an issue, I am hoping they didn’t mess up my scripts. I have to wait on them if they are doing maintenance on the file share or patching the server.

With Git, I can keep the scripts on my machine, while easily replicating and sharing with others. We each have a backup of the script in case of emergency. We can even protect the main branch, forcing everyone to make changes on another branch and then use a pull request so that someone on our team can approve merging those changes into the main folder that we all use. If we don’t like the script, or there are breaking changes, we haven’t edited a file that others are using because it’s in a branch.

Using Git (or any VCS) is a change in habit for many people, but it has a lot of benefits. I think it’s worth the investment of time for teams.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

February 14, 2024
DBAs, Give Git a Try – Getting Started
One of the really interesting things over the last decade is both the rise of Git as the main VCS system for most projects, and the number of people who know nothing about it. Many of the latter seem intimidated, which is both interesting and strange to me. I usually think of technologies as ready to experiment, but I find more and more they only experiment in narrow boundaries.

This post outlines a quick way to get started with Git.

This is part of my series on git that is designed to help people get started using version control in their daily work. You can see all my other posts on Git as well.

Installation

Got to git.scm.org and download git for your platform. This is an easy install, and you should be able to follow the instructions. For Windows, this is a standard install. You might need to restart any CMD windows to get git in the path.

If you’re on a corporate managed laptop, make sure you verify with your IT group this is allowed. That’s a good practice to get into for any software as anything you add increases your attack surface area. It’s another thing to patch and manage. I’d also document that process for yourself (and your blog). Do so in a way that doesn’t expose corporate info, please.

Tracking Code

Once you’ve installed Git, what do you do with it? Well, the easy thing to do is start tracking and versioning SQL scripts for most of us. If you’re a DBA/sysadmin/Ops person, you likely are often writing and editing scripts for your job. Let’s track those.

First, if you use SSMS, you often end up storing lots of code in C:\Users\%user_name%\Documents\SQL Server Management Studio. Let’s change that. In your Documents folder (C:\Users\way0u\Documents\ for me), create a “Git” folder. That gives me an organized places for repos.

Now, let’s create a folder under here for storing my random scripts. Don’t worry about being perfect here, just get started. So, I’ll make an “SSMS” folder. The easy way to do this is open a CMD window and navigate to Git. Then run “mkdir ssms” here. You can see me doing this below.

You can do this from Explorer (right click, new folder), but practicing the CLI is a good skill. Plus, we will need the CLI below.

Once in this folder, run “git init” to make this a Git repository. This starts tracking files. You can see this below, as well as my copy of the files in the SQL Server Management Studio folder. That might be easier to do with the Explorer GUI, but knowing how to navigate is a skill as well. See my ..\.. as a way to move around folders.

I only have one file there because, well, most of my work is tracked in Git. I’m actually sad I have even one file here. In any case, I now have files in this folder (I made up a few more).

What I want to do is start tracking these. If I run a “git status”, I see this:

I see my three .sql files as untracked. This just means Git won’t manage these for now. I need to “add” them. I can do this with “git add <filename” for each one (learn how to use the tab key here), or I can just use “git add –all”. I usually do that since often I want to grab all changes.

Once I do that, I’ll run status, and you can see them as tracked, but not committed. For non-color blind people the filenames changed from red above to green below.

Now I can commit this and stamp a version. It’s a good idea when you think the file is changed to commit them. Not on every save, but once I think the file is changed the way I want it. For admin scripts, I usually commit once whatever I’m working on is changed appropriately, which might mean I close a ticket or a client says what I did was correct.

You can run git commit, which will open a default editor. For me, I often use the CLI and do a git commit -m “message” for the commit. The “message” is why you changed something. Here, I’ll just note this is the first commit.

When I run status, it says nothing to commit, meaning no changed files.

Now as I save scripts, I’ll run through the “git add –all”/”git commit -m message” flow each time I make changes.

One last thing to do.

Fixing SSMS

The last thing is to configure SSMS to save random scripts here. To do this, go into the options and then pick Projects and Solutions and then Locations. You can see this below with the top location set to the original folder where my script was located.

I want to change that to my repo. Browse or edit the path.

Now when I create and save random scripts, they’ll go into my repo.

That’s it.

Summary

This showed how to get started saving your random scripts into a git repo. Over time, you might want to organize things better, especially for project or app work, but for now, this will track your scripts over time.

In future posts, I’ll go over these topics to help you get better with working on these scripts.
- Using VSCode to manage your repo
- Seeing history and recovering previous versions of scripts
- Sharing scripts with others
If there are other things you don’t understand or want to learn, please leave a comment below and I’ll answer (and write a post).
January 31, 2024