Git for the Operations PowerShell Scripter

I’m not a developer, why should I use git? My whole shop is using git now, but I don’t get it. It makes my workflow harder. If these sound familiar I might be able to help you find answers. Come learn how to stop fighting with git turn it into the second best tool in your toolbox after PowerShell.

Software is still in the process of eating the world, but source control has already eaten devops. Source control is one of the critical technologies that enables most of the devops tools and practices that enable us to move faster. The only problem is that in far too many shops, the ops people are either struggling with the change, or they aren’t even trying because they don’t see the benefit. But operations is in the title! We should be participating in the revolution! So come see if I can convince you of the benefit and show you a little bit of how you can do it. I’ll cover some of the why, but mostly I’ll be doing practical examples and demos to show you how you can stop emailing your scripts around, stop mapping shared drives with your scripts in them, and start letting the tools help you collaborate with your teammates.

I’m going to say something unfortunate, but before I say it, I want to be clear that I don’t think this is their fault. But the fact is that I’v been sad for some time now to notice the extent to which so many of my PowerShell friends are just not very good at git. The source control skills gap could not be coming at worse time in the life of the PowerShell eco system. We want PowerShellers to contribute to open source modules, we want them to contribute to DSC modules, we want them to write and distribute modules internally for teams to use, but their hesitance to learn and really internalize the principles of source control with git is holding them back. It’s slowing the growth of open source culture in the PowerShell community.

I can’t provide real mentorship in a 45 minute session, but maybe I can give attendee’s a taste of what good source control practices look like, and what it can enable. Questions I frequently get asked that I hope to answer:

1. Why would I use this? When you tell people things like, you can use it to see the difference between versions, that doesn’t mean much. They don’t see in their minds what that looks like, and they aren’t shipping versioned software, just writing scripts. I’ll show in VSCode and the commandline what a diff looks like and why it’s useful, even if you aren’t shipping discrete versions of your scripts.

2. What is branching and what is a good branching strategy? The answer varies with the size and complexity of your shop and your devops practices, and I’d like to talk about it. Ops people start to research how to use git and they find these treatises full of finger wagging about proper branching strategy, and the truth is it doesn’t have to be that complicated to get started with version controlling your code.

3. The commandline is hard and I don’t understand the GUI’s. The commandline certainly isn’t as friendly as PowerShell, but it can be understood if you understand the background concepts, and the GUI’s mostly make sense after you understand the things the are abstracting away.