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.
Voice of the DBA 