Git for Network Engineers – Part 2
Getting Started
In Part 1 we discussed why git for network engineers. In this part of the series we will start discussin how to start using git and creating your first repository.
The first thing would be to install git. This process varies by platform, but there are instructions right on the git website for each platform. https://git-scm.com/downloads
Once we have git installed, we will want to set the default username and email that will be associated with our commits. This provides context especially when more than one person is making changes to a repository. We will use the git config command with a couple of modifiers to make these changes. These can be set to any arbitrary values, but generally you want this to match your username and email in whatever git server you are using (GitHub, GitLab, BitBucket, etc) as there’s usually permissions assocated with those. A quick note, is you can actually set different user information on a per-repository basis, by using --local instead of --global. This is useful if you work with multiple organizations as a consultant or that kind of multi-tenant environment.
git config --global user.name bile0026 git config --global user.email [email protected]
Now that we have the settings out of the way. You can turn any existing project into a git repository, or start with a new project. I’ll be using VSCode in my examples since it seems to be the most prolific code/text editor for automation engineers. VSCode is very flexible and has a lot of extensions which can help working with different types of environments and files. We will start here with a new folder with a single file called blog_post.txt. We will open this in VSCode and click on the source control tab on the left hand side (it’s the one that looks like a y with circles on the points). We can then click “initialize repository” to turn this folder into a git repository and start tracking history. The equivalent cli command would be git init then git add -A (git add all). By default this will add all files in the current folder to be tracked by git in a recursive fashion.
VSCode will now tell us that we have a commit we can make. Any time you modify a file and save it in VSCode you will see a notification on the source control tab saying that there’s changes to commit. Each commit requires a comment associated with it, so we’ll just say “first commit” on this one, which is pretty standard for a new project to commit the basic files and folders to the project before any work is done. The CLI equivalient is to use git commit -m "First commit", or if you just type git commit, it will open your default cli text editor which is asking for your commit message. Once you save and close the editor the commit will actually complete and be added to the git database.
Every time you commit changes to git, it acts basically like a restore point for the repository. This way you can easily revert changes to a project by looking at the git history. After commiting, VSCode will give us the option to publish the repository to a remote (git server). We’ll skip this for now. If we now view this folder in a terminal we can see a new hidden directory is created .git. This is where the git history is stored. As an aside, to stop tracking a repository/folder with git, just delete this directory. Be careful though as this will irreversably delete all your git history and all git tracking information.
Now that our repository is initialized every time we want to commit changes, we can go to the source control tab and type in our commit message (describes what changes were made), and click commit. One comment on some of the things that VSCode does in the back end that you may not realize at first, the first being automatically adding all new files to be tracked by git (Unless excluded via the .gitignore file. More on this later). If you are doing all this from a cli any new files/folders you create have to be added to the git database by using the git add <file_name> command (or git add -A) as they won’t be tracked by default.
Adding More Files and Commits
Now we can add a couple more files and maybe a folder and see what happens. We can see that those new items are green in VSCode, meaning they have been added to git to be tracked, and have changes that need to be commited. The general idea with commits is to make small incremental changes and commit these along the way. That way commit messages are simple and its easy to revert certain changes if the need arises. Commit small, and commit often!
Now we can go back to the source control tab and add a commit message, and commit these changes. Remember, if you do this via the cli, git will not automatically add new files/folders to be tracked, and you’ll have to use the git add command discussed above to add them before you try and commit. After the commit is complete, we’ll see the green highlighting went away and there are no notifications on the source control tab.
Checking Git Status in the CLI
When working with git in the cli, it doesn’t give you as many helpful features as when using a graphical client. There’s a couple ways to see what the status is of your git history and current files. Using git status will give you some information about if you have untracked files, if there are commits pending, etc. We can see from the screenshot below, I have 2 new files waiting to be committed. They are are also staged (green) because this is the same folder we’ve been working with in vscode. I’ve also added a new file “blog_post3.txt” via a cli text editor, so VSCode has not automatically added this file to be tracked, which can be seen by the red highlighting.
After using git add blog_post3.txt we can see that all changes are “staged” meaning they are being tracked by git and have commits avaiable. By running git commit -m "Third Commit" and checking status again we can see that there are now no changes in the repository to commit.
Viewing Git History
Now that we have a few commits in our repository we can take a look at the git history in VSCode. It’s simpler in my opinion to visualize it in a graphical client than in the cli since it draws pretty pictures.
From the source control window, I’ll expand commits, and commit details. If you drag the commit details window all the way to the right-hand side of the screen it will open larger and make it easier to view. Then click on “show commit graph”, which opens the middle pane where I can see the commit history. Then by selecting a commit I can see what files changed and what my commit message was. This helps to follow the history of a project and what has changed. We can also see the branch that the commits were made to. More on this later, but here’s an example of a project that has had multiple branches and commits.
This hsitory is obviously more complex, but by reading the commit messages you can probably get an idea of what changed each time. I threw in a couple of precursors like the develop branch, which you can see in the most recent commits. We will discuss more on branches in the next blog post. There’s also tags v2.0, v1.5 which is a more advanced topic, but is just a way to tag certain versions of your project for reference later in something like a CI/CD (Continuous Integration Continuous Delivery, which is a whole topic on it’s own) pipeline to deploy a specific version of a project.
If we want to view this same information in the cli we can but it’s a lot more difficult to follow as the history grows. By running git log it will open the history in your default cli text editor. I definitely prefer the pretty pictures!
commit b28507658df4420b7f8e45e479a7a1db393e054d (HEAD -> main) Author: bile0026 <[email protected]> Date: Thu Jan 26 06:30:03 2023 -0600 Third commit commit 2611524fd1ef3877f30c619bd5c452607ffca46b Author: bile0026 <[email protected]> Date: Thu Jan 26 06:29:39 2023 -0600 Second commit commit c84fc1e1aed1d202a84aeb8baad038834c6c92e0 Author: bile0026 <[email protected]> Date: Wed Jan 25 20:55:12 2023 -0600 First commit
Here we can also see that every commit has a hash associated with it, which can be used to reference a specific commit if you need to revert changes, or for a much more advanced topic called cherry picking. Cherry pick is where you grab multiple “hand-picked” commits to be used in a revert or pull request without performing the action on the entire git history.
Wrapping Up Part 2
So far we’ve discussed what git is and why to use it in Part 1, and how to setup our first repository in Part 2. In Part 3 we will cover some more about how to handle branching, cloning, pushing, and pulling git repositories. Stay tuned!
One thought on “Git for Network Engineers – Part 2”