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
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
So, when you do this:
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.
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):
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
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:
which, would add any files that you wrote within the directory structure to the staging area of the project.
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
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
You can see the captured output from all of these commands in Figure 1 below.
Figure 1 - git status, git add and git commit
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:
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.
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:
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.So, for example, I want to create a new branch called “DerekBranch” I can create it using
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:
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.
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.
If we want to delete a branch we can do so using
Figure 12. Deleting the branch
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:
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)