Git way – IV

This would be the last post in the series of Git basics or Git way where we would fork a repository, clone it, sync it with upstream and issue pull requests.

First up, what is a fork. In the English language, a fork means choice. ‘A fork in the road’ is when you come to a place where the road splits into two and you have a choice of taking whichever road you want. You have no idea whether the road would become a dead-end or it will help you in your journey. In software development, it’s something similar with the exception that it is a software developer or groups of software developers who are either unhappy with the state of development in software, or they feel they are not being heard or are unhappy with the person who’s leading the development model or any permutations and combinations of reasons which are at work in a group dynamic activity.One of the first forks in the Free software world can be looked at XEmacs and GNU Emacs . The Wikipedia pages linked have more than enough data/knowledge about why the fork happened.

Similarly, in you can fork any repository. As forking the word has negative connotation, uses the world clone. You can go into any repository and if you are signed in on the upper right-hand side corner, you will see three choices, Download, Watch and Clone. Click on Clone. To use a specific example, let’s use the 2014-mirror where the code for the minidebconf in Kollam is happening. I clicked on Clone to make a new cloned repository called shirishag75s-2014-mirror . This mirror is up-to-date with the original repository at this point in time.

Now the clone mirror is up in the Cloud, which means the instance/repository is still lying in Gitorious server. The first thing I need to do is clone the repository to my desktop or laptop or whatever device I’m using just as before. The command here would be :-

~/games$ git clone

Once the clone is downloaded it will show as :-

~/games/shirishag75s-2014-mirror$ ll -h
total 4.0K
drwxr-xr-x 5 shirish shirish 4.0K Sep 1 17:01 website

The ‘ll’ is actually ls -l . I have shortened it for my own convenience. The first thing we have to do is actually we need to make sure that we don’t miss any updates from the original repo. For that to happen, we need to tell git that there is more than one repository that we need/want to keep a watch on. We do this by the command git remote.

First we run the command git remote -v and see what it shows :-

~/games/shirishag75s-2014-mirror$ git remote -v
origin (fetch)
origin (push)

The command shows that it knows that there is a repository called shirishag75s-2014-mirror, shows the address and tells that we have the permission (as we are the owners of that repository) to both pull data and push data to that repository as well.

The next thing we have to do is to tell git to add another remote by the name upstream.

$~/games/shirishag75s-2014-mirror$ git remote add upstream

Once this is added, we should again look at the git remote scenario :-

~/games/shirishag75s-2014-mirror$ git remote -v
origin (fetch)
origin (push)
upstream (fetch)
upstream (push)

Once this is done, you can do commit to your repository and fetch updates from upstream. Just when you are pushing or making any commits to your repository make sure to run the ssh-agent before committing to your repo.

$eval "$(ssh-agent -s)"

Once this is done you can commit to your repo. If you do any changes and want to include your changes you have to put up a request merge upstream. Whenever you or anybody else commits to a repo. that commit is known by a hash internally by git. You can see what git commits have been done and their hashes by using the command :-

$ git log | less

This will produce output something like this

$ git log | less

commit 8e144ba96e16560dbb8d531a9d4f33c858d94dfa
Merge: aff18e0 83dd29a
Author: Shirish Agarwal <>
Date:   Tue Sep 2 00:25:54 2014 +0530

Merge remote-tracking branch 'upstream/master'

commit 83dd29aa9d2b161a273a9913f995ff848324cf68
Author: Praveen Arimbrathodiyil <>
Date:   Mon Sep 1 20:33:59 2014 +0530

correct logo

The above shows the commit hash, who was the author of that commit , when was it committed and what was the commit about. You can even take a sneak-peak at one of the commits, just use the first 8 letters of the hash and it will show. For e.g. :-

~/games/shirishag75s-2014-mirror$ git show 8e144ba96e
commit 8e144ba96e16560dbb8d531a9d4f33c858d94dfa
Merge: aff18e0 83dd29a
Author: Shirish Agarwal <>
Date: Tue Sep 2 00:25:54 2014 +0530

Merge remote-tracking branch 'upstream/master'

This was me just merging upstream to my repository .  Doing that is simple. There are three commands you need to do one after other :-

~/games/shirishag75s-2014-mirror$ git fetch upstream
~/games/shirishag75s-2014-mirror$ git checkout master
Switched to branch 'master'

~/games/shirishag75s-2014-mirror$eval "$(ssh-agent -s)"
Agent pid 4179

~/games/shirishag75s-2014-mirror$$ git merge upstream/master
Already up-to-date.

~/games/shirishag75s-2014-mirror$ git push origin master
Enter passphrase for key '/home/shirish/.ssh/id_rsa':
Everything up-to-date

The first command just fetches if any changes have happened in the other remote (upstream) that you have shared. You can have multiple remotes depending on your scenario but as this is the basics I have just two, my own and the original/upstream repo.

The second command switches you to your repository master branch and tries to see if there are any updates to it.

The third command you ask ssh-agent to be in the background so that authentication and communication between the public and private key can happen once the passphrase has been told/shared and the passphrase is right.

The fourth command you just try to merge the two repositories. The best way to merge is to make sure that you are always synced with upstream and communicate with upstream that this is a change you will be working on to have least merge conflicts. There are other ways and means in which merge conflicts can be avoided but for now we are not going to discuss those. As can be seen there has not been anything new either in the upstream as well as I haven’t done any changes hence it says Already up-to-date.

Last command you are pushing whatever changes happened in upstream to your repository. While you can automate that the passphrase is entered for you every time, as a beginner, it’s always a good habit to do it manually so you are aware what you are doing.

Lastly when you want to put up a merge request, click on Request Merge on your repo. A new page will open up which will ask you things like which target repository you want to put a request merge for, which commit you want to add as a merge request, you will be asked to give a summary and a Description. Adding all that and clicking on Create Merge Request will show a merge request in the parent/original/target repository.

You might have noticed that in the git log I have shown, whenever I am merging between upstream and master it shows a separate merge hash as well to indicate that something unique happened.

This concludes the last part of git basics or git way. In some future scenario, we may go for some more complex scenarios and ways they are tackled. I hope this series of posts gives impetus to people to try out git and if possible also help us in improving the website for the minidebconf being held in Kollam next month.

Till l8er.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.