Create Repositories Based on a Purpose

Although there are many different strategies for creating repositories (repos), one of the best strategies is to create a repo per project. Perhaps you have a set of PowerShell scripts to manage things in Active Directory (AD) and a script or two that helps you build virtual machines (VMs). Rather than creating one big repo called Scripts and throwing them both in there, break that out into two repos called ADManager and VMManager, for instance. Assign a label to the effort. Put a name on that effort.

Associating a repo with a specific purpose not only helps you keep scripts separated for manageability purposes but also encourages tool-building. When you start labeling your “buckets” as tool names like software developers do, it puts you into the mindset of reuse instead of just dropping another script into a generic folder somewhere.

Commit Code Changes Based on Small Goals

Regardless of what version control tool you use, always try to commit code to your repository (repo) of choice based on a small goal. What’s a “small goal”? Think about the last time you made a change to one of your existing scripts that probably will take a couple of hours. What was the purpose? What was the desired outcome? That’s probably a single commit.

Consider, for example, you have a script that installs some software for a particular application. During your testing, you find that the script fails when it encounters a certain use case. The code to account for this use case will take less than 1–2 hours. You make the changes, test locally on your computer, and then you should create a commit with an informational message like “fixed that issue where X happens when Y.”

You should commit changes to your repo several times a day. If not, your working code isn’t “backed up” anywhere. If your local repo is wiped, you will lose that code forever.

Create a Branch Based on a Feature

If you’re committing code to fix a single edge case that may take you an hour to fix, a branch is a group of these commits. Think of a branch as a single feature or maybe fixing a problem in the code that may affect other areas of the code.

Maybe you have a module and a set of scripts that all coordinate with each other to manage a large line of business application called PSAcmeApp. You’ve spent many months on this project and helps automate and manage many aspects of this application. Let’s say your manager comes to you and tell you they’re getting ready to roll out the next major version of this application but you still need to maintain support for v1. You have no idea how this new version will work with your project. A branch would be a good strategy here.

You could create a branch called v2 off of your main branch and perform all of the work necessary for v2 knowing you’re not affecting the stable v1 version. Once you’re satisfied, you can then merge your v2 code with v1 enabling your tool to support both versions.

Use a Distributed Version Control Service

Version control, in and of itself, is an independent endeavor. A single person commits changes, rolls back changes, and manages code by themself. It’s not until you begin to work on a team, need to share code, or integrate your code with other systems, you may not need distributed version control.

Popular distributed version control services like GitHub are extremely popular and for good reason. Once you sync your local repos with GitHub, you can then easily share your code with others online, collaborate with teammates on a shared project, integrate with other tools like continuous integration or various testing tools, and more.

Using a distributed version control service is the next step in PowerShell development and should be the default for every new script and tool you create.