Git basics for IT pros: Using it with your PowerShell scripts

In a previous article, we introduced the basic concepts of Git for IT professionals. In this article, we will get a little bit more advanced by showing IP pros how to use Git to track their PowerShell scripts.

We will be installing Git on Windows Server or workstation, and then we will create our first repo, configure our personal information (which is required before starting the process to track changes), and finally work with some simple scenarios where we can take advantage of Git to control and use different versions.

Installing Git on a Windows Server/workstation

Git is available on all platforms: Linux, MacOS, and Windows. In Microsoft world, we can download the GitHub Desktop software and that one comes with Git built-in, however, we will play simple and we will install just Git itself on our Windows Server to test and validate the concepts introduced in our previous article.

The first step is to visit the Git website and download it for Windows. (You can use this link here.) It is also nice to have a useful code editor to play with files and Git during the installation will ask for your current code editor. Microsoft offers Visual Studio Code for free, and if you don’t have any preference, that could be a really good start. You can download it from here.

  1. In the Information page, the GNU (General Public License), which gives you the freedom to modify and share the software, will be displayed, click on Next.
  2. In the Select Destination Location page, by default it will be installed under C:\Program Files\Git, click on Next to continue.
  3. In the Select Components page, we can define the integration of Git with the Operating System. Click next.
  4. In the Select Start Menu Folder page, Git is the name that will be created in the start menu. Click on next.
  5. In the Choosing the default editor used by Git page, here is where we can select which editor we are going to use with Git.
    Note: If you haven’t installed your preferred editor yet, install it using the link provided by the installation wizard. After the installation, click on Back and next to refresh the newly installed software and that will allow the installation to continue.
  6. In the Adjusting your PATH environment page, here is how the environment variables will be configured to support Git. If you don’t have any special requirements leave the default settings and click Next.
  7. In the Choosing HTTPS transport backend page, we can define how Git will use the TLS library to be used with HTTPS connections (my preference for Windows is to use Use the native Windows Secure Channel Library option). Click on Next.
  8. In the Configuring the line ending conversions page, we can define how Git will work with ending lines in text files being controlled, and it matters how it is going to be your integration among platforms. Leave the default settings if you don’t have any requirement in this area, and click Next.
  9. In the Configuring the terminal emulator to use with Git Bash page, my preference in Windows is to select Use Windows’ default console window and click Next.
  10. In the Configuring extra options page, we can enable some options such as file caching and MFA (multifactor authentication), which are the first two options. Leave the default settings, and click Next.
  11. In the Completing the Git Setup Click on Finish.

Initializing the repository and first changes

Git keeps track of all changes, and, most important, it also tracks who performed the changes, which is great when working with teams. Although we are flying solo in this article, our first step is to define our name and email before starting tracking our upcoming scripts.

These following commands will define such parameters, and in the third and fourth commands, we will check the information that we have just entered.

Git config --global user.name “Name Lastname”
Git config --global user.email “alias@domain.ca”
Git config --global --list

Now that we have Git installed on our Windows Server and we configured the local Git with our information for tracking purposes, let’s create a folder and initialize the Git repository (better known as repo). Open PowerShell and perform the commands listed below, which will create a new root folder called PSScripts (PowerShell Scripts) and then we are going inside of that folder to initialize the repo using git utility.

Cd \
Mkdir PSScripts
Cd PSScripts
git init

The results will be a new folder .git being created under C:\PSScripts as depicted in the image below.

Time to create our first script file and add some code into it. We will create a new PowerShell script called Get-SecTLS.ps1 and after adding our first line of code, we will perform three separate actions, as follows: first we will check the content of the script just for reference, and then we will be adding the new file to the staging area (first command), then we will check the status of the Git in the current folder, and last but not least, we will commit that snapshot created on the first command to the local repository. All cmdlets are listed below, and the entire action can be seen in the image depicted below.

Command Brief Explanation
Get-content Get-SecTLS.ps1 View the current content of the file
Git add Get-SecTLS.ps1 Add the file to be tracked by git and to the stage area using the current content
Git status Check the status, it will inform that we have a new file that wasn’t committed yet
Git commit -m “string” Commit all the staged changes and the label for this commit will be the string provide after the -m

After the commit is executed (image below), we will run another Git status and at this time it informs us that we are working on the default branch called master and there is nothing being changed from the files that we are monitoring, and nothing to commit.

One important point is that the hash of the commit is informed in the output. We can use that hash to go back and forth in our commits later on.

Time to perform new updates. Let’s commit the second wave of changes, and we will perform the same sequence that we performed in the initial commit. You may be wondering, do I have to add it again? The answer is Yes, the Git add is to add any given file to the staging area, and it is not a onetime thing for the file. But after the first Git add, the file will be tracked moving forward. We will cover the process to remove a file from the list in a different article.

After making some changes to our script, we will run Git status and it will inform us that a previous tracked file has been modified. If we want to get a snapshot of what we have, then we should use Git add <file>, and after that another Git status will give us information that the modified file that we have just added is ready to be committed, which we do in the last command.

Working with commits

Until this point, we wrote our code and when we had a good stable script, we committed the changes and label such commits for future reference.

Time to take advantage of Git using a few key features of the solution. Let’s start by checking where is the head, which is a pointer that shows where is the current change is being located. We can list all the commits using the following command (Step 1).

Git log --oneline --graph --all

Now that we know all the current commits, we can check the content of our script using the command in Step 2.

Get-content .\Get-SecTLS.ps1

Let’s pretend that our new additions are not good and we need to check what we had added in the first commit, we need to use the command below (Step 3 and Step 4) using the checksum associated to the commit that we want to restore, and after that we will check the content of our script and at this time the content will reflect the changes that we have committed in the first commit.

Git checkout <checksum>
Get-content .\Get-SecTLS.ps1

If we want to go back to the latest development, we can use master which is the branch name and that helps to move the HEAD back to the latest development (Steps 5 and 6).

Git checkout master
Get-content .\Get-SecTLS.ps1

Using Git we were able to check the stable commits of our script to the source control and be able to move back and forth to validate the script code without working with two different files. We were able to work with views in the same location.

We are going in more details and scenarios in our upcoming article, however, for now, we have enough tools in our toolbox to deploy and use Git to support our scripts.

Anderson Patricio

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides of the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange, CISSP and several other certifications. Anderson contributes to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at Techgenix.com, MSExchange.org, ITPROCentral.com and Anderson Patricio.org (Portuguese).

Share
Published by
Anderson Patricio
Tags git

Recent Posts

Simplifying cloud complexity: 4 roads to the same destination

As cloud computing grows, the sheer number of options can be a problem. But there…

2 hours ago

Building Exchange 2019 from scratch: Setting up a domain controller

If you are building a new Exchange 2019 environment from scratch, you will have to…

5 hours ago

RAID 1 vs. RAID 5: When to use each level and why

Redundant array of independent disks (RAID) is the logical grouping of two or more disks…

1 day ago

Microsoft 365 adds online scheduling to Microsoft Bookings app

Microsoft 365 users have access to an app called Microsoft Bookings. Before you dismiss it…

1 day ago

Biometrics authentication: Where the technology is now — and where it’s going

As cyberthreats rise in number and complexity, biometrics authentication technology has seen rapid adoption and…

4 days ago

Remote work vulnerabilities: Tips on avoiding a nightmare scenario

Remote work is likely to remain permanent — and so will the vulnerabilities it brings…

4 days ago