Skip main navigation

What are Branches, Tags and Repositories?

This step describes the difference between branches, tags and repositories. Interpreting the graph correctly allows you to quickly get a handle on potentially complicated projects.
© The University of Manchester

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

Diagram of a Git graph showing a simple vertical graph with three branches

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.

Diagram of a Git graph showing a simple horizontal graph, a node and its two children are highlighted

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.

Diagram of a Git commit showing a tag

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.

© The University of Manchester
This article is from the free online

Collaborative Coding with Git

Created by
FutureLearn - Learning For Life

Our purpose is to transform access to education.

We offer a diverse selection of courses from leading universities and cultural institutions from around the world. These are delivered one step at a time, and are accessible on mobile, tablet and desktop, so you can fit learning around your life.

We believe learning should be an enjoyable, social experience, so our courses offer the opportunity to discuss what you’re learning with others as you go, helping you make fresh discoveries and form new ideas.
You can unlock new opportunities with unlimited access to hundreds of online short courses for a year by subscribing to our Unlimited package. Build your knowledge with top universities and organisations.

Learn more about how FutureLearn is transforming access to education