Git Repository Hosting


All BFH users can request repositories on </servers/>.

Access to Git repositories can be managed by the respective creator of the repository (see below). If the creator decides, he/she can make a repository accessible anonymously and read-only through the Internet (by default all repositories are accessible by their creator only).

Read-write access to Git repositories can only be granted to people with a BFH account. Means external people need to get a BFH guest account for that.


Unlike with other Version Control System offerings we do not create repositories for the user. Instead we assign areas on the Git server to the user for self-administration so that user can create and remove repositories as well as assign rights for other people on their own repositories themselfs.

When users request read-write access to the Git server they automatically get a personal area:

  • staff/${ACCOUNT} for staff
  • students/${ACCOUNT} for students

Additionally users can request unpersonal areas as well. These are loosly following the structur of BFH:


There is no technical difference between personal and unpersonal areas. The idea is that in personal areas people put repositories that are bound to them, means their repositories will be removed once they have no BFH account anymore when they have left BFH.

Unpersonal areas are ment for ongoing things like lectures that will be continued when a person has left thus the URL to the Git repository keeps the same. Or more generally it is ment for areas where multiple people work together, like research.


1. SSH Key

Create an OpenSSH Key Pair and send the public key and mention your BFH Account name via a ticket to IT Service Desk. Currently we accept RSA 4096 bit keys only.

BFH IT-Services maintains a SSH Certificate Authority (CA) to sign server host keys. As such we rotate host keys without notifications. See our SSH Certificate Authority documentation on how to install the CA key on your device. This will omit security warning messages and future needs for manually accept changed host keys.

Once your key has been imported you can check your permissions on the Git server. The following command will show you which repositories you are allowed to access and which areas you are allowed to created repositories in:


2. Create a new Repository

Once your SSH key has been added to the system repositories can be created with the following ssh command, e.g.:

ssh create staff/bad9/foo
ssh create staff/bad9/bar/baz

3. Clone the new Repository

Once the Git repository was created on the server it can be cloned with the following command, e.g.:

git clone

4. Manage your Repositories

4.1 Giving access to other users

By default a Git repository is only accessible by its creator through SSH. However, access can be granted to selected other people or can be made anonymously accessible through the Internet if desired.

If a BFH User is already known (i.e. his/her SSH public key has been imported) you can give access to repositories you own refering to the BFH Account of the user as his/her key, e.g.:

# Give anonymous git-daemon read access (to enable cloning through git://)
ssh perms staff/bad9/foo + READ daemon

# Give anonymous gitweb read access (to enable gitweb web-frontend at
ssh perms staff/bad9/foo + READ gitweb

# Give read access to Remo Schwaller (slr1) through SSH
ssh perms staff/bad9/foo + READ slr1

# Give write access to Simon Spoehel (shs1)
ssh perms staff/bad9/foo + WRITE shs1

# Give overwrite access (write access plus non-fastforward pushes)
ssh perms staff/bad9/foo + OVERWRITE slr1

# Give merge access (overwrite access plus merge commits)
ssh perms staff/bad9/foo + MERGE shs1

# Show given permissions
ssh perms staff/bad9/foo -l

If you give permissions to a user that has not previously had his/her key imported the permission will get automatically active once the key is imported. So there is no harm in setting permissions in advance.

Note: Enabling daemon or gitweb does not make the repository visible immediately, it requires one ‘git push’ to be activated (the push can be empty, doesn’t matter).

4.2 Set project description

Repositories can have a description which is shown in e.g. Gitweb:

ssh desc staff/bad9/foo Example Repository

4.3 How to set default branch

ssh symbolic-ref staff/bad9/foo HEAD refs/heads/my-branch

4.4 Delete an existing Repository

Repositories can be removed with following commands:

ssh D unlock staff/bad9/foo
ssh D rm staff/bad9/foo