by I started getting into PowerShell a few years ago because I believed it would make my life easier when trying to perform tasks as a System Administrator. I had no idea the hold it would have over me years later, and how much I enjoyed scripting and solving problems via code. Fast forward back to the present, and now that bug has caught the attention of several of my coworkers. As a result, I’ve found myself sharing scripts and functions more frequently than ever before.
To aid with this, I felt it was time we start moving to something a little more formal with some better tools for collaboration. Here is where Git for System Administration enters the chat.
I’ve wanted to write this piece for a while. Git is a tool leveraged by developers all over the world to store code, share code and track changes in code every day. It has version control built in as a key feature and allows for securely updating code from anywhere. When you are leveraging a repository like GitHub you gain the ability to include things like automation and integration with other tools. Finally, you can have code branches and forks to allow for both collaboration and code review. It’s a phenomenal tool, and to be totally honest, I’m SUPER late to the party. Oh well! I’m here now! Let’s get started.
DISCLAIMER
Please understand that the content herein is for informational purposes only. This existence and contents shall not create an obligation, liability or suggest a consultancy relationship. In further, such shall be considered as is without any express or implied warranties including, but not limited to express and implied warranties of merchantability, fitness for a particular purpose and non-infringement. There is no commitment about the content within the services that the specific functions of the services or its reliability, applicability or ability to meet your needs, whether unique or standard. Please be sure to test this process fully before deploying in ANY production capacity, and ensure you understand that you are doing so at your own risk.
Table of Contents
Introduction to Git for System Administration
Setting Up the Environment
Initializing the First Repository – Command Line
Initializing the First Repository – VS Code
First Commit to Main
Conclusion
Introduction to Git for System Administration
As usual I’m going to start this off by saying that I’m by no means an expert. This is a “Getting Started” and not a “Masterclass” for a reason. You won’t become an expert from this series. However, you will learn enough to get started and have a good base to start from when pursuing your own projects. This article will be a little light on the ‘git for system administration’ side but will get us started so we can leverage it more later down the road.
What is Git?
Git is an Open-Source tool used for version control and tracking changes over time. According to the main site, here is the main thing to understand. Use the link below to continue the deep dive.
The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data… other systems think of the information they store as a set of files and the changes made to each file over time… Git doesn’t think of or store its data this way.
Instead, Git thinks of its data more like a series of snapshots of a miniature filesystem. With Git, every time you commit, or save the state of your project, Git basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn’t store the file again, just a link to the previous identical file it has already stored. Git thinks about its data more like a stream of snapshots.
Git – What is Git? (git-scm.com)
Why use Version Control Software?
Why might this matter? Consider this scenario (that has definitely happened to me before…), you have a working version of your code, but you have an idea of something that might add functionality or make the code more efficient. You could save a new version and edit that one until you have a working bit of new code. But now you have 2 copies of the code.
That may require you to update folder paths or file names to several files and could be more work than it is worth. Or you could edit your existing code, realize later that what you were trying won’t work like you thought, and then figure out how to undo the changes you made. Either way, you run the risk of additional work and breaking your code.
Since Git uses snapshots, you can go back to previous versions of your code. This means you can commit your code before you make any changes, make your changes, and revert them back if it goes bad. Similar to how you might snapshot a VM before making major changes, you can do the same thing with Git. Additionally, Git allows you to go back to a previous version, copy the files out to a separate location, and then go back to the latest version in your branch retaining both copies. This is an excellent way to allow for continuous development while protecting production type work against accidental deletion.
How to Use Git
On its own, Git is a command line tool. Everything is done through the command line, from creating a repository to committing changes or reverting to a previous version. However, Git has been around long enough it to have several iterations of Desktop/GUI applications that make it easier to interact with Git in everyday use. Visual Studio Code is my IDE of choice, and it has extensions available that allow you to use Git from directly within VS Code. This integration makes using Git seamless in your workflow.
Additional tools include:
Setting up Your Environment
We’re going to start with the most basic setup first and progress to more complicated setups later. This post is meant to be for System Administrators; meaning you may be solo, or you may be part of a team. You can benefit from Git either way so we will start with a solo setup and work from there.
Installing Apps
First you will need to download and install Git. The link can be found here. Download and install Git for whatever OS you plan to use it on.
Next, I recommend downloading and installing Visual Studio code. I believe it is advantageous to use an IDE that will let you include the Git tools directly into the workflow. Visual Studio Code integrates directly with Git once they are both installed, allowing you to use the VS Code GUI to interact with Git. In addition, VS Code works really well when editing in markdown, so your README.md files can be edited easily and formatted simply to make them interesting and attractive.
Installing Extensions
Extensions extend the capabilities of various tools directly into VS Code. There are several options available for Git, and I recommend trying a few to see what catches your fancy. However, there is one that I recommend as a minimum to get installed into VS code, as it will make a difference once you start working in remote repositories. That extension is GitHub Repositories.
The GitHub Repositories extension lets you quickly browse, search, edit, and commit to any remote GitHub repository directly from within Visual Studio Code. If you don’t plan on ever using GitHub Desktop or GitHub Repositories, then you may not ever need this extension. For example, if you were using Azure DevOps, then it wouldn’t make sense to get this extension. However, since my scripts here are hosted in GitHub, this is the one I prefer. If you don’t have a preference, you can start here and then make your own choice as you learn more about the whole process.
Initializing the First Repository – Command Line
Your repository is the location where you are working with Git. If you were a solo system administrator and just wanted version control to function locally, this is how you could get started.
- Open command prompt (or terminal) and enter these commands to navigate to the directory of your choosing (example here is the Documents folder).
cd Documents # Navigate to the Documents folder (or your desired location)
- Next you want to create a directory that has the name of your new project or where you plan to store the files for this repository.
mkdir my_project # Create a new directory named 'my_project'
- From here, you want to change directory into that newly created folder.
cd my_project # Navigate into the 'my_project' directory
- Finally, use this command to initialize the folder for use with Git
git init # Initialize a new Git repository
Initializing the First Repository – VS Code
- First, in VS Code, open a folder, in whatever location you want to be your GitRepo. When using Git for System Administration, this may be a local folder, or a network folder. Whatever works for you is fine.
- If prompted, go ahead and indicate that you trust the authors of this directory (as it should be you as the author).
- In VS Code, on the right-hand side, choose the ‘Source Control’ tab. You should see an ‘Initialize Repository’ button. Click that to initialize the folder you are in currently.
- Now you should have a directory ready to use with Git and can begin your version control journey!
First Commit to Main
The last thing to know and understand to get started is how to commit your changes. The biggest thing to keep in mind is that this is a snapshot-based process. Every commit is like taking a new snapshot of the environment, or a new restore point for the environment. To see this in action, lets create a README document, so that anyone else who might someday see this, knows what we are trying to accomplish. A README file is typically written in markdown to make formatting and readability easier. I’ll be using VS Code from here on out, but the process is the same with command line.
Creating a README file
- Within that folder that we initialized for Git, lets create a file. Save this file with the name ‘README.md’
- The first thing you should notice is that the file name changed colors, that there is a ‘U’ icon at the end of the line, and there is now a number 1 on the Source Control tab. This is how we know that Git is functioning. It recognized there was a change in that directory since our last commit (initialization in this case). The ‘U’ stands for ‘Untracked’ because this is a new file.
- Click the source control tab, and you should see a section for a comment. In this case, you can put whatever you want in here, but these comments are an opportunity for you to understand what the purpose of this snapshot is. Make sure that you are including enough information that if you needed to restore back to this version, the comments would help you understand where in the timeline you were. Give this a comment like ‘Initial Commit’ and hit the Commit button.
- You should see the file that was created, disappear from this list, and the indicators of change we mentioned above should all go away. Congrats! You committed your first file to your first Git Repository.
Conclusion
You are now ready to begin working with Git. There is much more to talk about, but this is all you need to be able to start completing work on whatever project you want to work on. In my case, I plan on building out a repository of PowerShell scripts I have written and used in the past for both work and personal use. With that use case in mind, I can start to build out a folder structure and organization methodology for me to use to keep things organized. This is where we will be able to start thinking about how to use Git for System Administration.
In the next post, we’re going to spend some time talking about connecting to a remote repository, like GitHub, and cover some basics like the README file formatting and committing changes. Ultimately, we want to work to a place where we can collaborate with others and share our scripts as needed. I hope you found this first part of the getting started guide helpful. Let me know if you have any thoughts or suggestions on what else you would like to see. I’m happy to get everyone working and using these tools to make your lives easier.
Alternatively, if you have any topics specifically you need help with, let me know! I’m by no means an expert, but I like a good challenge! Hit me up on Twitter @SeeSmittyIT to let me know what you thought of this post. Or if you are avoiding the bird site, I’m also posted up on Mastodon @[email protected]. Thanks for reading!
