momius - Fotolia

Learn Git basics with a sample case study

Git allows team members to work together using the same files. This tutorial will help Windows systems administrators learn how to use Git for version control.

As much as some of my system administrator friends don't want to admit it, we're now in the midst of the DevOps movement. Part of DevOps involves IT operations specialists gaining familiarity with developer tools and practices. Today we'll learn how Windows systems administrators can make good use of the Git distributed version control system.

To help us learn Git and GitHub basics quickly, we'll adopt a case study format. To that point, I'd like to introduce you to my fictional friends, Mike and Jessica.

The need for version control

Mike and Jessica are Windows systems administrators for YYZ Healthcare in Nashville, TN. After attending a local Windows PowerShell User Group meeting, both became convinced that Windows PowerShell-based administrative scripting could help the YYZ IT department maintain its service-level agreements and make their professional lives easier.

Mike and Jessica began by creating a central, shared folder for their PowerShell .ps1 scripts. Before too long they realized they were losing work because each was periodically stepping on the other person's toes. What's worse is there is no historical record or ability to rollback to an earlier version of a script.

Jessica knows a bit about source code control, so she brought Mike up to speed on why they need Git. Here's the elevator pitch:

  • Git is free and open source, unlike many other version-control systems (VCS) platforms -- BitKeeper licensing, for instance, runs upwards of $100 per seat per month.
  • Git is distributed, which allows developers to work with a full copy of the code repository from wherever they are. Centralized products such as Microsoft Team Foundation Server require a connection to the central source to ensure the code is current.
  • Git is integrated into many tools and services, such as Visual Studio Code and Microsoft Azure.
  • Git has a simple, elegant syntax. Also, if you don't like the command line, you can use one of a seemingly infinite assortment of GUI front ends.
  • GitHub makes it easy to store your local Git repositories in the cloud, either privately for a monthly subscription price or publicly for free.

Setting up Git

Mike and Jessica downloaded Git and installed the program with all defaults, except for the following tweaks:

  • On the Adjusting Your PATH environment screen, select Use Git and optional Unix tools from the Windows command prompt. This option gives us Secure Shell and other useful utilities from our PowerShell console.
  • On the Configuring the line ending conversions screen, select Checkout Windows-style, commit Unix-style line endings. This option makes the Git-tracked source code play well with OS X and Linux systems should the need arise.
  • On the Configuring the terminal emulator to use with Git Bash screen, select Use Windows' default console window. This option loads our cmd.exe and powershell.exe environments with maximum flexibility with Git.

Adjusting the Git configuration

After installation, Mike and Jessica opened an elevated PowerShell console -- right-click the PowerShell icon and select Run as Administrator from the shortcut menu -- and run git --version to verify installation:

git --version

git version

Before they can begin using Git to track their PowerShell script projects, the team needs to modify their Git configuration, notifying the tool of their user name and email address. We do that with git config. Here's Mike's code:

git config –-global "Mike Love"

git config --global "[email protected]"

Here's Jessica's code:

git config –-global "Jessica Silberg"

git config --global "[email protected]"

We can verify the configuration by listing all Git settings by using the l -- lowercase L, not a 1 -- switch:

git config -l

Creating a Git repository

Git is distributed, which allows developers to work with a full copy of the code repository from wherever they are.

Mike started the scripting process by creating a folder on his system named mikescripts and sharing the folder on the YYZ corporate network. Specifically, he ensured that Jessica's Active Directory user account has read/write access to the shared folder.

Mike created a new PowerShell script file inside the mikescripts folder named uptime.ps1. He then opened the new script in the Windows PowerShell Integrated Scripting Environment and built a simple function that calculates system uptime:

function Uptime {

   $os = Get-WmiObject win32_operatingsystem

   $uptime = (Get-Date) - `


   $Display = "Uptime: "+ $uptime.Days + " days, " + $uptime.Hours + " hours, " + $uptime.Minutes + " minutes"

   Write-Output $Display



We're not concerned with the PowerShell code specifically in this tutorial. Instead, we're getting comfortable with Git source code control.

Mike then used the cd command to switch his PowerShell console focus to the mikescripts folder and runs the following command to start version tracking on all folder contents:

git init

Initialized empty Git repository in C:/Users/mike/mikescripts/.git/

Specifically, Git creates a hidden folder named .git that contains the actual version-tracking database. You can use Git to track multiple folders on the same system because Git creates a separate database for each tracked folder.

Mike ran git status to see how Git perceived the mikescripts project folder:

git status

On branch master

Initial commit

Untracked files:

  (use "git add <file>..." to include in what will be committed)


nothing added to commit but untracked files present (use "git add" to track)

What the output told Mike is that Git sees the uptime.ps1 file, but is not currently tracking changes. Mike fixed that by first staging the file for an initial commit:

git add uptime.ps1

Next, he formally committed the file to the repository. It's considered good Git practice to include a descriptive commit message to describe which change the commit contains:

git commit -m "Initial commit"

[master (root-commit) e024855] Initial commit

 1 file changed, 8 insertions(+)

 create mode 100644 uptime.ps1

I'd like to draw your attention to two elements from the previous Git commit output:

  • master: All Git repositories have a main, or master, branch. As a project grows, developers usually create branches to post fixes.
  • e024855: This is a unique identifier for the commit.

Cloning a Git repository

Jessica wanted to get involved so she started by cloning -- creating an exact local copy -- of Mike's script repository. Like Mike, she created a shared folder on her system named jessicascripts. She also used cd to shift her PowerShell console focus to her folder.

We use git clone to copy an existing repository:

git clone file:////mikepc/mikescripts

Cloning into 'mikescripts'...

remote: Counting objects: 3, done.

remote: Compressing objects: 100% (2/2), done.

remote: Total 3 (delta 0), reused 0 (delta 0)

Receiving objects: 100% (3/3), done.

Checking connectivity... done.

Jessica then switched into her local mikescripts folder and enabled Git revision tracking:

git init

More Git resources

While this is just an introduction to Git, this should help get Windows Server administrators started with the version control process. Here are a few more resources to help build your budding Git skills.

Making and pulling changes

Jessica noticed that Mike's Uptime script didn't use the accepted Verb-Noun format. Therefore, she opened her local copy and edited the source code:

function Get-Uptime {

   $os = Get-WmiObject win32_operatingsystem

   $uptime = (Get-Date) - `


   $Display = "Uptime: "+ $uptime.Days + " days, " + $uptime.Hours + " hours, " + $uptime.Minutes + " minutes"

   Write-Output $Display



Just like Mike did earlier, Jessica staged and committed her change:

git status

git add uptime.ps1

git commit -m "Change function name to verb-noun format"

Jessica sent Mike an email notifying him that she tweaked the script. Now it's Mike's turn to work on the function.

He ran git pull to perform a fetch of Jessica's file copy and merged the changes into his local copy. Remember that Git is a distributed VCS; you can expect to see merge conflicts arise from time to time, and it's your job to resolve them.

git pull file:////jesspc/jessicascripts/mikescripts

remote: Counting objects: 3, done.

remote: Compressing objects: 100% (2/2), done.

remote: Total 3 (delta 1), reused 0 (delta 0)

Unpacking objects: 100% (3/3), done.

From file:////jesspc/jessicascripts/mikescripts

 * branch            HEAD       -> FETCH_HEAD

Updating e024855..e97828b


 uptime.ps1 | 4 ++--

 1 file changed, 2 insertions(+), 2 deletions(-)

Next Steps

New to Git and distributed version control? Here are some Git examples and Jenkins-Git integration tutorials designed to help you master the popular source code versioning tool.

Dig Deeper on Windows administration tools