11.2 Git

What is Git?

Git is a version control system that allows you to track a project and any of its associated files as it develops over time. Importantly, you can can create parallel developments that do not affect the original, you can revert to an older version of one of its files or an older version of the entire project if required. This is particularly useful in large-scale programming projects where you can go down a pathway with the project that is unsuccessful. It is also very important if you have several people working on the same project.

We call the project with its associated files and history a repository. We call a different version of your project a snapshot. Git is written in C and came from the need from version control tools in the development of Linux Kernel code. It is used by many other open-source developments such as Eclipse, Android etc.

In my notes I have used github.com. There is nothing to stop you installing your own git server - If you do, I would recommend http://gitlab.org/ or http://getgitorious.com. Github gives a really nice web interface to the repository that I find very useful in my notes

The repository of code for this module is available on github at the address: 


The discussion that follows is a practical summary of the features of git; however, there is a really excellent reference on Git at: http://git-scm.com/book

Distributed Version Control System

Git is a distributed version control system, which means that you don’t need a single central server to manage the project. Each user can clone the repository

Cloning a Repository

So, when you do this:

git clone git://github.com/derekmolloy/ee402    


git clone https://github.com/derekmolloy/ee402

you are creating a full copy of my repository, with the latter form being more secure in case of a man-in-the-middle attack.

Your repository is now just as complete as the version on the Github server and if you were to deploy it over a network, file system, other git server, or even on a different Github account it could easily take over the role as the main version of this repository. While there no need for a central server, it is usually the case, as it allows multiple users to check in source to a known original repository. Ideally the git server would be always online.

Getting the Status

Here is an example, where I added 5 files to the local repository by adding them using Windows Explorer (i.e. copying them into the ee402 directory on the C:\ drive as below). The files are now in what we call the working tree, you can see the message says there “are untracked files present”. The output (using Windows power shell):

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master +5 ~0 -0 !]> git status

# On branch master

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)


#       notes_examples/chapter10/GenericsTest.java

#       notes_examples/chapter10/SortingObjects.java

#       notes_examples/chapter10/Student.java

#       notes_examples/chapter10/StudentIDComparator.java

#       notes_examples/chapter10/StudentNameComparator.java

nothing added to commit but untracked files present (use "git add" to track)

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master +5 ~0 -0 !]>

You can see the ‘!’ sign in the prompt and in the figure you can see that the ‘5’ is in red. The next step is to add these changes to the staging area using the git add command. 

Adding to a Repository

Once you have a local version of the repository you can then perform local operations on the repository, for example, if you cloned the ee402 repository and decided that you wanted to add your own examples you can simply add files to it.

Here I am adding all changes from the working tree to the staging area:

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master +5 ~0 -0 !]> git add *

which, would add any files that you wrote within the directory structure to the staging area of the project.

Commiting to the staging area

Once we have added the files to the staging area, we can then ‘commit’ the changes from the staging area to the local git repository - we commit them permanently to the local git repository using git commit

In my case, the changes will be flagged with my username and a message is required. If you want to do this inline you can use -m “the message” to set the message:

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master +5 ~0 -0]> git commit -m "a

dding generics code"

[master aa821fc] adding generics code

5 files changed, 119 insertions(+)

create mode 100644 notes_examples/chapter10/GenericsTest.java

create mode 100644 notes_examples/chapter10/SortingObjects.java

create mode 100644 notes_examples/chapter10/Student.java

create mode 100644 notes_examples/chapter10/StudentIDComparator.java

create mode 100644 notes_examples/chapter10/StudentNameComparator.java

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master]>

You can see the captured output from all of these commands in Figure 1 below.

Figure 1 - git status, git add and git commit

Pushing to the Remote Repository

If you had access to the remote repository you would be able to push the changes that you made to my repository on github.com. In my case, I have an account on Github with a username and password, so knowing this information I can simply use:

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master]> git push

Counting objects: 12, done.

Delta compression using up to 8 threads.

Compressing objects: 100% (9/9), done.

Writing objects: 100% (9/9), 1.97 KiB | 0 bytes/s, done.

Total 9 (delta 2), reused 0 (delta 0)

To https://github.com/derekmolloy/ee402.git

  2873672..aa821fc  master -> master

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master]>

You can see it uses https to communicate to github.com (as in Figure 2)

Figure 2 - pushing to the remote repository

It will prompt you for a username/password and if you are a user that is registered to make changes to the remote repository then you would make changes to the remote repository.

Updating other clones after a push

These changes are now commited to the remote repository. So, if I make changes to the repository during the semester then you can update your local repository to reflect those changes by typing:

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master]> git pull

Already up-to-date.

C:\Users\Derek Molloy\Documents\GitHub\ee402 [master]>

from within the local repository directory. In this case everything is up-to-date.

To delete a local repository you simply delete the directory.


Git supports the concept of branching, which allows you to work on multiple different versions of the set of files within your project. So, if you wanted to develop a new feature in your project, but also wanted to maintain the code in the current version, you can create a new branch for the new features and changes to the code there will not affect the current version. You can then switch between branches easily.

Creating a Branch

So, for example, I want to create a new branch called “DerekBranch” I can create it using git branch DerekBranch and then I can switch to that branch using git checkout DerekBranch as in Figure 3.

Figure 3 - Creating a new Branch

Now, I add a temporary file to the repository called test.txt using Windows Notepad and saving the file in my ee402 directory in the c:\ drive at the path below in Figure 4. In Figure 5, you can see that the status of the branch makes it clear that there is an untracked file

Figure 4. You can see the "test.txt" file in the directory (git on DerekBranch)

Figure 5. Getting the status on the branch

In Figure 6 you can see that I now add the untracked file to the staging area and then I commit it permanently to the DerekBranch of the repository. This change will affect the DerekBranch branch, but will have no effect whatsoever on the master branch.

Figure 6. Adding and Commiting to the DerekBranch

This can be seen when I now switch back to the master branch by using the command: git checkout master as in Figure 7.

Figure 7. Returning to the master branch

And you will see that there is no mention of the test.txt file being missing, in fact it has been removed from the git repository directory and is hidden inside the .git/objects directory as a change. In fact, in explorer “test.txt” has just disappeared (as can be seen in Figure 8).

Figure 8. test.txt has just disappeared!

However, it is not gone of course, if we switch back to the DerekBranch using git checkout as in Figure 9, you will see that the file now re-appears as in Figure 10.

Figure 9. Switching back to the master branch

Figure 10. The test.txt file has now re-appeared!

You can see just how well integrated the branching system is. At this point we can go back to the master branch and make changes to the original code without the changes in the DerekBranch branch having any effect on the master code. Even if we change the code in the same file it has no effect on the original code in the master branch.

Merging the Branch

So, what if we want to apply the changes we made in the DerekBranch to the master project, then we can just use git merge as in Figure 11.

Figure 11. Merging the branch

And now in explorer the same test.txt file is now present in the master. You can now see that my local repository is ahead of the master (on github.com) by 1 commit.

Deleting a Branch

If we want to delete a branch we can do so using git branch -d DerekBranch as in Figure 12.

Figure 12. Deleting the branch

Integrating Git/Github with Eclipse

There is a comprehensive set of tools for using git/github from within Eclipse directly. This can be useful if you are using git/github on an ongoing basis:

  • In Eclipse, go to help -> install new software
  • Go to Work with and select "Kepler ... " - the path is displayed in Figure 13.
  • In the filter text I typed git
  • Choose Collaboration
  • I chose Kepler GitHub integration from the list below (Figure 13) and installed it.
Figure 13. Installing the Tools within Eclipse

Once it is installed you can open the window, but going to Window->Show View->Other, pick Git and then Git Repositories. You can see the window that appears in the bottom left-hand side of Figure 14 below. You can add your Github settings and then push and pull to your remote repository from the comfort of Eclipse.

Figure 14. Git Repository view within Eclipse (click to maximise)

These notes are copyright Dr. Derek Molloy, School of Electronic Engineering, Dublin City University, Ireland 2013-present. Please contact him directly before reproducing any of the content in any way.