Changes between Initial Version and Version 1 of RepositoryGuidelines

Timestamp:

Feb 26, 2010, 10:36:50 AM (15 years ago)

Author:

FrederikHeber

Comment:

First explanation about using the git repository on Jupiter.

RepositoryGuidelines

@@ +1 @@
+=== 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://.../
+}}}
+
+= ... 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 yourself branches thereto!''' (except of course you are the administrator :).
+