login | rules | SSH | basics | sharing | e-mail replies | groups | references


GitLab is a web manager of Git reposiories similar to the well known GitHubservice. In addition to repository management (repositories are called projects here) GitLab can do Wiki and Issue tracking.


If you have an active account at the Faculty of Informatics, you can log in via LDAP authentication at the following URL:


Enter your faculty login and password; the account will be created automatically after the first time you log in.

If you do not possess a faculty login, you need to send a request to have an external account created. Do so by sending an e-mail containing your request and justification to administrators. To log in, use the Standard authentication.

Account validity

A GitLab account connected with your faculty account is valid only if the faculty account is active and unblocked. Should the faculty account be blocked or its validity have expired, all access to GitLab including SSH keys will be blocked as well.

Usage rules

SSH key

If you wish to work with a repository on your personal computer without the need to enter your password every time, you can upload the public SSH key in your profile. Follow the instructions. Here are tips only for UN*X systems.

How to create the SSH key

The ssh-keygen program may ask you to enter your password while creating the key. This is not mandatory: it is simpler to use the key with no password, however, the version with a password is safer.

Using the key with no password

You can use the following command to test the key functionality

ssh -i $path_to_the_PRIVATE_key git@gitlab.fi.muni.cz

The command output should be similar to:

Welcome to GitLab,(Name, Surname)
Connection to gitlab.fi.muni.cz closed.

Add the following lines to ~/.ssh/config (the file may not exist yet):

Host gitlab gitlab.fi.muni.cz
    HostName gitlab.fi.muni.cz
    IdentityFile path_to_the_PRIVATE_key

Individual lines are explained in the manual for ssh_config(5). You can try for yourself that the ssh git@gitlab command has an identical output to that noted above even without the key in the command arguments.

Using a key with a password

If you use this type of key as if it had no password, each GitLab operation will request the key password, which brings almost no benefit compared to regular login. Using the SSH agent, you will be able to unlock the key once and use it repeatedly:

ssh-agent $SHELL
ssh-add ~/.ssh/id_gitlab

The first command starts the agent, which, in turn, runs the new shell from the $SHELL variable. If your shell does not define the variable, enter the program path instead (e.g. /bin/sh). By terminating the shell you terminate the agent as well. Detailed information on commands is available in the instruction manual for ssh-agent(1) and ssh-add(1).

Please note that in the older version of the manual and on various discussion forums, you can find a procedure that makes use of eval $(ssh-agent -c) or a similar command. We do not recommend you use this procedure because it does not ensure the agent is terminated correctly.

Usage basics

Documentation on GitLab functions is available at help. We strongly recommend the following

Repository sharing

If you wish to allow access to other people outside of the project's “visibility” (Private, Internal or Public), you can set them as project members, see adding members.

If you wish to make a private or internal project accessible to a person who does not possess a faculty account, and the person only needs access the project to download it (i.e., he or she does not need access to Issues, wiki etc.), you can use Deploy keys (actually a read-only access to the project via the SSH key). If access to other services is required, or the ability to contribute to the project, the project must be made public or an external account must be created for the person concerned (place a request with administrators).

E-mail responses

The faculty GitLab features the Reply by E-mail function, which allows users to respond to comments in "issues" and "milestones" directly via e-mail. To use the function properly, several rules must be observed:

You can use Markdown in your emails and add attachments which will be displayed as attachment to your response in GitLab.


The feature to create your own groups is disabled in GitLab so that no collision with synchronized groups occurs. If you need to create your own group or wish to allow group synchronization, contact administrators.

If you become a member of a group, GitLab will send you an e-mail notification.

Guidelines for synchronized group owners

In your request to have a group created, indicate

For student subject groups, we recommend the Reporter rights, and for others the Developer rights. Rights may be modified in GitLab separately for individual users.

Groups synchronized with faculty administration are subject to special limitations to Owner rights. The synchronization script grants this right only to administrators. If you grant this right to a regular member, he or she will lose it after any synchronization.

Group setup

If you were granted group owner rights, GitLab will allow you to change the group settings. You can change the name or description but never change the path. It is not technically possible to prohibit this option in GitLab, nevertheless you can cause conflicts during the synchronization of new groups.

Groups are implicitly synchronized with the Private visibility. This setting may be changed to Internal or Public in SettingsGroup Visibility.

Other links and instruction manuals