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.
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.
- you may not change your name even though GitLab allows it
- you may not change the group path
- repositories are not designated to store large files
- the total size limit for all repositories is 1.5 GB (the size of individual repositories may be reduced by using Project → Settings → Housekeeping)
- make sure you follow the operating rules
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
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 email@example.com
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
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
If your shell does not define the variable, enter the program path instead (e.g.
By terminating the shell you terminate the agent as well.
Detailed information on commands is available in the instruction manual for
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.
Documentation on GitLab functions is available at help. We strongly recommend the following
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).
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:
- respond directly to the delivered mail via
Replyfunction, do not compose a new e-mail
- respond only above any citation, or—and this is advisable—delete any citations; GitLab may not eliminate citations correctly
- if you sign your emails digitally, it is better not to add your signature to your GitLab responses
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
- the initial owner of the group, provided the group does not have an administrator who is on the faculty administration
- default rights for members
For student subject groups, we recommend the
Reporter rights, and for others the
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.
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
This setting may be changed to
Public in Settings → Group Visibility.