What are Branches, Tags and Repositories?

This step describes the difference between branches, tags and repositories.

Branches

Interpreting the graph correctly allows you to quickly get a handle on potentially complicated projects. For instance, you can see that two different versions of the software “branched” out after the commit that included an update to the netcode. This means both versions include this update. Each branch has a unique name (which should, ideally, inform you of the branches purpose).

Here is a version of the graph in a horizontal arrangement.

In this graph, commit “b” is the first commit on the [add-clothes-shop] branch. Commit “c” is the first commit on the [add-waiting-room] branch. Both have “a” as their parent commit. This means that both “b” and “c” represent changes made to the version of the project represented by “a”.

Since changes made on a branch do not affect any other branches, the addition of an empty shop which was committed on the [add-clothes-shop] branch (the blue branch) will not be contained in the [add-waiting-room] branch (the yellow branch).

If you look at the “Include more bot responses” commit, you can see that it is based on the “Add text parser” commit, which is based on the “Update netcode” commit and so on, all the way back to the initial commit.

Looking at the commits on the [add-clothes-shop] branch (the blue branch) you can see that none of them are based on the “Add text parser” commit, which is on another branch. Therefore there will be no text parser in any of the versions of the software represented by the commits on the add-clothes-shop branch.

Tags

The graph also depicts a “tag”. A tag is a simple pointer to a commit. There is a tag on the commit where a username bug was fixed. The tag name is “v1.0”. Presumably, this commit represents the initial release version of the software. It is common to tag release versions this way. However, tags can be named anything and point to any commit so they are very flexible.

Repositories

The entire codebase including all of the information required to show and play back the history of changes is held in a virtual storage area named the repository. If you are working on a project which is stored on your local machine it is referred to as a local repository.

Although it might be possible to send your local repository to a colleague who is also working on the project, there would be many disadvantages to doing so. Imagine how complicated things would quickly get with multiple repository versions being sent between team members, each with different changes contained within them.

This is exactly the type of problem which Git and version control is designed to overcome!

Remote Repository

There are several ways which Git can facilitate collaborative working, many of the methods involve using a remote repository. A remote repository is usually hosted on a machine which is accessible to all members of the team. Team members can access the remote repository to make a copy of the project on their local machine. Since each team member can now work on their local repository, they can work simultaneously without impeding each other’s work.

Some hosting services such as GitHub, GitLab and BitBucket have been developed to host repositories which are accessible over the internet. Services such as these can be used to easily provide a remote repository for a project, so they have become very popular and almost synonymous with Git. However, it is important to note that using services such as these is not strictly necessary. There are other ways to deploy a remote repository and often a single, local Git repository is a perfectly valid choice for a project, depending on its scope and development plan.