FAQ

Login is done via your university’s Single Sign-On (SSO):

1. Open https://gitlab.git.nrw and click “Sign in”.
2. Choose “git.nrw University Login” and then select your university on the next page.
   • Guest accounts use the email login
3. You will be redirected to your university’s SSO and log in there (possibly including a second factor).
4. After successful authentication you will be redirected back to GitLab; on the first login your account is created automatically.

If your university is not listed, it may not be connected (yet) — in that case, sign-in via university SSO is currently not possible.

The git.nrw service is offered for the universities of DH.NRW and can be used by them. Currently, not all universities in North Rhine-Westphalia are connected to the service. At the moment, git.nrw will be available for members (students & staff) of the following universities at the time stated:

• RWTH Aachen University (May 20 2025)
• University of Duisburg-Essen (June 2nd 2025 for staff; students at a later date)
• TH Köln (to be announced)
• University of Cologne (May 20 2025)
• University of Münster (May 20 2025)

The git.nrw service is currently in the pilot phase, which is why not all universities in North Rhine-Westphalia are connected yet. The connection is being done gradually. We regularly provide updates on the git.nrw project on this website, including information about the connection of additional universities.

If your university is outside of North Rhine-Westphalia, it cannot be connected. The service can only be used by external users through a guest account. This guest account requires an invitation to a shared project and is only valid as long as the project is active.

Each user can invite up to 5 external guests, which are not from an already participating university.

The invitation is made through the git.nrw guest-management

To invite additional guests, a request can be submitted via the support form .

Adding guests to projects and assigning rights is done as usual in GitLab.

You can find more information in our documentation .

Many questions can be resolved directly via our FAQs and documentation. If you need to report a technical issue, it helps us if you provide as much concrete information as possible in the contact form, e.g.:

• Link to the affected page / project / group
• Time (date & time) and the exact error message
• Steps to reproduce
• Browser and operating system
• optional: screenshot/log excerpt (without passwords or tokens)

If this is a general outage, you may see a notice in the status banner at the top of the website.

There are two ways to report bugs or suggest improvements:

1. Merge request in the public repository: The git.nrw website repository is publicly accessible. You can create a merge request directly with your changes or suggestions: https://gitlab.git.nrw/web/git-nrw For more information on contributing, see our Contribute page .

2. Contact form: Alternatively, you can submit your request via our contact form . Please describe the bug or your suggestion as specifically as possible.

We gathered some tips and tricks for your first steps in GitLab, which can be found here: First Steps

You can find all our guides and resources in our documentation .

The official documentation from GitLab can be found here: https://docs.gitlab.com/

If several users are collaborating on different projects, it is useful to assign users to groups. More complex structures such as groups within groups can also be created, for example to map a research institution.

Groups can be used to visualize and organize teams in GitLab. By differentiating between top-level and sub-level groups, organizational structures can be separated from each other. A top-level group is intended for the highest administrative unit.

In order to avoid name duplications of common abbreviations and institutions, there are two options for clear identification:

• A prefix of the university is placed in front of the corresponding group name
• The group is incorporated into a top-level group below the entire university

If necessary, please contact your institution to find out which method is used.

Further benefits of groups:

• The quota of 10 personal projects does not apply to groups
• Projects within the group are accessible to all members of this group, an invitation process is not necessary

A new top-level group can be requested via the git.nrw contact form.

A new top-level group can be requested via the git.nrw contact form.

Please provide the following information:

• A minimum of 2 named owners for the top-level group. The names and email addresses of these persons are required; they must already have an account in git.nrw.
• The desired name of the top-level group: Please use the name of your university as a prefix, e.g. RWTH-, UDE-, etc.
  Special cases for e.g. special research areas (SFB) or other interdisciplinary projects are possible on request.

During the pilot phase of the git.nrw project, the creation of top-level groups is restricted to git.nrw administrators. The further administration of groups or projects below top-level groups is the responsibility of the two registered owners of the top-level group.

If a top-level group already exists for your institution, check within your institution and contact the group owners to request a sub-level group.

Once you have access to a top-level group, you can organize your work using subgroups:

1. Navigate to your top-level group in GitLab.
2. Click “New subgroup” and choose a name.
3. Set the visibility level (Private, Internal, or Public).

Managing members

• Go to your group and select “Manage” > “Members”.
• Click “Invite members” to add users by their username or email address.
• Assign a role (Guest, Reporter, Developer, Maintainer, or Owner) depending on the level of access required.

Members added to a group automatically have access to all projects and subgroups within that group. You can also add members at the subgroup or project level for more fine-grained control.

For more details, see the GitLab documentation on groups .

The following default limits apply in git.nrw:

• 2 GB storage per project (repository + LFS + artifacts)
• 10 personal projects per user account

Projects created within a group are not subject to the personal project limit — only the per-project storage limit applies.

By default, the storage space per project is limited to 2 GB in git.nrw. If a project exceeds this size, migration to git.nrw may not be possible.

In certain cases, the quota can be increased temporarily or permanently (e.g., for migration). We recommend reducing the size of the repository before increasing the quota, if possible.

If an increase in the quota is necessary, a request can be made using the git.nrw contact form. Please provide the following information:

• How many projects are involved?
• How much does the quota need to be adjusted?
• Are groups affected?
• Should the increase be temporary or permanent?
• Reason for the increase

The team will then provide feedback on the conditions under which a quota increase can take place.

Please Note: We reserve the right to refuse the quota increase in unjustified cases.

Large repositories can slow down cloning and push operations. Here are some approaches to reduce the size:

Add a .gitignore

Prevent build artifacts, dependencies, and temporary files from being committed:

node_modules/
build/
*.log

Clean up Git history

If large files were accidentally committed in the past, you can remove them from the history using git filter-repo :

git filter-repo --strip-blobs-bigger-than 50M

Warning: Rewriting history is a destructive operation. Coordinate with your team and create a backup before proceeding.

git.nrw is operated jointly by RWTH Aachen University and the University of Münster on behalf of the universities in North Rhine-Westphalia.

• All data is stored on servers in Germany.
• The service is operated exclusively by the two partner universities — there is no involvement of third-party providers.
• Only the git.nrw operations team has administrative access to the infrastructure. Your repositories and data are not accessible to other universities or external parties.

Further details on data processing can be found in the privacy policy .

For the plattform gitlab.git.nrw, the following privacy policy applies.

The git.nrw service processes and stores personal data solely for the management of the user account. Information requests and deletion requests can be addressed to the following contacts:

Data Protection Office of RWTH Aachen University:
Templergraben 83
52062 Aachen
Phone: +49 241 80 94114
Email: dsb@rwth-aachen.de

Data Protection Office of the University of Münster:
Schlossplatz 2
48149 Münster
Phone: +49 251 83 22446
Email: Nina.Meyer-Pachur@uni-muenster.de

Further information about data processing and storage for the use of git.nrw can be found in the privacy policy.

Since authentication is handled via your university’s Single Sign-On (SSO), your account benefits from the security measures of your university (including two-factor authentication if enabled there).

In addition, you can take the following steps within GitLab:

Use SSH keys for Git operations

SSH keys allow secure, password-free access when pushing and pulling. You can add your public key under “User Settings” > “SSH Keys”.

Manage Personal Access Tokens

If you use the GitLab API or CI/CD, create Personal Access Tokens with the minimum required scopes and set an expiration date. Revoke tokens you no longer need under “User Settings” > “Access Tokens”.

Review active sessions

Under “User Settings” > “Active Sessions” you can see all devices currently logged in and revoke sessions you do not recognize.

The project team offers its own training materials on the GitLab software solution, which can be found here:
https://git.nrw/en/courses

Requests for specific training materials can be sent to info@git.nrw or submitted via the contact form.

There are three target groups based on their level of knowledge:

• Beginner: Individuals with no prior knowledge who are just starting to explore the topic.
• Intermediate: Users who have heard something about git.nrw and GitLab or have gained some initial experience.
• Expert: Users who use GitLab daily and are proficient in advanced functions.

Additionally, the offering is primarily aimed at professors, instructors (from at least 5 universities in NRW), and students.

The central learning objectives are:

• Safe handling of git.nrw and GitLab: Learning, applying, and integrating the basics into daily work processes.
• Practical work: Users should be able to efficiently use GitLab as a daily tool.
• Individual self-evaluation: The quiz allows users to track their personal learning progress and improve it purposefully.

The tags serve as keywords for content categorization. They:

• Categorize the content thematically (e.g., “git”, “gitlab”, “software engineering”).
• Indicate the difficulty level (Beginner, Intermediate, Expert).

• Goal: To convey in-depth topics beyond the basics.
• Format: The specific training formats are still being evaluated (online, in-person, or hybrid).
• Certification: The certification process is currently open. Since our project group initially takes responsibility for course delivery and quality assurance, it is still unclear whether and how a formal certificate will be issued.

In addition to the modular online courses provided on the website, there are additional training sessions as part of the train-the-trainer approach.

• Target groups: Professors, instructors, and multipliers who are to convey the content.
• Organization:
  • Frequency: Regularly, with a quarterly planning currently being pursued.
  • Course size: Group sizes are still being defined to ensure an optimal learning and exchange process.
• Instructors: The trainers are selected in collaboration with the consortium partners and possess solid expertise as well as didactic experience.

• Documentation:
  The training page is based on HUGO and is provided as an open-source project on GitLab. All content and changes are versioned and documented, and the central project group oversees this process.
• Evaluation:
  A governance board is planned to be established to take over the evaluation of the content. The use of external tools and the development of a checklist are currently still in the planning phase.

Feedback on training and materials is always welcome:

• GitLab issues: For concrete improvement suggestions or problems, users can open an issue in the relevant course or documentation project.
• Contact form: If you’re not sure where it fits best, use the contact form (topic “Training”).

Additional feedback formats (e.g., surveys) are evaluated continuously.