Git is a distributed version controlling system developed by Linus Torvalds in 2005 for maintaining the development of the Linux kernel. If you are familiar with virtualization you may also be familiar with making snapshots of a virtual machine.
Version controlling is doing the same thing with your files or your code. It keeps track of the file and maintains the version.
There are many questions about how Git fits into the world of networking. Why should network engineers learn Git? Is there any special Git version for network engineers?
Let’s try to explain.
Why you need to add Git to your toolbox
The increasing demand for network automation requires today’s network engineers to learn how to program. This doesn’t just mean writing code, but also managing code and scripts properly. Maintaining a proper file version manually is a tedious job. This is where Git can help.
Git is not a language that you need to learn, it’s a tool. You just need to learn how to use it. There is no special version of Git available for network engineers, it’s the same Git used by software developers.
GitLab is probably the best known use of Git. It is a web-based tool that works as a remote Git repo. You can upload your local Git repo here and can share your code/work with others.
Actually, GitLab is more than that; it’s not only used for sharing/collaboration, the complete DevOps lifecycle can be managed by GitLab. It has many features like continuous integration (CI), continuous delivery (CD) and issue tracking. GitLab can be integrated with many other tools like Slack and email. Best of all, you can deploy a local GitLab server in your own premises.
Getting started with Git
Installing Git is very easy. If you are using debian/ubuntu you can use apt-get. Mac users can use homebrew.
In this tutorial I’ll show you:
- How to create a remote repository/repo (private) with GitLab.
- How to create a local repo with Git in your workstation and play with Git commands.
- How to make incremental changes in your local repo and sync that change in the remote repo.
- How to make a copy of your work without losing the original.
- How other team members can contribute to your project.
Remote repo with GitLab
We will start our ‘how to’ by creating a remote repo.
First, you need to create an account in GitLab. Go to https://gitlab.com/users/sign_up and follow the steps to create a GitLab account. After that login to your GitLab account.
Everything in GitLab starts with a project. So, for creating our remote repo we need to create a project. After logging in to your account:
- Click on the “New Project” button.
- Give it a name, for example “net_prog”. You can choose any other name you like.
- Select visibility level “private”.
- Click on the “Create Project” button.
Our remote repo is ready. Let’s go to our workstation for creating the local repo.
Local repo and playing with Git commands
Git local repo is a place in your workstation where your original code resides. In this section we will create a directory on our workstation and make that directory a Git repo. After that we will try various Git commands.
First, create a directory. You can choose any name you like for your local repo. For simplicity, I’ll give the same name as my remote repo.
mkdir net_prog cd net_prog
Let’s make this directory a Git repository. Type the command below in your terminal and press enter.
git init
After that you will see the following message:
Initialized empty Git repository in /home/imtiaz/net_prog/.git/
Our local Git repo is created. Simple isn’t it! As you can see Git created a hidden directory called “git” inside our net_prog directory. This directory will be used as a set up directory for this repo.
Let’s check the status of our repo by typing the following command:
git status
You will get an output like the following:
On branch master No commits yet nothing to commit (create/copy files and use "git add" to track)
This tells us that this is an empty Git repo and we are in our master branch, and we haven’t made any commits yet. (I’ll discuss branches shortly).
Let’s add a file and see what “git add” and “git commit” are.
Create a new file:
touch file1
Let’s see what Git tells us now if we provide the following command:
git status
This time you will get an output like the previous one but with some more information:
On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed)file1
nothing added to commit but untracked files present (use "git add" to track)
Notice how Git detects our newly added file file1 and it’s showing that this file is untracked. We need to tell Git to track the file so that whenever I make any changes, it can record it and if needed, I can restore the file again.
Let’s tell Git to track my file. Type the following command:
git add file1
Let’s check the status again by Git status command:
On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage)new file: file1
Notice how the colour changes from red to green. This means Git has started tracking this file. If you make any changes now, Git will again tell you that you have an untracked file.
Activity: I have a small activity here for you. Make a change (maybe you can add a line) in that file and see the result. After that, tell Git to track the file again. Use the Git commands you learned so far to complete the activity.
Now we will see two more Git commands called git commit and git log. Only committed files can be restored. When you tell Git to track the file with git, add the <filename> command. Git actually puts that file in a place called “stage”. Only stage files can be committed, and can be found in the Git history.
We have a file in the staging area and now we can commit the file. Before that you need to tell Git a bit about yourself with the git config command. It tells Git who you are and what your email address is. This information will be required when we commit our changes in the Git repo. In your terminal type the following command:
git config user.email "YOUR_EMAIL_ADDRESS" git config user.name "YOUR_NAME"
We are ready to commit our file. Type the following command to commit our file:
git commit -m "Initial commit" [master (root-commit) aeaa56e] Initial commit 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 file1
With -m flag you can input any messages. Use a meaningful message here — it will help you during the restore time. Git computes a sha1 value and uses it as a commit id (for my case it’s aeaa56e). This is the short version of the commit id. Type git log command to get the full id.
Activity: Another activity! Modify the file and tell Git to track the file. Commit your changes with meaningful messages. Type the git log command. You will get different information now. See how the Git commit id changes? And can you identify your comments?
Sync with remote repo using ssh
Let’s see how we can sync our local changes to our remote repo. You can upload your file in GitLab using ssh or using https. In this post I’ll show you how you can upload your file in GitLab using ssh. We will generate a ssh key and upload the key in GitLab.
Type the following command and press return in your workstation to create the ssh key.
ssh-keygen -t rsa -b 2048 -C "My SSH Key for gitlab"
Accept the default location of the key by pressing return. After that it will ask for the passphrase. You can give a passphrase for your key or you can simply leave it empty. Press return and you will find your key in the .ssh folder of your home directory.
It’s time to upload the key in GitLab. Go to gitlab.com and log in to your account. Click on the avatar (right side of your screen) and click on settings. On the left side of your screen click on the “SSH Keys” section. Here you can upload your key. Copy the content from the .ssh/id_rsa.pub file, which is your public key, and paste it here in the key field. Click on the “Add key” button. Your key will be added in the GitLab.
Now we are ready to push our local repo to our remote repo. Go to our local repo and type the following command to make the connection between our local and remote repo:
git remote add origin git@gitlab.com:YOUR_USER_NAME/net_prog.git
Let’s make a push now. We will use the git push command for that. Before that make sure you have no untracked files in your local repo. Type git status and press return. The output should be as follows:
On branch master nothing to commit, working tree clean
Type the following command and press return:
git push -u origin master
Type “yes” and press return. It will ask you the passphrase of the key. If you have any, type it and press return. If not, simply press return. After that you will see an output like the following (size and counting objects may vary in your case).
Counting objects: 6, done. Compressing objects: 100% (2/2), done. Writing objects: 100% (6/6), 429 bytes | 429.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To gitlab.com:YOUR_USER_NAME/net_prog.git * [new branch] master -> master
Go to your remote repo. You should see all your files are uploaded there. Now the connection between our local and remote repo is done. You can now do your work and when you want to upload the file in your remote repo just push it.
Activity:
- Make a new file in your local repo.
- Make some modification in that file.
- Commit the file with some meaningful messages.
- Push the file in your remote repo.
What’s a branch?
Now our automation project is running, we need to add some extra features. Usually we’d make a copy of the full project or make a copy of our scripts, file/folder. As a result, the number of files increases in the disk.
In Git, by creating a branch, we can simply make a reference to a specific commit. After creating the branch you will get exactly the same environment as the original one. You can edit files in that branch, make commits and push that commit in the remote repo if required. Your main running code will be untouched. When you finish your changes and do all the testing, you can merge that branch in your current running version of the code with the added feature.
Let’s do it step-by-step so it will be clearer to you. In this section we will see how to:
- Create a branch
- Do the editing in that branch
- Merge that testing branch to our main work, and finally
- Delete that branch
On master branch
By default every Git repo starts with a default branch name master. If you type git status in your local repo the first line will be as follows:
On branch master
This means you are in the master branch. Type the following command to see the list of the branches in your current project.
git branch * master
We only have one branch in our current project and that asterisk means you are in the master branch. Let’s create a branch now.
Creating a branch
To create a branch name dev, type the following command:
git branch dev
To see the branch, type git branch command again. The output should be like that below:
dev * master
The asterisk sign means you are in the master branch.
Switch between branches and modify files
Now we have two branches named master and dev. For working purposes we need to switch between these branches. As of now we are in the master branch. To go to the dev branch type the following command in your local repo:
git checkout dev
The output should be as below:
Switched to branch 'dev'
You are now in the dev branch. In this branch we will do all the new testing for our automation project.
Let’s create a file called file3 and add some text in that file and commit your changes. Remember you are in the dev branch.
Now if you make a simple ls command in your terminal, you should see file3 in the list. Go back to the master branch and type the same ls command. You will see in branch master no file3 exists. That’s because we do all our changes in the dev branch and all the changes are available in the dev branch. So, if I run my production code from my master branch, changing them in the dev branch won’t affect my project.
Now if you’re done editing your dev branch it’s time to merge the changes in the production branch in the master branch.
Merge branch
To merge the changes in the master branch we need to be in the master branch. To navigate, type the following command:
git checkout master
Now you are in the master branch. Type the following command to merge the content of the dev branch in the master branch:
git merge dev
The output should be like the one below (the value may vary in your case).
Updating 14daf98..c706dc3 Fast-forward file2 | 1 + file3 | 0 2 files changed, 1 insertion(+)
create mode 100644 file3
All the changes from the dev branch are now merged into the master branch. If you type ls, you will see file3 is now available in the master branch.
Type the following command to make your changes available to the remote repo:
git push -u origin master
Go to your remote repo and you will find the updated files.
Team collaboration with merge request
So far, you have been the only one working on this project. Now imagine your other team member (who has a GitLab account) wants to work with you on this project. In this section we will see how other team members can start working on this project.
In your remote repo you need to invite your team member. Log in to your account and click on your project. In our case it’s net_prog. On the left hand side, click on “Members”. From here you can invite your team members.
Type the username of your team member. Once found, select the name and assign the role as a “Developer”. Choose the access expiration date. Finally, click on invite. The user can now start working on this project. When your team member logs in to their GitLab account they can see the project.
Local repo for your team mate
As you already know, Git is a distributed version controlling system. This means a project can have multiple local copies with their own history and commit.
To start working in a project, first you’ll need to clone the repo locally. (You need to set up the ssh key before making any clone or push to the private repo. You can follow the Sync with remote repo using the ssh section for the configuration. Also don’t forget to tell Git your name and email address with the git config command).
To get started, type one of the following commands to clone the repo:
git clone git@gitlab.com:<USER_NAME>/net_prog.git
Or
git clone https://gitlab.com/<USER_NAME>/net_prog.git
After that you will find a directory called net_prog in your current directory. This is your local project. The best practice after cloning the project is to make a branch and start working on that branch. While working you may need to make several commits. Do all your changes in that branch, and once finished, push your branch to the remote repo by typing the command below.
git push -u origin YOUR_NEW_BRANCH_NAME
Remember this push is done by your team mate (ex: user Y), not you. Now go to your (User Y) remote repo. Click on your project name. You will see a message telling you that you have pushed a new branch, and asking if you want to create a merge request? Click on the “create merge request” button.
After that you will be redirected to the “New Merge request” page. Fill out the information and assign the job to your other teammate, such as user X. Click on the “submit merge request” button. The moment you submit the request the assigned member (User X) will be notified through email that user Y created a merge request.
Accept the request (user X)
When User X logs in to his/her GitLab account, he/she can see the merge request notification. When they click on the request they will be redirected to the merge request detail page. From here they can get an overview of the changes, see the commit and the actual changes made by user Y of the code. Once verified they can modify the request or they can accept the changes by clicking on the “merge” button. The code will be merged into production and will be available in the master branch.
Receive the changes (user Y)
The new features/updated code is available in the master branch of the remote repo. It’s now time to pull that request in the local repo. Switch to the master branch and type the following command to pull the latest code:
git checkout master
If you haven’t pulled your changes you will get a notification when you get in the master branch like below:
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
(Use “git pull” to update your local branch.)
Type the following command to pull the latest code:
git pull
Deleting branches
All your changes are now available in the remote repo and also in your local repo. If you need to delete the branch from your local repo, type the following command:
git branch -d YOUR_BRANCH_NAME
Summary
In this post I’ve shown you the basic usage of Git. Once you are familiar with it you can explore more advanced Git features like fork, merge conflicts, cherry pick and rebase.
If you have plans for deploying automation/orchestration/SDN type technology in your environment, you have to deal with the codes/files, or you have to make sure of the code version running in your production. All these things can be easily and efficiently maintained by Git.
Explore GitLab if you need to share your work with your team members or want to know about the changes happening in your code instantly through email or Slack messages.
Imtiaz Rahman works for a financial organization in Bangladesh. He has experience in system, network and security administration.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.