This is the first of a multi-part series intended to share practical knowledge about Git for network engineers, as well as some tips and tricks that I have learned over the years that will hopefully make your journey easier!
Why Should I Know Git as a Network Engineer?
Version control systems, primarily Git, are becoming more and more prevalent outside of the realm of software development. The increase in DevOps, network automation, and infrastructure as code practices over the last decade has made it even more important to not only be familiar with Git, but proficient with it.
As teams move into the realm of infrastructure as code, understanding and using Git is a key skill.
What is Git?
Git is a Version Control System (VCS). Version Control Systems record file changes over time, giving you the ability to recall previous revisions and see the history of changes. On the surface, it seems simple. However, things get more complicated when you start working with others on the same set of files.
Git is known as a distributed VCS. This is primarily how the Linux kernel development team utilizes Git. For most the use of a centralized location like GitHub, GitLab, or an internal Git server is typical, especially because there is even more functionality associated with these centralized Git systems like GitHub and GitLab.
Short History of Git
Linus Torvalds created Git in 2005 to replace a commercial VCS used by Linux kernel developers. Linus Torvalds, who was also the creator of the Linux kernel, designed Git to be:
- Speedy
- Simple design
- Support parallel development
- Distributed
- Handle large projects efficiently
Nowadays, Git is maintained by a team of Open-Source developers who are continuing to improve Git as we know it.
How Git Works
Unlike other Version Control Systems, Git uses a snapshot method to track changes instead of a delta-based method.
Every time you commit in Git, it basically takes a snapshot of those files that have been changed while simply linking unchanged files to a previous snapshot, efficiently storing the history of the files. Think of it as a series of snapshots where only the changed files are referenced in the snapshot, and unchanged files are referenced in previous snapshots.
Git operations are local, for the most part, meaning it does not need to interact with a remote or central repository. (There are specific commands which do interact with remote repositories, but we will be covering that in the next article.)
Everything in Git is checksummed. This not only maintains the integrity of the repository by allowing Git to detect corruption but it is used as the reference to most objects in Git, such as commits, tags, etc. Git uses the SHA-1 hash, represented as a 40-character string of hex (digits and a-f characters) as the checksum. You’ll see these types of hashes a lot when working with Git.
I feel it is important to note (and this will become clearer as you use Git) that Git has three main states for a file:
- Modified: File has changed, but not committed to yet
- Staged: File has been marked to appear in the following commit snapshot
- Committed: File has been safely snapshotted
This will make more sense later once you see it in action.
Getting Started with Git Locally
I think it’s important to understand the basic operations in Git. One of the best ways to learn is to create your own local repository. Now, a local repository is just that: local. It has no remote repository locations configured, and we will not be interacting with a remote repository.
Don’t worry. We’ll be covering remote repositories in the next article in this series.
Basic Git Commands
We will be working with the command line version of Git. For the most part, a majority, if not all graphical user interface Git have the same concepts or even refer to the operations the same way as the command line operations. Understanding the command line will be helpful for later when using graphical Git tools.
Configuration :: git config
The git config command allows the setting and getting of configuration options either system-wide, global for the user, or at the repository level.
Before we can really do anything in Git we need to set our user.name and user.email. These are used when we commit and will become much more important when working with remote repositories. Typically, these are set globally, but they can be set at the repository level as well. When a configuration option is set at the repository level that value overrides the set global configuration values.