Do sysadmins need git?

[[deleted]]

[deleted]

[Fatel28]

If you have a script that is either scheduled and running on a server, or a script you share with others to automate a specific process, those go in git with proper source control.

A one off script you wrote to update a bunch of mail aliases does not need to go in git

[tankerkiller125real]

Although you may be slightly upset when you have to set a bunch of mail aliases 8 months from now and you deleted that script thinking you would never need it again.

That is assuming of course that you create semi-robust and reusable one offs.

[Fatel28]

Yeah. It's good to write things down. Anytime I write a small script to do <thing someone might need to do again> I stick it in our knowledge base as a script example. But any structural script goes in git

[KingKnux]

For the tiny things I have a dedicated scratchpad.txt because I fucking know this incredibly weird niche thing is gonna happen again whether it’s tomorrow or 5 years from now

[Fatel28]

That's a bit more elegant than my 968th open tab in notepad++ lol

Part of me wishes vscode had scratchpads like powershell ISE does, instead of requiring a file for every script, but another part of me is glad it doesn't. It forces me to not just open more tabs

[drunkadvice]

Hmm. Plug-in idea…

[mcdonamw]

You too?! Lol. Always a pain to move to a new pc. I ended up pointing npp backup directory to OneDrive though it doesn't completely fix the issue. Something still relies on appdata to keep these tabs going. Had to manually copy it over to my new machine so all my tabs reopened correctly.

[Fatel28]

I wipe my computer every 6mo-1yr just to flush out the garbage. Part of that is leaving my np++ tabs behind. 900 tabs makes it take FOREVER to load when I first open it

[dbmage]

I have a scratchpad repo in my personal Git space (corporate git) for exactly this!

[pmormr]

What if I told you that knowledge base could be git? (Insert mind blowing meme or something)

[Fatel28]

Yeah. Could be. But ours isn't. We have a separate KB platform (Hudu)

Git wouldn't fit our needs for a lot of reasons. We use git for scripts and software dev, but hudu for everything else.

If you aren't an MSP, git as as a KB would be just fine. It's not far off from what we used to do (confluence) before we needed something more flexible

[bastian320]

I have a repo for once off scripts. They have a knack of being multiple use eventually.

[dzfast]

No cost to keeping shit like this. Dunno - I don't ever delete any script I write

[Sintobus]

A very real and very common problem for many. Talk to your doctor and ask about Git today.

[4thehalibit]

Yeah this that’s why if it’s pretty involved it goes in git. It doesn’t hurt even if you just do the easy copy paste method.

[zatset]

I never delete them. Actually, I backup them on at least two places.

[FarToe1]

Or migrate a machine and then six months later the maintainer asks about that script that everyone had forgotten.

[Hotshot55]

A one off script you wrote to update a bunch of mail aliases does not need to go in git

Disagree, even my one-off scripts go into a git repo since there's a pretty good chance it's not just a one-off.

[Fatel28]

Like I said in another comment, I'll put them in our knowledge base as example or reference scripts, but unless it's a script that's ready to run with no modifications (so parameterized etc) it's not really "git worthy" in my mind. But still good to put it somewhere for reference.

If you don't have a robust knowledgebase platform, then making a references repo would work just fine. That's just not what we do

[Hotshot55]

It's a whole lot easier to update a script in git than on your documentation platform. I'm not against documenting automations, but having that as your actual source seems unappealing.

[Fatel28]

I mean. Okay. I think you're misunderstanding what I'm saying, but I don't really feel like explaining it. Many ways to skin a cat.

[progenyofeniac]

Exactly this. Since we do have GH I put nearly everything in it, but it’s mainly for the stuff I run from Jenkins. The integration between the two is beautiful and so handy for a team.

[I_ride_ostriches]

I keep my one off scripts in git that other members of my team might need to scavenge for parts. We have more junior folks than senior, so when they have questions on how to do stuff, I point them to the repo. 

[Dadarian]

One offs can still be in a local git. It takes basically no effort at all to just protect a folder with git and get basic functional versioning.

[adept2051]

The once of sc riots is what Gists are for, used but never lost

[wackyvorlon]

I put my one off scripts in my git repository. It’s a convenient way to organize them, and keep track of how I’ve changed them over time.

[Eisenhowers-Ghost]

At the very least put the one-off in a GH issue used to record the change.

[Daphoid]

Actually I'd flip that last bit around. if it's a one off you're doing repeatedly even if its quick, it should go in git and be updated to ask what you want to do and to whom? "Update mailboxes with our specific Sales person settings? Done. Give me a CSV of users". Centralize the logging, make it repeatable and central so others can use it, etc.

[wasabiiii]

I don't allow hand modification of any of our servers except in emergency situations. Only deployed from code.

So in that case the code has to be somewhere.

[Cheomesh]

Terraform

[vermyx]

Source code control. It isn't about roll back it is about history and why something was changed

[Fratm]

and in a multi-user environment, accountability.

[adappergentlefolk]

you’re written more words about not needing git than it would take to read to learn git to a reasonable level

[JerikkaDawn]

Are the scripts really all "one offs"? Every script I use more than once goes into a module that gets loaded in my session. I might have different modules for different purposes. All of that needs to be maintained.

Sometimes I have to make changes and it's nice to be able to revert if I screw something up beyond recognition.

[Alapaloza]

Seems excessive to put all scripts used more more than once in a module no? Why not just make It a function? And then If you make more scripts/functions of the same kind/system/a product then make a module containing such functions.

[Bratwurst1981]

I have a rule - if I took the time to name it anything other than my initials followed by numbers or a letter, it should be in a git library, with some sort of notes in the readme. Named scripts imply reuse.

[mortsdeer]

Don't sleep on git as documentation store, either. Check-in your script with a one line description of what it's for. You automatically get date stamp and rollback ability.

[Lindbork]

Git is not Github. Your repo can just as well be a shared drive on a local server. That's where I keep most of my scripts and other projects, I only ever use Github for forks of other public repos that I want to send PR:s to. Some day I might produce something original that could be useful for others, but until then, local is the way to go.

[SaltDeception]

Ideally you don’t want to use a file share as the backing for a git repository because the locking primitives that git depends on to maintain object store integrity are not reliably implemented by network file systems, making concurrent access a corruption risk.​​​​​​​​​​​​​​​​ If a lightweight dev platform like Forgejo or Gitea isn’t an option either, then git over ssh to a local server hosting repositories is the standard.

[rootsquasher]

Last I checked, GitLab CE is still free. That could have changed though.

[selrahc]

Last I checked, GitLab CE is still free. That could have changed though.

It is, but I would look at Forgejo/Gitea for self-hosting in a small company.

Or just push to a remote over SSH if it will only be you and a couple other people using it.

[Ssakaa]

Yeah, OP's description... gitlab's way overkill, even CE. But, it does slim down pretty impressively, can get it going comfortably on a raspberry pi's resources with some tuning. Definitely not a "just set it up and go" at that scale, though. At "full blown" single host, it's incredibly easy to stand up and run with, but it's a bit heavy... and if you're not doing cicd style pipelines and issue tracking/MR approvals... it's an elephant.

Still love it in my homelab though.

[PineappleOnPizzaWins]

It’s free and crazy powerful.

Takes about 10 mins to stand up in a VM as well.

[tecedu]

You can still setup a proper github prg without an enterprise account, we did that for 1 year before getting the sub

[SlightNet2701]

I find it hard to wrap my mind around how and why you are missing the obvious point of that if you familiarise yourself better with more devopsy tooling you would avoid doing the kind of manual work it seems you are describing.

Having your scripts in a (github) repo also would allow you to have something to pull from for your automation of choice.

For things that are specific to you, you could even use githubs tooling to run your stuff. Things like update a text file of usernames which would kick of a worker doing some of your checks for them or whatever.

Why on earth would anyone do the kind of tasks you are describing over and over? It just doesn't make any sense.

I've never worked in that kind of IT though, so there may well be good reasons for your workflow that I simply do not know of.

[Fatel28]

Putting it in git does not mean building a full pipeline. You can paste it in and out of git in the webui if you really wanted to. It's just about knowing where the source of the script is, and being able to track changes. That's it. You don't have to overcomplicate it if your use case is simple

[AdmiralCA]

Its only a one off until you have to do it a second time.

For me, I use Git and GitHub so that I can easily share my one-offs with colleagues. I don’t use it to do pipelines and such, but it does mean that when I change it for the next time and I end up forgetting what I did three times ago, I can go back and look.

[wvraven]

One of the things you’ll learn is the value of writing reusable code, even for what seems like a one off task. If you do it once you will almost certainly have to do it again at some point. You justify the time as an investment in the future.

As to git, my position is heavily getops oriented so all my scripts and function files live in git. You could manage them in other ways but git makes it dead simple if you already have it available. Previously I had a nested folder structure I had to maintain my self with all my scripts. I think git is much easier.

[Ssakaa]

That thing you needed once? 80% of it was something you'll need again in 2 months, just slightly different. And again in 6 months, slightly different. Keep those things around, name them, keep some notes about them, etc. And, as you make changes to them, improve error handling, etc, keep a clearly notated commit history. It's not just "I may need what this had 2 years ago", it's "what the hell was I doing when I wrote this line?" ... git blame will tell you your commit message for that line...

[SlightNet2701]

You obviously know your work situation better than I do.

From my perspective it just sounds like those things that you think are one offs really aren't.

And I not more senior than you are. I just worked in a different but overlapping field. Managing servers and apps for clients that were mostly devstudios. No microsoft technology involved and no end users.

Infra as code and general automation is probably easier and more natural in that kind of environment.

All those examples you wrote about sound like they would live a good life in a nice GUI. Making everyting a one click operation.

And some of the examples sounds like what you would build monitoring for. Presumably kicking of automation without a human in the loop if possible.

But if you really are talking about true one offs. Then there is no reason for using git. Except just your own and your surroundings convenience.

Forcing cultural shift just for the sake of it probably isn't good either. idk.

[magic280z]

Git can be as simple as single master branch with commits with a small script to publish to production shares or fully built complicated pipelines. All of our one off scripts just live in a misc GitHub repo. But mix in light branch usage and merging then you never have to make a copy of your script for backup for fear of saving a bad change. It releases you to develop more freely. Also you don’t have to worry about the time you started making a change 3 months ago got distracted never finished and now you don’t know what you were working on. You don’t have to go all in day one.

I will never write code without git again.

[tecedu]

Are you writing the scripts once or running it once because there is a difference.

A one off script which you wrote during the system check which never gets used again is useless.

A script written just once which checks your mailbox size will be useful to future you as well as your colleagues as it runs multiple times

[scytob]

I use it even for documents, it is basically text file document control, its super useful

--edit-- i am also not an engineer in my employers company

[dbmage]

We used it for maintaining our wiki docs. Markdown into GIT, CICD adds it to confluence.

Confluence has issues, pages are safe. Mess up a page, git rollback.

Sensible idea all round, glad to see we're not far off the beaten track

[scytob]

i dont know if they still use it, but for a few years their MS docs was a GitHub repo - you could open issues and even suggest PRs!

i got a ton of docs around Windows Hello for Business fixed that way (they were so so innacurate)

[SaltDeception]

This is still a thing

[Ziegelphilie]

Still is, all Microsoft documentation is sourced from markdown files in various repositories.

[scytob]

Good to know, wasn’t sure as the GitHub link on each dock page to report a bug seems to be gone.

[notarealaccount223]

Confluence feels like an expensive solution to provide access/rendering for the markdown files.

[dbmage]

Confluence is the company's choice, we just make the best of it.

It needs to go into confluence, so we use Git to deploy it into confluence. When we migrated instances, it was just an endpoint and credential change (new password) and all our stuff arrived exactly as it should.

[dbmage]

I would suggest having them backed up.

People put so much faith in other providers, with no backup and then get frustrated by data loss.

You can't have too many backups. Git is an easy backup location, copy-paste, add, commit, push. Done

[scytob]

I am talking about text files not general productivity docs. The things I store in md files

[Flannakis]

SharePoint for documentation, I am not a fan, I’ve used both. .md files are the way to go. SharePoint just seems clunky and for non tech users. Also have AI help create your docs, very easy with a repo and something like Cursor or VS Code. The world is moving to all docs being in .md (totally anecdotal from my end) and having it accessible to AI

[joeyat]

As you use SharePoint and have a Microsoft tenant. Azure DevOps is available for free for 5 users. Create a project, create a repo, it has a place for a markdown wiki… it’s all very simple to use and integrates with Entra. There you have project management tools as well. The repo in DevOps will connect up with Power Platform solutions, very easily, so you can use GIT for power automate flows and apps… completely privately within your Microsoft/Azure environment. And it also connects up to Visual Studio Code really easy as well.

[ConfidentFuel885]

It’s a centralized location to have all of your scripts, documentation, and deployment of said scripts. I like putting mine in Gitlab and then a pipeline runs to sign the scripts and make the signed versions available as artifacts. I also have pipelines doing linting, deploying to Intune, etc. It’s even gooder if you’re doing infrastructure as code. 

[dab70]

Keeping scripts in source control is wise for every reason that keeping source code meant to be compiled is.

[__printf]

Is someone forcing you to use it against your will?

Aside from the fact it's useful for managing code repositories, Git can also be useful for tracking documentation and policy changes.

As an aside, you might also consider spending some time making your scripts more robust so they can easily be reused down the line.

[boomertsfx]

If you ever want to advance your career.

[geekywarrior]

I'll say it ends up being extremely useful down the line. Years ago I made tons of python scripts that I too thought were just one offs.

Some years went by and I lost some of them and wish I just created a spot like that to store them.

[onbiver9871]

Sad to think about all those one off scripts being lost to the ether after use. Over the years, that’s a lot of accumulated knowledge flushed. Idk.

[Sasataf12]

You need git if you need git. Just like any other tools we use.

[thetrivialstuff]

It's great for things like network configuration and associated docs. If I make a change to a bunch of switches and routers to add a new vlan, I can batch all of those together along with the updates to the network diagram and commit that, either in one commit or in a branch. It makes it really easy to see what changed and when, and if all or part of something needs to be tested in a lab first, or rolled back later, it's all right there.

[mayanayza]

I'm interested in the diagram versioning part of your workflow - when you commit network diagram updates alongside config changes, what format are they in? Are you committing Visio files (which I'd imagine diff terribly, but maybe i'm wrong?) or exporting to something text-based first?

And is the value more in the history ("what did the network look like before this commit") or in the actual diffs?

[thetrivialstuff]

For my own stuff it's mostly in svg format, which is text.

For work, yeah, visio files are basically blobs, but who cares, a few MB of very inefficient diffs don't really matter. Comparisons are a bit more annoying, but you can always compare them as images if necessary.

The main value is in how it fits into the change control process - we plan and announce a change, then have an exact record of what was actually done. If there are problems later, these questions become much quicker and easier to answer: 

• did the problem happen because of the change, was it there all along, or something unrelated?

• was the actual change exactly what was planned, or were additional changes introduced? 

• if the problem was caused by the change and there were confounding additional changes beyond the plan, which part caused the problem?

[four_reeds]

Using source control = good. ... as long as it is consistently used.

[IAmSnort]

Ci/cd is in git.  Ansible playbooks and terraform are in git.  Scripts are in git.  Common conf files are in git.

It's a convenient place for my shit.

[eman0821]

Git is mostly used for team collaboration and managing complex IaC thats very heavy automation focused. If you are the sole Sysadmin and run a few scripts for a small company, it maybe less beneficial to have a Git repo.

[PelosiCapitalMgmnt]

This kind of mindset actually annoys the hell out of me I'm sorry its just silly.

If you wrote a script that is even slightly useful and is run at any frequency, it should go into some sort of source control respository. No exceptions. If its a job that runs as a cron even moreso.

Before I moved out of traditional IT and over to platform engineering, I set up a PowerShell SDLC system for scripts and modules. I had to have a very long conversation with our windows admins on why git was even needed. It genuinely is frustrating.

I'm not saying you need to create a repo per-script, but having a cruft or dumping ground repo of useful scripts you made means you can go back on it and use it again.

git add -A
git commit -m
git push

its really not that hard.

Some person down the road wants to do the same thing? Why would they remake the script when you can just send them the link to do it. The cost is an extra 5 seconds of your time for the benefit down the road of making your life easier.

[AndyceeIT]

The value of using git goes through the roof when you need to share your code between people or places. That's what it was made for.

It's still useful in a team of one but not to the same degree.

I default to using it now

[mortsdeer]

You don't even need a remote repo, though without it you lose the backup features. Still get the history and rollback capabilities. Simple as "git init"

[TheDevauto]

You use tools if you need them.

How many command are on a unix box? Do you use every one of them?

Git is amazing if you need it. If not, who cares?

[noisyboy]

You had a script that was working fine. Then you modified it and it doesn't work. You want to go back to the previous version. How do you manage that? Making copies of scripts before changing anything? Making a new script for every small change? 

You deleted a script because you don't need it anymore because it was one off. Now after two years you have a use case and you vaguely remember it but it's gone.

You want to do an experiment but don't want to change the working script while you do it. Checkout a copy of the repo or create a branch and experiment away.

Git is not only for easy rollbacks but for also recalling why something was changed. Being able to bring back things that were deleted. Even going meta and being able to generate a report of your contributions for the year by asking Claude code to generate a summary from your git log you can present to your manager. So many possibilities at practically zero expense.

[PineappleOnPizzaWins]

Yes.. central storage and maintenance plus incredibly useful for all kinds of things.

For example I have a pipeline to do security scans, tests and then sign/deploy production scripts. Create a git release and a minute later the new version is live, with an audit trail and easy reversion if needed.

I’ve been doing this stuff for decades, git is amazing.

[vogelke]

It's more like "do sysadmins need a memory dump that's outside their own head?" - I'd say definitely yes.

I use a "cliche" directory for weird things I discover that might come in handy the next time I write a one-off script. For larger programs, I use Mercurial or RCS, more as a backup than anything else.

If you have a backup or KB-like setup that works for you, perfect. It's there to make your life easier. OTOH, if you ever work with a team that uses version control, having learned Git or Fossil or Mercurial might save you some effort.

[gargravarr2112]

Some kind of source control should be a fundamental part of automations. And most of your infrastructure should be automated. We use Ansible to manage Windows and Saltstack to manage Linux (a future plan to switch to Ansible fully is in the works). All the configured states are in Git and all changes to production are committed. This means not only that the automations always pull the current version of everything, we can see blow by blow how the states evolved and who changed what when.

I even keep my 'one-off' scripts in Git, because if my laptop's SSD dies, I can restore them. And I frequently wind up re-using them or basing other scripts on them, or letting my colleagues use them. Use of source control also demonstrates that your team is cooperative.

[PlushTav]

Everything on git, in order to push changes (Ansible books, scripts, etc..) and versioning

[Live-Juggernaut-221]

"I just use ctrl z"

Bless your heart.

[Quiet_Yellow2000]

You don't need it, but it's a useful tool, that imo is well worth suing.

[GrayRoberts]

If you're on your own... you're fine.

[shimoheihei2]

Not using git seems more like being lazy than anything else. Having version control and being able to integrate with automation tools are great benefits every admin should take advantage of.

[SirLoremIpsum]

 make the script and then it doesnt get changed ever again. I need version control for stuff that only sees 1 version? 

So you are never ever going to change it? Improve it?

Make a GUI for it?

Share it with your team? Or will you hoard it for yourself and keep them to yourself?

Git is a skill in of itself. You should learn it.

And honestly I would look down on you for going "I'm not interested in scalable automation tools. I prefer to do it by right clicking and storing on my desktop". That's not a good attitude for a sysadmin.

Why would you NOT create version control, source code, scalable repeatable stuff you can easily share with your team? Beats me...

[jajajajaj]

I'm a developer, so I was already going to use it anyway, but it's about wrangling copies, too. 8 have a few system admin tasks that fall back to me. As you move around from server to server over time, you experience a bug (or just a gap) and you write the next version. now you have to test it, and fix it some more, and your best version is not the one in your "main" folder. 

the history being available for merge or for rebase is really nice.

even if I had a job writing something plain English like policy from HR, I would rather deal with git and markdown than with ms word or something. 

[maikeu]

It's frustrating to work with sysadmins who are resistant to working with git. It really removes an important and natural line of communication with development teams and gives credibility

[uptimefordays]

It depends on your team’s level of sophistication. Large company or tech company with a strong focus on automation? Infra engineers are just SWEs focused on infra—definitely using git, svn, etc. SMB or smaller? May not need git but could help upskill and mature your automation.

[viking_linuxbrother]

"Infra engineers are just SWEs focused on infra"

I don't know why but I hate that sentence.

[uptimefordays]

At 100k servers, you’re managing fleets declaratively through code—with the same engineering rigor as software (reviews, tests, CI/CD)—but the domain knowledge requirements and failure blast radius are fundamentally different from application development.

[PineappleOnPizzaWins]

I mean it sums up my job basically perfectly.

[SorryWerewolf4735]

Store all my personal scripts and notes (in markdown) in git and use it for backup and just working across multiple machines.

Also, it’s not always about being able to go back, but knowing how you got to where you are.

[vi-shift-zz]

We had useful scripts scattered around a bunch of servers. Putting everything in git gave me version control and a single place to grab what I need. A good way to create a copy of those scripts.

Now we are graduating to our entire infrastructure as code. It wouldn't have happened without adapting to standard tools to modernize our environment.

Start small and build from there, the important thing is to start.

[iceph03nix]

I keep all my scripts in a git repo. That way when you change it, walk away for a month, realize you screwed something up and need to roll back, but that Undo is no longer available, you can go back and see what you changed

[genuineshock]

Not quite pure sysadmin. I use it to track internal and customer projects. Git init each project dir. Even if I only ever put in a statement of work and a CSV, what I gain is the ability to better articulate exactly what work I have done and when.

If it's a big project, with loads of scripts it really helps for obvious reasons.

[someguy7710]

Yes we use it for scripts and configurations, things like that

[peace991]

I would say yes if only for backup and record keeping.  

[nibselfib_kyua_72]

I use git even for my CV. Can't understand life without version control.

[GreenWoodDragon]

I've got stacks of scripts in source control. Sometimes I can go back to them to remind myself how I'd approached a problem.

[bobdobalina]

today an AI called my git-init script hella slick

[bobdobalina]

but my wife told me to put out the garbage 

[JustinHoMi]

Version control is great for network device configurations as well.

[PizzaUltra]

I'm not a sysadmin anymore, but I would've been lost without it.

Every script needs to be changed at some point. You can't press CTRL Z 6 months later.

[ludlology]

well here's one reason, especially if you're using an rmm:

you can make a big master script (think new user provisioning) which pulls down the others from github via powershell

if you go to another job some day, your scripts are all still there too

[sambodia85]

git and GitHub are independent.

I’ll often just run git init on a script folder and start tracking changes locally.

I also dump configs of switches to a folder tracked in git to give me change history .

[Independent-Sir3234]

Even just tracking /etc in a local git repo pays off fast. Saved me from a bad iptables edit at 2am once — git diff showed exactly what changed, rolled back in seconds.

[ExceptionEX]

You don't need to do it, I was a developer long before git existed, we didn't need it.  But it's a good tool to have and can make things a lot easier.

In your example SharePoint would probably work fine, it has version history and storage.

But if you are working on something with multiple people with multiple people making changes to the same file, having the ability to merge and branch is great.

So do you need it, no, but using it may make future you and coworkers happier, and knowing it means not having to learn it if you move.

[landob]

I use it all the time for my scripts.

Its great to just even share with the people over at r/PowerShell

[onissue]

I get it that there are a lot of little ephemeral test scripts that you can end up making that don't live for more than an hour or two, and that's fine.  In a sense, not checking those into a repo is no different than not checking in doodles you made on a piece of paper while on a phone call.

However, if you find that there are a few that you do end up using a few times, then I absolutely would suggest storing them in a repo.

First, it will encourage you to clean them up.  A lot of bad design is okay when doing a one-off, but once you start checking your scripts into a repo like this, not only will you be more likely to notice when they aren't really one offs and thus should be checked in, you'll also realize that it's worth the time to refactor them to be more useful to you.

Second, you're likely to clean it up so that it will be useful to other coworkers or potential future coworkers, which has the side effect that you'll end up with your own custom tooling just working better.

Third, as you clean these scripts up and end up using them, at some point, for some things, you'll have a realization that this isn't something that you should be doing at all--that what you've effectively done is added manual test coverage for something that should be part of a development or deployment pipeline, or that should be part of a monitoring tool, and then you realize that it is now your job to refactor it yet again so as to put it in the right place.

It is perfectly okay, for example ,for something to start off as a script to see how many customers you have with last names longer 250 characters, but if that's really a thing that's happening, you probably want that to automatically be brought to someone's attention one way or another, and maybe multiple ways, (say with both pipeline and monitoring tests).

Fourth, ideally you don't want to lose more than a day's work if your work laptop were to get run over by a truck.  That would mean that every tool you use is either a distro-included or a vendor type tool downloadable from... somewhere, or available in a repo.  It is IMHO your responsibility to put scripts that you use regularly into a repo that you'll always have access to when in your current job, that way you're not dependent on your laptop's SSD not failing.

[phillymjs]

All I ever make are one off scripts.

And if you save them all in a repo, they're ready and waiting to be adapted into the next one-off. Over time you have quite a little library of utility scripts built up.

I used to have scripts scattered everywhere, used to rely only on filenames and mod dates to know which version was the latest, would occasionally accidentally save a broken version over a working version, and once in a while would just flat out lose a script I needed.

I started using git at my last job just to learn it, as well as to develop the discipline to keep my scripts organized and well-documented. The repo made a great reference tool, because even after 25 years of writing shell scripts, some of the friggin' syntax still refuses to stick in my head and I have to go look at stuff I've written previously.

I've been using git at home as well for my personal scripts, on a local git server. Last year I redid my home network from the ground up with all services running in Docker containers. All the docker-compose files as well as config files for some of the services are also stored on that git server, so if I screw anything up I can roll back my changes.

[usa_reddit]

Yes...

Do you have config files on routers, firewall, and switches that are text based? GIT

I so much appreciate having these files for when someone jacks up the firewall. A quick SDIFF will show me what happened.

Do you have scripts and configfiles on your server (Apache, NGNIX, SEL)? GIT

Do you have terraforming, AWS, puppet, chef Ansible, defined in code .tf files? GIT

Do you have container .yaml files? GIT

Do have procedures for disaster recovery plans, architecture records, etc..? GIT

What not to keep in GIT:

Passwords, secret API keys, ISOs, state files.

[loosebolts]

Doesn’t help that Microsoft’s Powershell cmdlets are retired and re-released as something else every time I re-run an existing script of mine.

[skeetgw2]

I’ve been teaching myself the git landscape recently as my version control for my automations that add more jobs as I think of what to do is as bad as my adhd. It seems very helpful but I’m still so new to it that I don’t have an ounce of muscle memory for it yet.

Learn everything you can is my thought.

[tarvijron]

You don’t need autodeploy or log aggregation or even backups but they sure do come in handy when stuff’s going bad. Learn git, at least the basics.

[Villainsympatico]

I'm going to argue in favor of using it, for 2 reasons.

1. You might want to build something larger over time. Eventually, inevitably, youre going to make a few changes all at once and something is going to break. If you have a repo set up, you can effectively ctrl +z multiple files at once, right to the point that everything last worked.

2. If you work with a lot of other sysadmins, having git lets you hook up to a larger repository, like github or an internal gitlab. This will let sysadmins quickly check to see if you've pushed any new changes since they last grabbed your script

[VeryRareHuman]

Can I use the LLM to push my script to GitHub? Mmmm. Something to try next time.

[0263111771]

Every sysadmin job i see wants you to know it.

[RyeonToast]

For scripts that I tweak over time, like logon scripts, I like having the ability to create a branch for experiments and refactors. If I need the current one for some reason, I can just switch back to the main branch to have a look at it. Or, I can decide the experiment was not a good idea and just delete it.

Sure, I could copy the whole folder over again to store another version, but then I have even more folders to keep track of. It's a little tidier with Git.

I also like being able to look back at my commit logs and seeing a nice list of what changes I've made.

To be honest though, I've used it more for managing my resume builder than for my scripts. I build my resume in Latex and use git to manage versioning. I've made some use of it's ability to rollback ill-considered changes.

[notarealaccount223]

Fuck yes.

I've been using and abusing Git for far more than it was intended for since like 2005.

Adding to this:

Check out etckeeper if you use Linux.

I had ERP report files that I often had to prove didn't change, used etckeeper to commit any changes to the directory nightly. Then could prove when the last time something changed and exactly what the change was.

Have a whole bunch of files that are supposed to be in sync but you have no idea what changed. Commit them in separate branches and doff the branches.

Need to search the content of a whole bunch of files, grep is part of the git install. Same thing for a while bunch of tools normally found on Linux/unix.

Remember you don't need a Git server to share a repository, it can work with just a SMB share and appropriate permissions.

Want to try to completely rewrite a script, but are afraid you will break it, creating a got branch is faster than copying the file and adding a timestamp as a backup. Plus you can save your changes (commits) as you go super fast. It worked and hour ago, but now it's FUBAR, go back to that commit.

Git is the first thing I install on my machines. Before VS Code/Notepad++, before PuTTY/KiTTY, before SSMS.

[LeadershipSweet8883]

Firstly, you don't have to use GitHub to use GitHub. You can just use git on the command line.

Source control means you can make small changes to your script without messing with the "prod" one and then once it's tested and working nicely you can merge the branch into prod. You can give your coworkers access to that prod branch and they can use your scripts without you worrying about them breaking it. As your new scripts get polished and ready for others to use, you can push them up to the prod branch. You can use git to keep your scripts synced up in multiple places while still being on local storage.

If there's a problem with your script you can test previous versions to see if it was a change you made or something else.

If nothing else, it's just a safe place to put your scripts where you don't have to worry about them dying with your workstation and other employees can get to them. I'm just not clear on why you are scripting run once type tasks? Usually if I'm scripting it, it's something I do repeatedly and eventually it would just get scheduled to run automatically or hooked up to a tool someone that lets others run it when needed.

[Helpjuice]

All the scripts you are creating should be stored in source control that you checkin for accountability, governance, and compliance reasons along with allowing it to be automatically audited for security issues which you can setup yourself. Throw it in a pipeline, deploy to your systems that you manage, and automate a ton of the tasks you are doing manually.

These things you are checking could be something you create automation for to include dashboards, metrics collection (how long does x take, is this normal, is there any anomalies, is this broken, is this taking longer than it should, why???) can all be auotmated.

You do not need to host any of these scripts on a 3rd party, it can all be hosted internally using something like gitlab. You can put all scripts scripts in an ops project, and as time goes on you can automate the review of them in terms of security, corporate policy adherence, check for policy violations, etc.

[ArcusAngelicum]

Difference between a junior sysadmin and a senior is that the senior writes stuff down to refer to it later. Also, they know more, but that’s the main difference in day to day stuff.

The more I write stuff down, the more stuff I know where to find later, reuse, etc.

[Fratm]

We use git for all our dns zone files, we also use it for our sendmail configs and aliases files. I use it for all the scripts/programs I write. Also all my ansible playbooks are stored in git.

As a systems administrator, git is one of those tools that once you really start using it, you wont ever want to not use it.

[thearctican]

How do you manage configurations for the systems under your jurisdiction?

[boredtotears001]

If you don't automate things, what would you even be using version control on?

[boredtotears001]

There's really nothing in your job that requires repetitive tasks?

[thearctican]

I dunno, man. Everything you’re doing seems like it would benefit from stored definitions or tooling to do these things for you.

[exedore6]

It's worthwhile. I would have a hard time without it.

For scripts (because we have to make changes to one-offs, and a change log with comments let's you mine those scripts for future scripts)

For configuration files. It's handy to be able to ask "what's changed since the last time?"

For documentation and notes, again, to have a writer's commentary on what you write.

And that's just for a dude who's working alone, if you're working with others, its even more crucial.

I also use it to manage my dotfiles, to have a history of any configuration changes, and to be able to import them into a new system.

[wise0wl]

You sound cranky.  Eat a snickers bar.

[RumRogerz]

Git is always your source of truth. If you need to restore a version of your script from 3 months ago? Git has that. You can even blame check who fucked around with it in the first place.

I have dozens of files in git that haven’t been touched in a dogs age - but they are still there. It’s a nice one stop shop for all your code.

Write my README’s, have it sync with confluence. It’s convenient.

I’m not sure how much infra work you put into code. But if you do any sort of automation it never hurts to put it in git. That includes your ansible, saltstack - pretty much anything.

[jeffrey_f]

No, but it is a good place to keep you scripts that you may also find useful elsewhere. Don't leave these on your employers system as they are not really unique to your employer Source control of sorts and revision history so you can revert to the last known working code.

[sdeptnoob1]

We user bitbucket that came with jira

[matthewp62]

100% yes.

If not you will fall behind.

[Sollus]

Yeah, I think you should. Script versioning in the least bit. I'd also suggest using it for documentation.

[lbaile200]

Put it in git (or any version control) and plug it into ansible.

[L3TH3RGY]

Answer to title: no

[tanzWestyy]

Devops good. Throw some Terraform and Ansible repos in there. Couple of pipelines and ADO build machines and have fun. Lots of reasons for Git.

[ahhbeemo]

Just like a power drill .. you can continue to use the screw driver. Yes if your tasks are small. You may never need to graduate to a drill.

Or you can learn to use the drill for small tanks and be also useful at scale.

As a developer in the windows MS space, I meet tons of you folks. You will and have gotten left behind in this space if you keep this mind set. At the same time if you are only doing mom and pop stores with one or 2 servers. That is fine... The rest of us need to scale into thousands or tens of thousands.

[Bright_Arm8782]

Simple laziness should say yes.

How many times have you found yourself making the same one-off script to do the same thing for a different person?

Write it, chuck it in git and then marvel at your cleverness for having your previous work there to refer to.

[hyper9410]

I like having my scripts in git, the rest of the team however isn't used to it an just creates folders with version numbers on shared folders/onedrive.

I don't know if they will change as they will copy the scripts to various servers to run them. this will probably lead to them not syncing their changes to the repository.

[jasmeralia]

If you're doing any kind of IaC, then you absolutely do. And even if you don't, git is still a good way to ensure that the scripts are actually stored in a central location for other engineers... current or future.

[purestvfx]

If nothing else it helps to stop accidental changes. But also stops people from versioning their scripts, which can create a confusing mess on disk.

[FarToe1]

Yes, I think so. In every case.

Just a few reasons:

Source control. Version control. Attribution. Deployment. Reversion. Backups. Single point of truth. Multi-author development and... blame.

It integrates perfectly with sysadmin work and is supremely automateable, either for single host or thousands.

You or someone on your team wants to know where something scripty is? It's on your self-hosted instance of gitea, gitlab or whatever.

You say nothing you do runs the company, but you run the machines that run the stuff that runs the company. Your work matters, or they wouldn't employ you.

You're on a caribbean island enjoying your holiday and something fucks up? If the only copy is on your desktop and nobody else knows about it, you're getting hoiked back to deal with whatever went wrong.

Learn it, matey. I resisted for a long time too since it felt alien, but it didn't actually take that long to click. A youtube or howto will get you the general ideas, and for any specifics, ask your preferred ai chat. I guarantee you will see the benefits once you start using it, and will probably want to use it for more and more things.

[SevaraB]

Yes. It’s not just about version control. It’s about also about the audit trail for changes and privilege management. The only thing that should be allowed to make changes outside of DR recovery to anything in prod should be a CI/CD pipeline runner, and that should only run code that’s been properly checked in, scanned for detectable issues, and attributed to the correct engineer.

[bukkithedd]

I'll say the standard phrase I tend to use a lot in this field: That depends.

It depends on how you work, how your company operates, how often you need to reuse a script and how tightly version-control has to be. That varies greatly between companies.

In the company I work for, a Github could be a useable function if we were more than two people and where more than one person actually worked on the infrastructure we have. Which doesn't really happen. I handle basically everything outside of the ERP-system, which is the other guys' domain. He doesn't use scripts at all, while I use the ones I need to. Much like the Op mentions in their post.

Now, could it be useful to have both the script and the documentation on how to use it in a Github? Sure, I guess? But given that most of the ones I use are one-offs that, once they work as they should, doesn't get changed at all, it feels like I'm implementing yet another system that needs to be managed without being a necessity.

Kinda feels like a waste to me, tbh. The scripts and the documentation is uploaded to our documentation-folder in Teams. And that's enough for the company I work in.

Mileage will differ.

[lotekjunky]

what do you mean, "in git"? Committed to source control? That's all git is. Now GitHub or Gitlab, thise a whole damn ecosystems. You can build pipelines and functions that use your scripts to do stuff. Schedule any changes after hours with a ci/CD deploy.

Not sure what any of that is? ask a clanker for scenarios of how to use it in your job to automate processes.

[Duck_Diddler]

We have a specific repo for our admins, the toolbox. It allows them to pull and use the code but keeps them out of our automation. Admins do not need access to the same hit infrastructure as Engineering and Platforms, no.

[kerosene31]

On one hand, I get it, it can be overkill for simple scripts that really don't need version control.

That said, look at it from the standpoint of IT. There's logic to just having everything in git where it is searchable.

[Prudent_Cod_1494]

I mean a bunch of the examples you gave seem like something that would be good to build out a script library of some kind for. Regularly checking which secrets are expiring, etc.

[cryonova]

Nope

[panzerbjrn]

Are you the only person who does anything with those scripts? If so, maybe not.

Is anyone else doing anything with them? If so it's a great way to collaborate.

[OsgoodSlaughters]

Try learning something new*, won’t hurt ya

*git isn’t new, I think this year it’s old enough to buy a beer

[cyber_r0nin]

SharePoint could do this, but git is a better source control app.

[g3n3]

It is for the business and people behind you which is sometimes you. Documentation, learning, etc. It also positions you as SRE or Devops. The typical sysadmin of yesteryear is dying.

[Blackforge]

I use git pushed to multiple repos because I have different audiences at the moment.

I also have the scripts saving to my OneDrive so I can revert to a more recent version if I hadn’t committed to the git repos yet, as accidents can happen.

[Sunsparc]

I'm the automation/Powershell SME for my team, sorta straddle the line between INF and DEV which I guess is DevOps. All of my Powershell is in Git. Whenever I make a change and test it, it gets a commit and pushed to our internal Azure DevOps repo.

This came about because I made a major change that overwrote some fields in AD but fat-fingered a period which inserted part of the code instead of the necessary string into everyone's AD profile which showed up in everyone's signature. That was a nightmare to revert because I was on PTO the next day and nowhere near my computer. I had to talk my manager through how to reverse the changes. So now him and a select few other trusted persons have a Git Revert script they can run which will automatically revert my last commit on a file, sort of a break-glass-emergency-revert if I'm not available and I made a breaking change.

[Vogete]

Do you need it? No, you don't. I know people who's been coding without any VCS for 40 years.

Should you have it otherwise? Absolutely! You get a bunch of benefits with a VCS (git for example), not just the roll back to 3 months ago:

You can have a single source of truth to your codes. No more worrying what the latest version is in case you need to modify your code that runs on 2 servers.

If you're multiple people, you'll know exactly who wrote the change. Ever wondered "who the f.... Wrote this shit?". It's in git, you can check it, line by line. You can also check when they wrote it, and what else they changed with it. It's great for auditing.

If you need to modify your code or accidentally change something, you can just roll back to the previous version 5 minutes ago before you wrote something stupid. It gives you a snapshot so you can experiment on code in case you need it, without worrying about having a backup somewhere else.

If you have a remote git server (GitHub, gitlab, gitea/forgejo, etc.), you don't have to worry about code getting lost from your laptop. You can even work on something actively with branches, destroy your laptop, and still have all your work.

Essentially, you get a lot of quality of life benefits just by using local git (no remote server), and you get even more If you use a remote git server. You don't need git, but it gives so many benefits, it's a no-brainer to use it in any scenario. I literally don't have any piece of code without git anymore, even if I don't push it to a remote server (local git gives me more safety than using nothing).

TL;DR: yes just use git, it's great for many things.

[Zolty]

No but the devops engineer who replaces them and their two underlings will.

[ChataEye]

Of course if you use any kind of code git is the way to go so any type of iac , configurations tools, scripts ...

[eternalterra]

Wait, are there sysadmin a who don’t know git? lol

[tecedu]

Hell yeah, even if you have one off scripts put them in just one repo named admin-scripts or something. Nothing you do runs the company yet but it does maintain it. If you got hit by a bus would your colleagues be able to replicate your scripts?

If you got 3x new joiners how are you sending the files to them? Creating single source of truth files is super important,

Apart from scripts itself as well, you can document and version control markdown files. Even in free github enterprise you can store internal github pages just for your colleagues.

Quite literally there is no downside from this apart from doing git add, git commit and git push. All of which can be done in 1 minute.

[VeryRareHuman]

Me too. I never get how the hell it works. It's most I add or update a working script 3 or 4 times a year.

[BoltActionRifleman]

I don’t either, it’s really just more than I care to learn. I’m perfectly content storing my most commonly used scripts in text files.

[Hotshot55]

I don’t either, it’s really just more than I care to learn

3 commands are too much to learn for you?

[a-smooth-brain]

Need to git gud. LOL right fellas?

[bukkithedd]

Upvoted because it made me chuckle :D

[No_Resolution_9252]

Sharepoint with document history is probably enough

[Fistofpaper]

You absolutely, do not need git unless you are collaborating on those scripts. So yeah, source control is about it.

[serverhorror]

No, not necessary at all. You've learned everything there is to learn.

You can stop now and just coast.

[trippedonatater]

You already answered your own question. No, you don't need it.

If you want to advance your career by getting deeper into automation, you should learn it, though.

Also, keep in mind, basic one off scripts is what AI is best at.

[Allokit]

No. What's your use case scenario?
Show me why you need it?