---
layout: page
title: Help on use
permalink: /help/
ref: help
lang: en
---

## How to use GitLab?
TODO: Browser sufficient for many things, installing Git locally.

## First steps
TODO: Rough overview, links to good resources for learning more (see below).

## Visibility of Projects (and groups?)
TODO: Meanings of *private*, *internal*, and *public*.

## User roles and permissions

If you include somebody as a project member, you have to decide what role they should have.
You can pick either *Guest*, *Reporter*, *Developer*, *Maintainer*, or *Owner*.
Each role is associated with an increasing set of permissions, see them [here in form of a table](https://gitlab.test.uni-giessen.de/help/user/permissions.md#project-members-permissions){:target="_blank"}.
<!-- Also interesting: https://about.gitlab.com/handbook/product/index.html#permissions-in-gitlab -->

### Project permissions as Guest

The *Guest* role is for not-active members who can only read content, and open issues and leave comments.

Project members with the *Guest* role can
download the project,
leave comments,
view and pull project files,
view wiki pages,
create new issues,
see related issues,
create confidential issues,
and view self-created confidential issues.

If *Public pipelines* is enabled in *Project Settings > CI/CD*, they can also
see a list of jobs,
see a job log,
and download and browse job artifacts.

### Project permissions as Reporter

The *Reporter* role is for members who get more insights and can work in the issue tracker.

Project members with the *Reporter* role get the following permissions in addition to the *Guest* role:
TODO

<!--
Regarding issues, they can assign and label issues, lock issue threads, and manage the issue tracker and labels.
They can also create code snippets,
see a commit status,
see a container registry,
see environments,
see a list of merge requests,
view project statistics,
and view Error Tracking list.
-->

### Project permissions as Developer

TODO 
<!--
create new branches,
and push to or remove non-protected branches.
Regarding merge requests, they can create new ones,
manage/accept,
assign and label them,
and lock merge request threads.
They can create new environments and stop them.
cancel and retry jobs,
create or update commit status,
update a container registry,
remove a container registry image.
Regarding issues, they can create/edit/delete project milestones, and add tags.
apply code change suggestions,
create and edit wiki pages, and
rewrite/remove Git tags.
-->

### Project permissions as Maintainer

TODO 

### Project permissions as Owner

TODO 


## User groups
TODO: Group members and their roles and associated permissions.
TODO: Clarification that group projects won't be deleted when leaving JLU, as long as members exist in the group.

## Settings about private information
TODO: Setting of commit email address (in GitLab and locally), hiding of activity and profile, ...

## Last steps
TODO: Explanation when and what stuff gets deleted once you leave JLU (account data, *own* projects, ...) and what doesn't (group projects including issues and comments, commits, ...).
- Except for commits, stuff will be anonymized (transferred to the Ghost user).

## Further help
TODO: Useful links, maybe in categories.