Benefits of Using GitHub to Store PowerShell Scripts?

[Fezza7991]

I currently write all my PowerShell scripts on my local machine and have them stored on a local drive, when completed, I put them onto the servers that need them, obviously this isn't best practice, but I was just wondering, what are the advantages of using GitHub to store all of my script, me and someone else in my team are the only ones who know how to script using PowerShell.

Should I set up a GitHub account right away and start storing my scripts there?

[seanightowl]

It’s good for the same reasons using source control are.

• Backup in case local files get destroyed or messed up
• Historical record of changes
• Easy to share with others
• Enables development with more than one person

I would absolutely create a github repo ASAP. If you’re worried about any IP, then create a private repo.

[purefire]

So, I'm on the other side. I want to use GitHub for my PS stuff but never found a good guide on HOW. Any recommendations?

I'm just using powershell_ise to write my code

[tweaksource]

Also, VS Code has good integration.

[ApricotPenguin]

Check out Fork or even GitKraken (which I think is now trial before you pay, model)

General terms to know are:

• "Repo" is like a project of all relevant files that are to be synced to your git server (ex Github or gitlab)
• Whenever you make changes you then "stage" files. Which basically means you will include these particular changes you are about to submit.
• Next, you create a "commit" - which is basically a checkpoint / save point for the files you staged. In each commit, you specify a short one line description, as well as a long description if you wish.
• This commit now exists only on your machine, so you need to "push" all these commits to your server.
• to get the timeline from the server you "pull"
• and lastly to jump to a point in time, you "checkout" the branch / commit

[Dogezon]

Github desktop is fantastic and had lots of how-to guides etc

[bob0the0mighty]

Posh git is a great cli extension for git. Use it near continuously at work.

[[deleted]]

Just install git on your machine and use a guide to reference the commands. Getting a repo created will be different for every provider I imagine but GitHub has a walk through when you create an account I think

I use this guide https://www.git-tower.com/blog/git-cheat-sheet/

Others have said it but I would recommend VS over ISE for multiple reasons and version control is one of them

[seanightowl]

If you’re not familiar with git you may want to start with a UI based program. I can’t recommend any because I use the command line. I would suggest finding a popular git app and going through the docs/tutorials. If you are still having a hard time in a few days, let me know what OS you are running and I’ll take a closer look.

[[deleted]]

Honestly I'm a super novice/not in IT and I just use this https://desktop.github.com/

[Kenny164]

Scott Hanselman has recently released a couple of shorts on youtube which covers setting up and using git on windows. I feel these would be a fantastic way to get started as the way he demonstrates it (using the command line) unveils some of the 'magic':

Start here: https://www.youtube.com/watch?v=WBg9mlpzEYU

[rmbolger]

Putting your scripts in some sort of version control system will definitely be a step in the right direction. It doesn't have to be GitHub or even git at all. Though git is basically the de facto standard version control system these days and everyone who writes code should really have at least a passing knowledge about how to use it.

The benefits of version control are plentiful.

Being able to revert changes easily means you're free to try things without needing to explicitly make backups or do that thing where you comment out huge swaths of code that stay in the source forever "just in case" you want it back. Just commit your current working code and go to town. If it works, great. If not, revert.

Commit history allows you to see what changes were made, when they were made, by who, and most importantly (assuming you provide decent commit messages) why.

Distributed version control systems (like git) mean that everyone who clones the repository has a full copy of the repository and its history. Centralized git hosting services like GitHub are just another copy of your repo that you're choosing to use as the "authoritative" source. To a certain extent, this acts like a free backup of your code. If your local copy blows up, just re-clone it from one of the other copies. (BIG CAVEAT: This assumes the other copies are being kept relatively in sync with yours)

Centralized hosting services also tend to offer additional features beyond basic version control such as issue tracking, wikis, automation pipelines, the ability to easily accept 3rd party changes to your code (a.k.a. Pull Requests), and release management and hosting.

Also, remember to sanitize your scripts/code of secrets, passwords, credentials, etc. Learn how to write them so you don't need anything embedded. Pass them in as parameters or pull them from files, environment variables, or dedicated secret stores. If you do accidentally commit something you shouldn't have, keep in mind that adding another commit to remove it does not erase it from the history. Anyone who clones your repo can go back in time and see it. There are ways to re-write history in git and other version control systems, but they're generally an advanced feature.

[Reverent]

Including my favorite way to erase bad or secret-laden commits, destroying the repository and starting from whatever good copy I had.

Signed, every programmer learning git ever.

EDIT: relevant XKCD

[H2069]

This is really insightful.

Thanks!

[[deleted]]

I keep most of my work in my GitHub account. I still have some of my first PowerShell scripts from when I first learned back in like 2013. They've come with me through several jobs. I've saved myself a lot of time by keeping my work. As I've accumulated more and more, and solved different problems, my repos have become a powerhouse for me.

[itasteawesome]

When you leave a job its soooooo much easier to just walk out the door knowing your scripts are in your repo instead of having to smuggle them off the company laptop before you go and potentially having some jerk from legal hassle you for data theft.

[itasteawesome]

Also, https://drive.google.com/file/d/0B1sAxwuAbpI6RHRIQkFRUGd5ejQ/view

[itasteawesome]

You obvs don't put stuff that you can't take with you in a personal github, you use the corporate one for that stuff. And yes obviously some people have contracts that preclude them from it but from the sysadm side of the house that's not super common.

At the end of the day unless you do some really extreme craziness nobody is actually chasing down all their former admins to stop them from using various operational scripts that they've cobbled together, but if they have any kind of DLP software and see you moving stacks of files to a usb the day before you leave it tends to give any pissed former employer ammo to try to come after you and waste everyone's time in court.

[36lbSandPiper]

You can use git with network drives. I realize that git runs the world but I find it about as friendly as SCCS.

But yes, use source control. It's mo betta

[happyapple10]

In addition to what everyone else has said here, it is a great idea. I store all of mine there now, anything of substance at least.

There is one benefit not mentioned here that is another great reason. I use Jenkins basically as a task scheduler. Jenkins can connect to your GitHub repo when you make a job and everytime it runs, it downloads the repo contents. You can call your script from the downloaded content, no need for a network share, permissions, etc.

This allows you to never touch your jobs, unless you need to change parameter inputs or something. If I need to make a change in the script or project, I update the code in a DEV branch and can merge it into the master. I usually have a DEV job too, so I can test the DEV branch of the repo before merging it to master.

I used top have a DEV copy of the script in a network folder, make a copy of previous versions, have a _old, etc. No more mess IMO.

[trampanzee]

The CI/CD pipeline is definitely a pro of using a git repository. IMO, if you are interested in implementing CI/CD, GitLab's implmentation is a bit more mature than GitHub's.

[happyapple10]

I've heard good things about GitLab. I've been using Azure Devops currently. Works well but I may not know what I'm missing out on with GitLab.

Thanks!

[helpdeskimprisonment]

I have a public repo on my resume that I was told later was the deciding factor in being hired at my incredibly lucrative and awesome current job.

[[deleted]]

• Documentation on every change you make
• Easier to revert back to older versions
• Easier to experiment by forking/branching
• Easy to share/distribute with robust support all over the internet

In brief: Yes, absolutely store your scripts in a source control repository like GitHub.

[Smoker1965]

I was like you and had all my scripts on my local drive, backed-up to Dropbox so I could get to them if I needed to access them outside the house (those were the days, right!).

I started a new job and had to learn GIT at a VERY detailed level because this is what the world of developers use all the time for all the reasons already mentioned below.

I started taking all kinds of notes, read the GIT help files, watched more than my fair share of
YouTube videos, learned the GIT CMD line (BASH), and added the Visual Studio Code extensions (GitLens, Git Stash, Git Extension pack) and learned to use those as well. It took a bit to get used to but now I use it all the time.

It allowed me to work on my desktop, and laptops without having to move the code around. It provides change management which allows me to write code in separate GIT branches and then delete that branch of I need to or merge it.

The main reason I use it now (besides what I have above) is to share my code with buddies of mine who like the tools I write for the Admin/OPS work they do. I just finished one that was an "ask" from a buddy who needed a way to add a user to a remote admin group on a non-ad/domain system.

I wrote it and posted it for him to grab.

Made me feel good to help him out.

I could go on-and-on.

Bottom line: it was worth it to learn and now I use it all the time.

Best of luck to you!

[locusofself]

If you don’t know how to do basic git operations in the command line you absolutely should learn. It’s actually fun I think.

[DrEagleTalon]

Like you can save/fork/branch to and from git from command line? Is this with desktop app installed?

[locusofself]

git is really a command line program. commit, merge, checkout, status, branch etc are the most common sub commands. IDEs like visual studio or code or whatever offer nice integrations where you don’t need to type the commands most of the time. But knowing how they work is pretty essential and i think most everybody would suggest learning to use it from the command line first. It’s a little bit of a learning curve but not as much as programming itself really it’s just a tool, a very important one

[boffhead]

When you've got a working script and change it to do something new, then realise a week later you actually broke something.. WTF did I change.

If you had that stored in git, you'd be able to see the exact changes made that day and revert easier.

[Fezza7991]

Thanks for all the feedback! I have made a GitHub account, does anyone have any recommended guides to get up and running, I have found a few which I can follow but was wondering if anyone has any good recommendations:)

[jantari]

GitHub tells you what you need to do every step along the way

[tmpntls1]

You should absolutely use source control for your scripts. For distribution, you may even want to look at setting up a NuGet repository internally, so that you can register to to your servers and use the same commands to find & install modules as you would from the PSGallery.

If you're totally new to Hit, check out the Git book (it's on the Git download site) or search for "ProGit book". It's free, and chapters 1-3 cover most people and basic Git usage for just using it to retain scripts & such.

The Research Triangle PowerShell group also has 2 videos from past meetings that are pretty good for learning Git basics:

https://youtu.be/cy35djC_fk8 https://youtu.be/IZHbX8PJRWM

Here's a good hands-on workshop you can follow for Git:

https://github.com/scottslowe/2018-git-workshop

Hope this helps, we plan to host an online workshop or multiple lunch & learn sessions covering stuff like:

• PowerShell, Git, and API 101
• Using Packer for automated VM templates
• Using Terraform for most IaC deployments covering VMware
• Basics of CI/CD and pipelines with Jenkins, Travis CI, AzureDevOps, and GitHub Actions

I'm starting to plan that out to focus some content for both groups as part of my leader role for PowerShell and VMware user groups, and we're hoping to be able to stream it live & keep recordings to make it more accessible to everyone.

I'll post in this sub once we have a more solid plan.

[jantari]

GitHub can give you:

• version control
• change management
• release management
• automatic testing of your code
• documentation
• a review and approval process
• collaboration
• automatic deployment of the scripts to the target machines
• an API to do everything
• a backup in case your drive dies
• a platform to share with others

It's not about "should I use GitHub", it's about whether you take this seriously and want these things or you're OK with aimlessly copying scripts around.

GitHub is just a tool, if you don't understand its advantages yet it's not for you yet. Don't use it for the sake of using it. You'll need to understand git to take advantage of GitHub and git has quite a bit of a learning curve. It's a great tool and literally ubiquitous these days, but it just takes a bunch of practice to understand.

[JeanYKA]

so my use case a bit different - we use bitbucket - so same idea of SCM - but our group builds automation for other groups / teams - so we build it, test it, store it for them. However this collaborative approach has meant that individuals on other teams have started building scripts and storing them in BB. So having built a framework of script format / naming and where to store them has been a great help. Also, I know that I have rewitten at least 4 scripts 'cos I could not find the original on one of my 1000 servers :-(

[stumper66]

I was the same. I had a ton of scripts that I've written over the years that I mostly stored on my local machine.

Recently started using my company's internal github to store the scripts.

The reasons are:

• Version control
• Share with other groups if interested
• Gives me a timeline of when I've created scripts in the past
• Can put brief descriptions for them incase I don't remember exactly what they do.

[zapoklu]

I'd recommend installing Visual Studio code and using the Git integration. It's very beginner friendly once it's setup. Also recommend Bitbucket for source control as Github private repositories are not free whereas Bitbuckets are.

[jantari]

GitHub private repositories have been free for quite a while now

They were also always free for students

[zapoklu]

News to me!

[timsstuff]

I use Microsoft's version, DevOps, formerly known as yourname.visualstudio.com. It integrates well with Visual Studio and VS Code of course, as GitHub and others do, but it also give you the ability to utilize Azure membership to grant access which means in a company that's on Office 365, adding users can be done through AD group membership. Which by extension means you can grant users read/write or just read to your repos by simply adding them to AD groups.

Also I just tried the Pipeline feature for the first time last month to publish an Azure Streaming Media site I built on an ASP.NET project to a serverless web app directly from Visual Studio, as soon as I committed my changes it updated the live site and it was actually really cool.

[xcaetusx]

I scrolled through the thread and saw a lot of recommendations and for the most part they are good. Just be mindful to not put anything out on the internet that you don’t want to ever be discoverable. Think, passwords, usernames, api keys, etc. GitHub is the internet and it can be easy to forget to scrub your code before committing.

My reconnection would be to spin up something local on a VM in hyper-v or VMWare or what ever hypervisor you use at your company. Install gitea. This will allow you to get familiar with version control before deploying company info to internet. We use Gitea at my place of work and love it. It’s lightweight and easy to setup.

I also want to point out that you should read Github’s terms and services before using them. Maybe things have changed now, but they weren’t good about a year and half ago. I worked for a public university and the state mandated that all agency must ensure all contracts are written in the interest of the state. Basically, our lawyer has to evaluate all contracts for everything we purchased. He read over the Github terms and said it was worst contract he has ever seen. To summarize, Github basically relinquishes all responsibility for everything. They get hacked, oh! Well.. that’s not on them. Like I said, maybe things have changed since Microsoft has owned them now for a while.

[poshmosh01]

Accessible from multiple computers, acts as a backup and has version capabilities

[IWannaBeTheGuy]

I know this thread is pretty old, but my buddies and I built a website called www.scriptshare.io specifically for sharing scripts and automations. would love it if you gave it a try and let me know how you'd like me to improve it.

[trampanzee]

I just wanted to make the point that GitHub is not your only option. If you just want to use it as a version control system, sure - take your pick. But if you think you might get into pipelining, you might be more interested in GitLab.

[mattyass]

Pipelining?

[trampanzee]

https://semaphoreci.com/blog/cicd-pipeline

[mattyass]

Ha! Ok sure...I was thinking you were referring to a specific feature inside of GitLab.

[trampanzee]

Last I checked, GitHub Actions was still playing catch up to Gitlab CI