Git – Version Control

In the previous article in this series on version control we provided an overview of the concept and explained some of the benefits of using it. In this article we will take a look at one of the most popular pieces of software for managing version control – Git. We will look at the core concepts that Git involves and how each fits into your development workflow.

Git Overview

Git is a piece of software that runs on your device to manage the version control of files in a specific folder. This is done by creating a repository in the folder that you want to apply the version control to. The repository tracks and saves each change that is made to the files that it is tracking. You can determine which files you want it to track and which you want to ignore. You can use branches to maintain different versions of a file. All of the the files sit in a working directory where they can be modified or developed. To update the repository with the changes you made to a file you first need to add it to the staging area and then commit them to the repository. This will update the repository with the latest version of the file.

Repositories can sit on your local device. A more common approach is to also have the repository stored online in a remote repository. These are typically held by services such as GitHub or GitLab. With this approach you need to push the committed files to the remote repository for them to be stored there.

We will discuss each of these concepts in this article and in future articles.

Repositories

Repositories are the central point for tracking the desired files. They are set up on a folder and can also track folders within this folder. A repository should be set up for each project or distinct document. If you have three different, separate pieces of software that you are working on, each piece of software should have its own repository. If you are writing two separate books and want to control their versioning, create a separate repository for each book. The files that are held in a given repository should all be related to each other in some logical way.

Branches

Each repository will start with an initial branch, which is usually called main. This is where the current version of your files will be tracked. Sometimes you may want to make some changes to a file, such as adding a new feature to a piece of software, but you are not sure if you will want to keep the changes. For this you can create a new branch where you add this new feature. You could call this branch new-feature. You would create this branch with the current state of the files in main. While working on the new branch, any changes made to the files will not affect the files on the main branch. This allows you to try out changes without affecting your main branch which is your current ‘good’ version of the files.

You can setup branches for specific features, for trying out changes you are not sure if you will keep, or to work on your documentation separately from your source code. The image below shows a repository with three branches, a main branch, a documentation branch and a branch for making changes to the app. Note that as this is an older repository it has master for its main branch. The convention now is to use main instead.

Working Directory

The working directory is the folder that holds the files you are working on. This will likely be a folder on your device where you hold the individual files:

The files that you are working on, which the repository could track, will be in this working directory. A working directory is basically a folder. Inside the folder shown above is a hidden folder .git. This is the repository. You can see it here as I have hidden files shown. Any files that you add to the working directory will be considered untracked until you tell Git to track them. Note that the working directory can change when you change branches. If you add a file on the new-feature branch, and then move back to the main branch, you will not see the new file in the main working directory unless you merge it in.

Tracking files

Git needs to be told to track a file for it to be able to manage the file’s version control. Git will then know the state of the file and will be able to identify when changes have been made to the file. Note that the file will only be tracked on the specific branch that you track it from. If you move to another branch you will need to tell Git to track the specific file again. Once a file is tracked you can have Git tell you if changes have been made to the file and you can also revert to an earlier version of the file if you do not want to keep those changes.

Staging area

The staging area is where files that have been changed are placed prior to committing their changes. You can also track a file that is not currently being tracked by adding it to the staging area. So there are two reasons a file may be in the staging area:

• It is a tracked file that has been modified
• It is an untracked file that has been added so it can now be tracked.

You will work on each file in the working directory as required. When you want to take a snapshot of the current state of the tracked files you will first add them to the staging area. Any new files you want to track you also add to the staging area. You are now ready to commit these files.

Commits

When you make a commit a snapshot is taken of each of the files that currently sit in the staging area. This snapshot will sit on the branch that you are currently working on. The repository will hold this snapshot and in future you can revert one or more of the committed files to the version in this snapshot. After making the commit the files will be removed from the staging area. It is a good idea to make a commit each time you make a change to a file such as adding a new function or fixing a bug. Making regularly commits gives you greater flexibility when trying to undo changes and a more detailed history of the state of the files.

Pushing Commits

The commits made above will be made to your local repository which sits on your device. You will likely have a remote repository which will be stored in the cloud. There are three main benefits to remote repositories:

• It is a form of backup in case your local device fails (the repository and all your commits are still available in the remote repository)
• You can work on the project on multiple devices by pushing your commits and then pulling them to another device
• You can collaborate with others on a project by working with a shared remote repository.

You push commits by telling Git to update the remote repository with the commits that you have made. It is not necessary to push changes after every commit. A more usual approach would be to make commits after each distinct change to a file and to push these commits at the end of your working session. This may mean pushing changes once per day. You want to ensure that after each session your changes are pushed to the remote repository so they are available for you next session – very important if you are working on the same project across multiple devices!

Summary

A repository contains all the information required for managing the version control for files in a project you are working on. Files are tracked for changes and added to the staging area when they are ready to be committed. Committing the changes will create a snapshot of the files in their modified state. Different branches can be used to make parallel changes to the same file or files. At the end of your session you should push your files to a remote repository to provide a backup and allow you to work on the project on a different device.

This article has provided an overview of the core concepts for using Git. In future articles we will look at how you perform the actions associated with these concepts.

• 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