Version Control – Git Command Line Tool

Git is a piece of software that allows you to manage the versioning of files. In this article in our Version Control series we will look at the Command Line Tool that comes with Git.

Git Tools

There are two main ways to work with Git – via the Command Line Tool and the Git GUI. The Command Line Tool requires you to type instructions into the Console whereas the GUI tool allows you to use drop-down menus and click buttons. Which you use will be a personal preference (I almost exclusively use the Command Line Tool). For people that are learning to use Git my recommendation is to take the more difficult path and start by using the Command Line Tool. You can see the two tools side by side below.

Why use the Command Line Tool?

Git has a GUI tool that can be used to perform many of the actions you would want to take using Git. We will look at this tool in a future article. I strongly recommend that you begin by using the Command Line Tool, even if you are not comfortable working at the Command Line. My reasons for this recommendation are as follows:

• You will become more comfortable using the Command Line, which is a good skill to have
• You have more control over what you are doing
• You are working more closely with the functionality of Git as the GUI adds a layer between you and the software
• You develop a deeper understanding of how Git works and what is happening with the files you are working with.

The last point is the most important. Working with the Command Line Tool will give you a much deeper understanding of how Git works and what you can do with it. You can experiment with different commands and can examine the output. Using the GUI from the start will bypass a lot of this learning so I strongly recommend starting with the Command Line Tool, even if you intend to move to the GUI tool for day to day use.

Orientation

The image below shows the Command Line Tool when run in the project folder we set up in the previous article. I have customised the colour scheme so it may look different to yours but the components will be the same.

The first line contains the following components:

• Jeff (in red font) is the name of the user account in use
• (main) is the name of the branch that is currently in use. Any changes will be made to this branch
• Contracting_Expenses_Calculator is the name of the repository that is currently in use.

The second line starts with a $ sign. This is where you type in your commands. You can see that I have typed in git status which will return the current status of tracked files in the current branch within the repository. The output is shown in white font on the next few lines.

The Status Command

The status command (git status) is a command that you should use often. It will tell you the current status of all the tracked files, any files that have been added (but are not being tracked) and if you have any staged changes waiting to be committed. You should regularly use this command to check the current status of your repository. It is also a good idea to run it after performing an action, such as committing changes, to check that the action was performed successfully.

Adding Files

Currently our project folder only has the files we set it up with (the .gitignore file and the README file). We can add a python file which we will be writing our piece of software in. After adding the file our project folder looks as follows:

Running the git status command again we can see that Git has identified that the main.py file has been added to the project folder but we are not currently tracking it. This means that any changes we make to main.py will not be held by Git and we will not have any version control over the file. You can see main.py listed under Untracked files: in red font.

We can add the file so that Git starts tracking it using the command git add main.py. After doing so a + sign appears after the branch name telling us that a file has been added to the staging area but has not yet been committed.

Running git status again now shows that there is a new file to be committed. This appears in green font.

We can commit this change using the command git commit -m ‘Added main.py’. This will move the new file from the staging area and commit it. Git will now be tracking any changes we make to the file. Git returns a message telling us that one file was changed. As it is a new file no data was added (insertions) or removed (deletions). As the changes have been committed the + sign has been removed from the branch name.

Editing Files

One of the key uses of version control is to track changes made to files. If we make some changes to main.py and save the changes, Git will track those changes but will not do anything about them until we tell it to. After saving the file and running git status we get the following output:

Let’s breakdown what Git is telling us here:

• Our branch is ahead of ‘origin/main’ by 1 commit
  • We have made one commit locally but we have not yet pushed this to our remote repository, so we are ahead by 1 commit
• We have made changes to main.py but we have not yet staged them (‘Changes not staged for commit:’)
• main.py has been modified. It is in red as we have not yet added the changed file to the staging area
• The branch name has an * after it as we have made changes to a tracked file but not yet added those changes to the staging area.

Wow, that is a lot of info to take in. We want to add these changes so we keep a track of them. We do this using the git add and git commit commands we saw earlier. After running these two commands we get the following output:

Here we see that 1 file was changed and two lines of code were added (2 insertions(+)). If we were to run git status again we would see that we are now 2 commits ahead of origin/main (the two commits we have not yet pushed).

Pushing Changes

The last command I want to introduce in this article is the pushing of commits to the remote repository. Currently the changes we have made are tracked in our local repository. We want these to also be tracked in our remote repository. This allows us to access these changes from another device and to keep a backup of the changes in case something happens to our local device. We do this from the Command Line Tool by using the push command. For this we will use the command git push origin main. This pushes the changes we have committed on the main branch to origin, which is the shorthand we used for our remote repository.

After running the command we get the following output:

And after running git status we see that our branch is up to date with the remote repository:

Summary

Using the Command Line Tool for Git is a great way to learn how Git works and to be clear on what is happening with your files as you edit them. I strongly recommend that you start off using the Command Line Tool as you develop your capabilities with Git. In this article we looked using the Command Line Tool to add a file, check the status of a file, commit changes to a file and then push these changes to our remote repository. In the next article we will look at using the Git GUI to perform the same actions.

• About
• Latest Posts

Jeff Mitchell

P&C Reporting and Data Analyst at Fisher & Paykel Appliances

Jeff is passionate about the role of learning and development, and has a specific interest in how people and organisations can be developed in order to achieve their potential. Jeff has a keen interest in information technology and specifically data analysis and the e-learning space.

Latest posts by Jeff Mitchell (see all)

• Version Control – Git GUI – 7th March 2023
• Version Control – Git Command Line Tool – 7th February 2023
• Version Control – Creating Repositories – 7th January 2023