Do sysadmins need git?

[-]

Fatel28@reddit

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

[-]

wackyvorlon@reddit

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.

[-]

tankerkiller125real@reddit

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.

[-]

FarToe1@reddit

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

[-]

zatset@reddit

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

[-]

Sintobus@reddit

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

[-]

bastian320@reddit

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

[-]

dzfast@reddit

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

[-]

Fatel28@reddit

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

[-]

KingKnux@reddit

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

[-]

dbmage@reddit

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

[-]

Fatel28@reddit

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

[-]

pmormr@reddit

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

[-]

Fatel28@reddit

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

[-]

4thehalibit@reddit

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.

[-]

adept2051@reddit

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

[-]

Dadarian@reddit

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.

[-]

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.

[-]

progenyofeniac@reddit

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.

[-]

Hotshot55@reddit

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@reddit

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@reddit

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@reddit

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.

[-]

g3n3@reddit

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.

[-]

cyber_r0nin@reddit

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

[-]

Quiet_Yellow2000@reddit

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

[-]

OsgoodSlaughters@reddit

Try learn something new, won’t hurt ya

[-]

panzerbjrn@reddit

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.

[-]

cryonova@reddit

Nope

[-]

Prudent_Cod_1494@reddit

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.

[-]

kerosene31@reddit

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.

[-]

Live-Juggernaut-221@reddit

"I just use ctrl z"

Bless your heart.

[-]

PlushTav@reddit

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

[-]

gargravarr2112@reddit

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.

[-]

Duck_Diddler@reddit

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.

[-]

lotekjunky@reddit

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.

[-]

thetrivialstuff@reddit

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@reddit

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@reddit

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?

[-]

a-smooth-brain@reddit

Need to git gud. LOL right fellas?

[-]

bukkithedd@reddit

Upvoted because it made me chuckle :D

[-]

bukkithedd@reddit

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.

[-]

SlightNet2701@reddit

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.

[-]

iworkinITandlikeEDM@reddit (OP)

Maybe thats where my disconnect is. I've also only been in an admin role for 3 years though. y'all have been doing this for 10+ years so you think of things that I don't.

I view most of my work as one off, so why would there be a need to build automation pipelines around it if its being ran once? How do I justify time spent on automating something thats needed once?

[-]

magic280z@reddit

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.

[-]

Ssakaa@reddit

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...

[-]

wvraven@reddit

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.

[-]

SlightNet2701@reddit

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 devstudios.

Our internal environment was mostly managed

[-]

AdmiralCA@reddit

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.

[-]

Fatel28@reddit

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

[-]

SevaraB@reddit

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.

[-]

FarToe1@reddit

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'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.

[-]

thearctican@reddit

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

[-]

iworkinITandlikeEDM@reddit (OP)

We dont really have config management AFAIK. We just remote into a server or app and change what needs to be changed.

"We need to disable external chats in ms teams" okay log into ms teams admin portal and turn off external chats.

"We need to create a new connector for azure devops" okay log into azure devops, go to the project and click create new connector.

"We need to update the middleware application for servicenow to version 7.2" okay rdp into the middleware server, copy the installer from my desktop to the server and run it.

"We need to redirect our IIS app to a new landing page" okay log into the server, open iis, copy an html file to the server, change the document root to the new landing page.

We have dev test prod environments but thats about it. Change config in dev. If no noise for a week then change in prod.

[-]

boredtotears001@reddit

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

[-]

iworkinITandlikeEDM@reddit (OP)

Nothing. Thats why I cant wrap my head around needing git for myself.

[-]

boredtotears001@reddit

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

[-]

iworkinITandlikeEDM@reddit (OP)

Not really. Today I made a change to our cognos server for the first time in 9 months. which was just updating a logo.

Yesterday I worked on building OLA rules in service now and I updated tls certs in IIS.

Last week I created a DB for an external partner.

In 2025 my big projects were migrating from gsuite to exchange online, and migrating one of our business critical legacy app servers to a modern replacement.

These arent things I do every day. They're one off gigs. Our desktop admin team handles most of the day to day stuff. I just get random side projects thrown at me, and I deal with tickets that desktop team either doesn't know how to fix or tickets that got sat on too long so now end users are mad at breached sla, and I write knowledge docs for our desktop team.

[-]

thearctican@reddit

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

[-]

scytob@reddit

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

[-]

dbmage@reddit

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@reddit

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)

[-]

Ziegelphilie@reddit

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

[-]

SaltDeception@reddit

This is still a thing

[-]

notarealaccount223@reddit

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

[-]

dbmage@reddit

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.

[-]

iworkinITandlikeEDM@reddit (OP)

Can you explain this more? We use SharePoint for our documentation. Isn't that a more robust tool than github for documenting?

Should I just start storing all of my KBs in git?

[-]

scytob@reddit

I am talking about text files not general productivity docs

[-]

Flannakis@reddit

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

[-]

dbmage@reddit

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

[-]

purestvfx@reddit

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.

[-]

jasmeralia@reddit

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.

[-]

vogelke@reddit

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.

[-]

hyper9410@reddit

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.

[-]

Bright_Arm8782@reddit

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.

[-]

Allokit@reddit

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

[-]

mortsdeer@reddit

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.

[-]

iworkinITandlikeEDM@reddit (OP)

What about SMB where there isnt a large company repo? Do I just make a personal non enterprise github and upload everything to it? I feel like if someone doesnt know what they're doing or vibe coding something they could upload company secrets and not put .env in .gitignore

[-]

rootsquasher@reddit

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

[-]

PineappleOnPizzaWins@reddit

It’s free and crazy powerful.

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

[-]

selrahc@reddit

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.

[-]

Ssakaa@reddit

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.

[-]

Lindbork@reddit

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@reddit

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.

[-]

uptimefordays@reddit

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. SMB or smaller? May not need git but could help upskill and mature your automation.

[-]

viking_linuxbrother@reddit

"Infra engineers are just SWEs focused on infra"

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

[-]

PineappleOnPizzaWins@reddit

I mean it sums up my job basically perfectly.

[-]

uptimefordays@reddit

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@reddit

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 late the new version is live.

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

[-]

No_Resolution_9252@reddit

Sharepoint with document history is probably enough

[-]

ahhbeemo@reddit

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.

[-]

noisyboy@reddit

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.

[-]

tanzWestyy@reddit

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.

[-]

L3TH3RGY@reddit

Answer to title: no

[-]

lbaile200@reddit

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

[-]

SirLoremIpsum@reddit

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...

[-]

iworkinITandlikeEDM@reddit (OP)

are you never going to change it?

Not really, no. If I make a script whos sole purpose is to change the timezone on an exchange mailbox, then thats the purpose of the script. I made it exactly how I want it to be on the first iteration. If I ever need something else then I'll make a new script not revise the existing one.

My team is siloed. I own exchange stuff, sharepoint stuff, purview stuff, service now stuff. Co worker owns vdi stuff and other internal apps. Our network team is separate. No one listed benefits from my scripts, and I dont benefit from their scripts. Ill never be working on their silos unless I transition to that team.

[-]

Sollus@reddit

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

[-]

matthewp62@reddit

100% yes.

If not you will fall behind.

[-]

sdeptnoob1@reddit

We user bitbucket that came with jira

[-]

jeffrey_f@reddit

No, but it is a good place to keep you scripts that you may also find useful elsewhere. Source control of sorts and revision history so you can revert to the last known working code.

[-]

RumRogerz@reddit

Git is always your source of truth. I’m 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 plate.

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.

[-]

TheDevauto@reddit

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?

[-]

wise0wl@reddit

You sound cranky. Eat a snickers bar.

[-]

exedore6@reddit

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.

[-]

vermyx@reddit

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

[-]

Fratm@reddit

and in a multi-user environment, accountability.

[-]

Fratm@reddit

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.

[-]

ArcusAngelicum@reddit

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.

[-]

Helpjuice@reddit

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.

[-]

LeadershipSweet8883@reddit

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.

[-]

notarealaccount223@reddit

Fuck yes.

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

[-]

RyeonToast@reddit

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.

[-]

0263111771@reddit

Every sysadmin job i see wants you to know it.

[-]

VeryRareHuman@reddit

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

[-]

trippedonatater@reddit

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.

[-]

maikeu@reddit

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

[-]

Villainsympatico@reddit

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

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.
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

[-]

tarvijron@reddit

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.

[-]

mortsdeer@reddit

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"

[-]

skeetgw2@reddit

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.

[-]

loosebolts@reddit

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.

[-]

usa_reddit@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.

[-]

phillymjs@reddit

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.

[-]

boomertsfx@reddit

If you ever want to advance your career.

[-]

AndyceeIT@reddit

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

[-]

onissue@reddit

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.

[-]

landob@reddit

I use it all the time for my scripts.

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

[-]

ExceptionEX@reddit

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.

[-]

Independent-Sir3234@reddit

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.

[-]

Independent-Sir3234@reddit

Git saved me once when I fat-fingered a firewall rule on a Friday night. Rolled back in 30 seconds instead of rebuilding from memory. Even just version-controlling /etc is worth it.

[-]

Independent-Sir3234@reddit

Git saved me once when I fat-fingered a firewall rule on a Friday night. Rolled back in 30 seconds instead of rebuilding from memory. Even just version-controlling /etc is worth it.

[-]

PelosiCapitalMgmnt@reddit

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.

[-]

eman0821@reddit

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

[-]

JerikkaDawn@reddit

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.

[-]

Bratwurst1981@reddit

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.

[-]

Alapaloza@reddit

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

[-]

sambodia85@reddit

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 .

[-]

VeryRareHuman@reddit

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@reddit

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.

[-]

ludlology@reddit

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

[-]

shimoheihei2@reddit

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.

[-]

PizzaUltra@reddit

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.

[-]

bobdobalina@reddit

today an AI called my git- init script hella slick

[-]

bobdobalina@reddit

but my wife told me to put out the garbage

[-]

JustinHoMi@reddit

Version control is great for network device configurations as well.

[-]

GreenWoodDragon@reddit

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.

[-]

jajajajaj@reddit

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.

[-]

serverhorror@reddit

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

You can stop now and just coast.

[-]

dab70@reddit

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

[-]

hanzzen@reddit

To me its wild that some people dont put their scripts and automation in git of some sort. Being able to trace changes made to a an environment is very valuable. We had a sysadmin at our company store the automation of all the center environments in a single ps1 script on a random server. As soon as he left, it was all moved to git. The whole department has gotten better since then.

[-]

nibselfib_kyua_72@reddit

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

[-]

__printf@reddit

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.

[-]

iworkinITandlikeEDM@reddit (OP)

I've heard it thrown around a few times at my current job and previous job. "It doesnt exist unless its committed in git."

[-]

peace991@reddit

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

[-]

someguy7710@reddit

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

[-]

IAmSnort@reddit

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.

[-]

genuineshock@reddit

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.

[-]

four_reeds@reddit

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

[-]

adappergentlefolk@reddit

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

[-]

iceph03nix@reddit

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

[-]

vi-shift-zz@reddit

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.

[-]

SorryWerewolf4735@reddit

Store all my scripts and docs in git and use it for backup and just working across multiple machines.

[-]

Sasataf12@reddit

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

[-]

onbiver9871@reddit

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.

[-]

geekywarrior@reddit

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.

[-]

wasabiiii@reddit

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.

[-]

ConfidentFuel885@reddit

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.

[-]

GrayRoberts@reddit

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

[-]

Fistofpaper@reddit

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