February 14, 2024 at 12:00 am
Comments posted to this topic are about the item This is Why You Use Git for Scripts
February 14, 2024 at 1:47 pm
Hi Steve, I like the idea of using Git. Where I work, it's all databases and we use file sharing. We've experienced all of the example you gave as reasons to use Git. What's the obstacle then? I would have to learn yet another thing, and then implement in the company. We're a small company, so it wouldn't be a massive change. Any suggestions for how I can learn enough about Git to make the case for moving to it from file sharing? Thanks.
February 14, 2024 at 2:18 pm
Even better than just a Git repository, our team uses Atlassian. First, we create an internal Confluence blog post that documents how to use the script and it's implementation (similar in design to an MSDN article), and from there is a link to the script in Bitbucket. Modifications to the documentation and script are tracked using Jira workflow tickets, and I'll typically cite the Jira # in the comment whenever I modify a script as well. So, it's all integrated.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 14, 2024 at 2:52 pm
I started at my current company a little over two years ago. It was a new position, they had never had a DBA before (and one was sorely needed). One of the first things I did was to get all the databases into Source Control. I knew I was going to be slowly and methodically retiring tons of tech debt, and I wanted to always have a way to go back and look at the definition of any object before I started making my changes.
Once you get in the habit of working with a Source Control system, the small amount of extra time and organization it takes is easily worth the benefits.
February 14, 2024 at 3:46 pm
I totally agree with you, Steve. Using Git is great.
Your article answers a question I've had about how DBAs may handle their SQL Scripts. I work for my state's health department and we now have 4 DBAs which manage hundreds of SQL Servers. (Perhaps thousands, I don't really know.) I'm heading up the process of migrating our source code out of an old TFS into GitHub. I've talked with our DBAs and found that they store all their SQL scripts on a network share somewhere. (I don't have access to it.) I've felt that part of the reason why they did that is because TFS was really designed with developers in mind. I've spoken to the manager for the DBAs about getting their SQL Scripts into Git, but she has asked me to delay that indefinitely. Now I know that our DBAs practice of storing SQL scripts on a network share isn't just their habits.
However, it isn't just DBAs who do that. We employ a lot of epidemiologists. They use either SASS or RStudio, and they store all of those scripts in a network share. Two years ago, I was tasked with bringing them up to speed on using Git with Azure DevOps (which is what we were using at the time). That went OK for a while, but soon they appeared to lose interest, so the training stopped. Much of their SASS and RStudio code relies upon finding data files locally. If they were to put all their scripts into a Git repo, then they'd have to reference those data files in a remote destination, rather than referencing the file name locally. I don't see that changing anytime soon.
Kindest Regards, Rod Connect with me on LinkedIn.
February 14, 2024 at 5:36 pm
Hi Steve, I like the idea of using Git. Where I work, it's all databases and we use file sharing. We've experienced all of the example you gave as reasons to use Git. What's the obstacle then? I would have to learn yet another thing, and then implement in the company. We're a small company, so it wouldn't be a massive change. Any suggestions for how I can learn enough about Git to make the case for moving to it from file sharing? Thanks.
I have some stuff on my blog. The easy thing to do is just get a repo set up on a share and save there. Then when you're ready, learn to push/pull from there with a local repo rather than editing in place.
February 14, 2024 at 5:38 pm
I totally agree with you, Steve. Using Git is great.
Your article answers a question I've had about how DBAs may handle their SQL Scripts. I work for my state's health department and we now have 4 DBAs which manage hundreds of SQL Servers. (Perhaps thousands, I don't really know.) I'm heading up the process of migrating our source code out of an old TFS into GitHub. I've talked with our DBAs and found that they store all their SQL scripts on a network share somewhere. (I don't have access to it.) I've felt that part of the reason why they did that is because TFS was really designed with developers in mind. I've spoken to the manager for the DBAs about getting their SQL Scripts into Git, but she has asked me to delay that indefinitely. Now I know that our DBAs practice of storing SQL scripts on a network share isn't just their habits.
However, it isn't just DBAs who do that. We employ a lot of epidemiologists. They use either SASS or RStudio, and they store all of those scripts in a network share. Two years ago, I was tasked with bringing them up to speed on using Git with Azure DevOps (which is what we were using at the time). That went OK for a while, but soon they appeared to lose interest, so the training stopped. Much of their SASS and RStudio code relies upon finding data files locally. If they were to put all their scripts into a Git repo, then they'd have to reference those data files in a remote destination, rather than referencing the file name locally. I don't see that changing anytime soon.
I totally agree with you, Steve. Using Git is great.
Your article answers a question I've had about how DBAs may handle their SQL Scripts. I work for my state's health department and we now have 4 DBAs which manage hundreds of SQL Servers. (Perhaps thousands, I don't really know.) I'm heading up the process of migrating our source code out of an old TFS into GitHub. I've talked with our DBAs and found that they store all their SQL scripts on a network share somewhere. (I don't have access to it.) I've felt that part of the reason why they did that is because TFS was really designed with developers in mind. I've spoken to the manager for the DBAs about getting their SQL Scripts into Git, but she has asked me to delay that indefinitely. Now I know that our DBAs practice of storing SQL scripts on a network share isn't just their habits.
However, it isn't just DBAs who do that. We employ a lot of epidemiologists. They use either SASS or RStudio, and they store all of those scripts in a network share. Two years ago, I was tasked with bringing them up to speed on using Git with Azure DevOps (which is what we were using at the time). That went OK for a while, but soon they appeared to lose interest, so the training stopped. Much of their SASS and RStudio code relies upon finding data files locally. If they were to put all their scripts into a Git repo, then they'd have to reference those data files in a remote destination, rather than referencing the file name locally. I don't see that changing anytime soon.
git is local. That's the point. You have git on you c: drive (or /home/user) and you load/save there. Then you commit separately and push out to a central place for others.
February 15, 2024 at 1:42 pm
You might find the following links useful.
I've been using git for a long time and have only ever needed to use a handful of commands. Beyond the basics, I have only had to dig deeper a few times.
The one tip I would give anyone using Git in a shared environment is to think of your work as being the equivalent of DB transactions. Think what would you consider a sensible transaction (git commit). HINT, a small piece of working code. If you lump several changes into one commit then rolling back will rollback a lot, probably more than you would want.
Do a git pull at frequent intervals to make sure any new code is incorporated into yours. This helps prevent the dreaded merge conflicts.
Remember, git was invented to help open source teams collaborate when they are probably not in the same building and just as probably on different continents.
February 16, 2024 at 3:03 pm
There are official GitHub certifications too. https://github.blog/2024-01-08-github-certifications-are-generally-available/
If you work for a consultancy you may find you are expected to hold and keep a number of certifications.
February 16, 2024 at 3:20 pm
Thanks, I'll take a look.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply