How to use the Repository on Jupiter

In this page we describe how to get access, the first thing you have to do (clone the repository) and how one should usually proceed to exchange new versions.

Getting access

In order to get access, you have to create a ssh-key and ask the system administrators to install it on the web server. They can assist you in creating it. Remember the secret pass phrase that you have to enter and don't give it away!

Cloning

The very first step on your local computer is as follows

git clone git@jupiter:espack.git

This will ask you for your passphrase and will then count some objects, transfer them and after this you will find a new directory espack with some files and a sub folder .git in there.

The second important step is to create your own branch to work. One important thing to understand about the version control system git, is that each of the coders has its complete own repository. There is basically no central instance. Jupiter just serves as another repository where we know that no changes to the code will appear (it is also marked as a bare repository). Hence, a branch that exists on Jupiter has nothing to do with branches of code on your computer (or harddrive rather). That's why we have to create a new branch: enter the espack directory and there type in the following

git checkout <branch> -b <newname>

where <branch> is the name of the branch on jupiter and <newname> is the name of the branch you may choose as you wish.

Note that by entering

git branch -a

you may inspect all the branches there. The switch -a shows you all branches, all local ones and all remote ones that your git repository knows about. Remote ones are those on other computers, they are usually prefixed with origin/ or something alike.

Coding

As you start coding in your new branch, from time to time commit! Committing often is very important! If possible try to dissect your changes to the code in tiny steps, such that each step can be compiled successfully and afterwards committed. The dream world would be that every commit is both compilable and all unit tests run fine. The latter may be disregarded if needs be, but successful compilation is a must!

See the additional information in this [Wiki ​http://wissrech.ins.uni-bonn.de/inside/wikka/Git] for how to daily use git.

Exchanging versions …

Parts of the code that have been implemented and tested successfully have to be broadcast to others. There are two ways to do this.

... between users

This is easy if your computers reside in the same network (i.e. wiss-stud), just tell your colleague that he should pull one of your branches as this

git pull ssh://adamantium:/home/<user>/<path>/ <name>

where <user> is your name and <path> the path to your local espack code and <name> finally is the name of your branch.

It is however safer to proceed as follows:

1. Setup a remote by giving git a shorthand of the above "​ssh://.../" line, where <friend> should be a suitable name of your colleague as shorthand reference.

   git remote add <friend> ssh://.../
   

2. Use the remote to fetch all remote branches.

   git fetch <friend>
   

3. Merge the obtained remote branch <remotebranch> with one of yours, here called <yours>.

   git checkout <yours>
   git merge <remotebranch>
   

Note that git pull performs the fetch and the merge in a single step.

... with the jupiter repository

Here, you tell the repository administrator that he should pull one of your branches in the same manner as above. He will check your code and if it is fine, push it onto the jupiter repository. Note that you should never ever push branches by yourself thereto! (except of course you are the administrator :).