TU Berlin

ZE CampusmanagementGitLab Service

"das Wort tubIT in roter Schrift auf wei├čem Grund"

Page Content

to Navigation


GitLab is a web-based version management software for collective work on programming code with git.

On the corresponding web portal users can log in and create their own projects.

For every project a git repository is created, where the programming code is deposited.

GitLab features a wiki and an issue tracker for every project through which documentation is offered and where problems and requests for modification can be gathered and managed.

Other users can be added and given differentiated rights for collective work.

Projects can be made accessible internally, externally, for signed-in users, project members or public/worldwide.

While all data is stored on tubIT servers,  mode and scope of operation essentially correspond to the web application "github.com".

GitLab is thus ideal for managing code regardless of working alone or in a group.

News: GitLab Major Update on August 2021

The next major update of our GitLab version is coming. We would like to ask all GitLab users of our central GitLab service at git.tu-berlin.de to inform themselves about relevant changes in the new version 14.0 here. It is possible that adjustments to existing GitLab projects may be necessary.

News: new GitLab Service

We are pleased to announce that we can present a new GitLab environment in the current version to all members of TUB.
The service can be accessed at git.tu-berlin.de and can be used by you with immediate effect.

The core features of the newly rolled out service compared to the existing one are:

  • Package Registry, to publish packages (e.g. for Maven, NPM, PyPI, Composer, Go...)
  • Design Management, to have discussions about images (mockups, designs...) and keep a history of iterations
  • Merge Request enhancements such as:

    • Merge Request Reviews - a developer creates a review in the course of reviewing a merge request diff and can make their own comments and then submit them collectively for visibility 
    • Merge Request Approval - for quality assurance purposes a merge request approval process can be used 
    • Merge Requests Draft - this can be used to mark unfinished merge requests as drafts and thus prevent them from being accepted accidentally 
    • Squash & Merge Support - commits can be merged into one, keeping the history shorter
    • Suggested Changes - reviewers can make changes to multiple lines for a merge request diff with a single suggestion

  • CI/CD Improvements, such as:

    • Code Quality Reports - code quality reviews can be configured for the CI/CD process
    • Static Application Security Testing (SAST) - for the CI/CD process SAST can be configured
    • Parent/Child Pipelines and Dynamic Child Pipelines, which can also be used to map more complex process structures
    • Fine-grained control over jobs using rules
    • Directed Acyclic Graph ("Needs") to clarify dependencies between jobs and reduce the duration of pipelines
    • HashiCorp Vault support for authentication, secrets reading and password management

  • New tab "Operation" to be able to find all important data about deployments centrally (if necessary with integration of external services):

    • Metrics (Prometheus / Grafana)
    • Logs (Elastic Stack)
    • Tracing (Jaeger)
    • Errors (Sentry)
    • Alerts & Incidents
    • Environments and Feature Flags

  • Web IDE - complex changes hitting multiple files can now be edited directly in the browser. Very handy if you are on the road and don't have a real IDE
  • last but ot least: the often missed SubGroups feature

A list of all changes can be found here.

News: Moving projects to git.tu-berlin.de

If you still need your GitLab projects from the previous installation at gitlab.tu-berlin.de or gitlab.tubit.tu-berlin.de, you should definitely back them up or move them to the new environment. For moving a project, we have provided instructions for you at gitlab.tubit.tu-berlin.de/zecm/migrations-projekt/.

As we had to realize in the meantime, the version differences of the two GitLab installations lead to very limited migration possibilities. Basically, only the source code and wikis can be transferred. For this reason, we decided to provide an extended web-based migration tool based on the GitLab API, which will give the possibility to import all metadata (wikis, issues, merge request, permissions, labels, etc.). We will inform about this tool after completion.

News: Shutdown of the old GitLab Service

You should only use the previous GitLab installation at gitlab.tu-berlin.de or gitlab.tubit.tu-berlin.de for backing up or moving your projects.

Please note that this environment will be set to readonly later this year and is expected to be shut down by the end of 2021.
The exact dates are yet to be announced.

Purpose of the GitLab Service

Version management of source code is possible with the help of the GitLab service. Furthermore, it is possible to use the GitLab service for Continuous Integration (CI), Continuous Delivery (CD) and Continuous Deployment (CD).

The GitLab service is provided for software development projects of the study, teaching and research for students and employees*.

IMPORTANT: Commercial use is not permitted.

Target audience

This application is available to all members of the TUB who have a tubIT account. Previous activation is not necessary.

Note: Other users can be added to a group only after they have logged into GitLab once.


GitLab is provided free of charge to members of the TU Berlin for research, teaching and study. The free GitLab version is used.


GitLab can be accessed by inserting username of your TUB Account (lowercase) and password on the following page https://git.tu-berlin.de.
The projects git repositories can be used by utilizing common git clients via HTTPS and SSH.

IMPORTANT: our previous GitLab service can be reached via gitlab.tubit.tu-berlin.de or gitlab.tu-berlin.de. This system will be shut down on 1st june 2021, so you will have to migrate your still needed projects to the new system at git.tu-berlin.de.

Terms of Use

  • In GitLab there are so-called "maintainers" - these are the owners and administrators of projects. Any user of the GitLab service can become a maintainer. They take responsibility for all content of their projects. This includes all data managed with GitLab.
  • A README file should be created for each project describing the project and naming the project maintainer(s).
  • Only files whose versioning makes sense may be loaded on the GitLab server.
  • Users of the GitLab system are required to comply with media and copyright laws.
  • The GitLab service may not be misused by users or user groups. As the operator of the service, ZECM reserves the right to take appropriate measures in the event of misuse.

General Conditions

  • Initially, repositories are created as private repositories. This can be changed if necessary.
  • Each user of the GitLab service can create 100 projects. The "visibility" of the individual projects can be defined by the "owner".
  • Users can manage groups and their members themselves.
  • It is not possible to change the username in GitLab. The usernames are always written in lower case.
  • The use of TUB service accounts (svc-*) is not permitted.
  • Setting up and working is possible worldwide via web interface, otherwise all git operations can also be performed via ssh. For this purpose an ssh-key has to be stored in GitLab.
  • There is a daily backup of the gitlab data at 1:00 am. This can lead to performance restrictions.

Data Protection

A TUB account and an e-mail address are required to use the GitLab service. The following (personal) data is required and stored by the service:


  • TUB account
  • Email address
  • IP address from which to log in


Additional personal data, which can be set via the system's profile settings, is not mandatory for use and is under your control. Processing of this additional data outside the GitLab system with its functionality does not take place.

Visible (generally accessible):

For each commit, the name and email address as stored in Git's configuration are visible.

  1. Access via web browser
    In the web interface, the GitLab username (Username) as set in the Account section of User Settings is visible. The username is also visible in the path for personal projects.
  2. Access via Git Client
    GitLab records all access that happens through a Git client. Thus, all activities on a repository are stored in its version history. In particular, the name and email address of the user configured in the Git client are stored here. Partial deletion or anonymization of this data cannot take place due to the tamper-proof nature of a Git repository. When participating in public GitLab projects, this information is stored and displayed on the project page in a generally accessible manner.

    This data can be deleted by authorized users with the help of Git mechanisms. Likewise, the version history of a repository is also deleted when the repository is deleted.

Contact the TU Berlin data protection team: info@datenschutz.tu-berlin.de


Please see one of the numerous documentations on git, such as  

https://git-scm.com/  or  https://doc.gitlab.com/ce/.




Quick Access

Schnellnavigation zur Seite über Nummerneingabe