Skip to content

GitLab

Projects

In GitLab, you can create projects for hosting your codebase, use it as an issue tracker, collaborate on code, and continuously build, test, and deploy your app with built-in GitLab CI/CD.

Your projects can be available publicly, internally, or privately, at your choice. GitLab does not limit the number of private projects you create.

Project features

When you create a project in GitLab, you'll have access to a large number of features:

Repositories:

Issues and merge requests:

GitLab CI/CD:

Other features:

  • Wiki: document your GitLab project in an integrated Wiki.
  • Snippets: store, share and collaborate on code snippets.
  • Value Stream Analytics: review your development lifecycle.
  • Insights: configure the Insights that matter for your projects. (ULTIMATE)
  • Security Dashboard: Security Dashboard. (ULTIMATE)
  • Syntax highlighting: an alternative to customize your code blocks, overriding GitLab's default choice of language.
  • Badges: badges for the project overview.
  • Releases: a way to track deliverables in your project as snapshot in time of the source, build output, other metadata, and other artifacts associated with a released version of your code.
  • Conan packages: your private Conan repository in GitLab.
  • Maven packages: your private Maven repository in GitLab.
  • NPM packages: your private NPM package registry in GitLab.
  • Code owners: specify code owners for certain files (STARTER)
  • License Compliance: approve and deny licenses for projects. (ULTIMATE)
  • Dependency List: view project dependencies. (ULTIMATE)
  • Requirements: Requirements allow you to create criteria to check your products against. (ULTIMATE)
  • Static Site Editor: quickly edit content on static websites without prior knowledge of the codebase or Git commands.
  • Code Intelligence: code navigation features.

Project integrations

Integrate your project with Jira, Mattermost, Kubernetes, Slack, and a lot more.

New project

Learn how to create a new project in GitLab.

Fork a project

You can fork a project in order to:

  • Collaborate on code by forking a project and creating a merge request from your fork to the upstream project
  • Fork a sample project to work on the top of that

Star a project

You can star a project to make it easier to find projects you frequently use. The number of stars a project has can indicate its popularity.

To star a project:

  1. Go to the home page of the project you want to star.
  2. In the upper right corner of the page, click Star.

To view your starred projects:

  1. Click Projects in the navigation bar.

  2. Click Starred Projects.

  3. GitLab displays information about your starred projects, including:

    • Project description, including name, description, and icon
    • Number of times this project has been starred
    • Number of times this project has been forked
    • Number of open merge requests
    • Number of open issues

Explore projects

You can explore other popular projects available on GitLab. To explore projects:

  1. Click Projects in the navigation bar.
  2. Click Explore Projects.

GitLab displays a list of projects, sorted by last updated date. To view projects with the most stars, click Most stars. To view projects with the largest number of comments in the past month, click Trending.

Project settings

Set the project's visibility level and the access levels to its various pages and perform actions like archiving, renaming or transferring a project.

Read through the documentation on project settings.

Import or export a project

Delete a project

To delete a project, first navigate to the home page for that project.

  1. Navigate to Settings > General.
  2. Expand the Advanced section.
  3. Scroll down to the Delete project section.
  4. Click Delete project
  5. Confirm this action by typing in the expected text.

Delayed deletion (PREMIUM)

By default, projects in a personal namespace are deleted after a seven day delay.

Admins can restore the project during this period of time. This delay may be changed by an admin.

Admins can view all projects pending deletion. If you're an administrator, go to the top navigation bar, click Projects > Your projects, and then select the Deleted projects tab. From this tab an admin can restore any project.

For information on delay deletion of projects within a group, please see Enabling delayed Project removal

CI/CD for external repositories (PREMIUM)

Instead of importing a repository directly to GitLab, you can connect your repository as a CI/CD project.

Read through the documentation on CI/CD for external repositories.

Project members

Learn how to add members to your projects.

Project activity

To view the activity of a project, navigate to Project overview > Activity. From there, you can click on the tabs to see All the activity, or see it filtered by Push events, Merge events, Issue events, Comments, Team, and Wiki.

Leave a project

Leave project will only display on the project's dashboard when a project is part of a group (under a group namespace). If you choose to leave a project you will no longer be a project member, therefore, unable to contribute.

Project's landing page

The project's landing page shows different information depending on the project's visibility settings and user permissions.

For public projects, and to members of internal and private projects with permissions to view the project's code:

  • The content of a README or an index file is displayed (if any), followed by the list of directories within the project's repository.
  • If the project doesn't contain either of these files, the visitor will see the list of files and directories of the repository.

For users without permissions to view the project's code:

  • The wiki homepage is displayed, if any.
  • The list of issues within the project is displayed.

Redirects when changing repository paths

When a repository path changes, it is essential to smoothly transition from the old location to the new one. GitLab provides two kinds of redirects: the web UI and Git push/pull redirects.

Depending on the situation, different things apply.

When renaming a user, changing a group path or renaming a repository:

  • Existing web URLs for the namespace and anything under it (e.g., projects) will redirect to the new URLs.
  • Starting with GitLab 10.3, existing Git remote URLs for projects under the namespace will redirect to the new remote URL. Every time you push/pull to a repository that has changed its location, a warning message to update your remote will be displayed instead of rejecting your action. This means that any automation scripts, or Git clients will continue to work after a rename, making any transition a lot smoother.
  • The redirects will be available as long as the original path is not claimed by another group, user or project.

Use your project as a Go package

Any project can be used as a Go package. GitLab responds correctly to go get and godoc.org discovery requests, including the go-import and go-source meta tags.

Private projects, including projects in subgroups, can be used as a Go package, but may require configuration to work correctly. GitLab will respond correctly to go get discovery requests for projects that are not in subgroups, regardless of authentication or authorization. Authentication is required to use a private project in a subgroup as a Go package. Otherwise, GitLab will truncate the path for private projects in subgroups to the first two segments, causing go get to fail.

GitLab implements its own Go proxy. This feature must be enabled by an administrator and requires additional configuration. See GitLab Go Proxy.

Disable Go module features for private projects

In Go 1.12 and later, Go queries module proxies and checksum databases in the process of fetching a module. This can be selectively disabled with GOPRIVATE (disable both), GONOPROXY (disable proxy queries), and GONOSUMDB (disable checksum queries).

GOPRIVATE, GONOPROXY, and GONOSUMDB are comma-separated lists of Go modules and Go module prefixes. For example, GOPRIVATE=gitlab.example.com/my/private/project will disable queries for that one project, but GOPRIVATE=gitlab.example.com will disable queries for all projects on GitLab.com. Go will not query module proxies if the module name or a prefix of it appears in GOPRIVATE or GONOPROXY. Go will not query checksum databases if the module name or a prefix of it appears in GONOPRIVATE or GONOSUMDB.

Authenticate Go requests

To authenticate requests to private projects made by Go, use a .netrc file and a personal access token in the password field. This only works if your GitLab instance can be accessed with HTTPS. The go command will not transmit credentials over insecure connections. This will authenticate all HTTPS requests made directly by Go but will not authenticate requests made through Git.

For example:

machine gitlab.example.com
login <gitlab_user_name>
password <personal_access_token>

NOTE: Note: On Windows, Go reads ~/_netrc instead of ~/.netrc.

Authenticate Git fetches

If a module cannot be fetched from a proxy, Go will fall back to using Git (for GitLab projects). Git will use .netrc to authenticate requests. Alternatively, Git can be configured to embed specific credentials in the request URL, or to use SSH instead of HTTPS (as Go always uses HTTPS to fetch Git repositories):

# embed credentials in any request to GitLab.com:
git config --global url."https://${user}:${personal_access_token}@gitlab.example.com".insteadOf "https://gitlab.example.com"

# use SSH instead of HTTPS:
git config --global url."git@gitlab.example.com".insteadOf "https://gitlab.example.com"

Access project page with project ID

Introduced in GitLab 11.8.

To quickly access a project from the GitLab UI using the project ID, visit the /projects/:id URL in your browser or other tool accessing the project.

Project aliases (PREMIUM ONLY)

Introduced in GitLab Premium 12.1.

When migrating repositories to GitLab and they are being accessed by other systems, it's very useful to be able to access them using the same name especially when they are a lot. It reduces the risk of changing significant number of Git URLs in a large number of systems.

GitLab provides a functionality to help with this. In GitLab, repositories are usually accessed with a namespace and project name. It is also possible to access them via a project alias. This feature is only available on Git over SSH.

A project alias can be only created via API and only by GitLab administrators. Follow the Project Aliases API documentation for more details.

Once an alias has been created for a project (e.g., an alias gitlab for the project https://gitlab.com/gitlab-org/gitlab), the repository can be cloned using the alias (e.g git clone git@gitlab.com:gitlab.git instead of git clone git@gitlab.com:gitlab-org/gitlab.git).

Project APIs

There are numerous APIs to use with your projects: