- Public projects and groups
- Internal projects and groups
- Private projects and groups
- Change project visibility
- Change group visibility
- Restrict use of public or internal projects
GitLab allows users with the Owner role to set a project’s or group’s visibility as:
- Public
- Internal
- Private
These visibility levels affect who can see the project in the public access directory (/public for your GitLab instance). For example, //gitlab.com/public. You can control the visibility of individual features with project feature settings.
The visibility setting of a project must be at least as restrictive as the visibility of its parent group. For example, a private group can include only private projects, while a public group can include private, internal, and public projects.
Public projects and groups
Public projects can be cloned without any authentication over HTTPS.
They are listed in the public access directory (/public) for all users.
Public groups can have public, internal, or private subgroups.
Any signed-in user has the Guest role on the repository.
Internal projects and groups
Internal projects can be cloned by any signed-in user except external users.
They are also listed in the public access directory (/public), but only for signed-in users.
Internal groups can have internal or private subgroups.
Any signed-in users except external users have the Guest role on the repository.
Private projects and groups
Private projects can only be cloned and viewed by project members (except for guests).
They appear in the public access directory (/public) for project members only.
Private groups can only have private subgroups.
Change project visibility
Prerequisite:
- You must have the Owner role for a project.
- On the top bar, select Main menu > Projects and find your project.
- On the left sidebar, select Settings > General.
- Expand Visibility, project features, permissions.
- Change Project visibility to either Private, Internal, or Public.
- Select Save changes.
Change group visibility
Prerequisites:
- You must have the Owner role for a group.
- Subgroups and projects must already have visibility settings that are at least as restrictive as the new setting of the parent group. For example, you cannot set a group to private if a subgroup or project in that group is public.
- On the top bar, select Main menu > Groups and find your project.
- On the left sidebar, select Settings > General.
- Expand Naming, visibility.
- Under Visibility level select either Private, Internal, or Public.
- Select Save changes.
Restrict use of public or internal projects
You can restrict the use of visibility levels for users when they create a project or a snippet. This is useful to prevent users from publicly exposing their repositories by accident. The restricted visibility settings do not apply to administrators.
For details, see Restricted visibility levels.
- Project features
- Project integrations
- Import or export a project
- GitLab Workflow - VS Code extension
- Project APIs
- DORA4 analytics overview
In GitLab, you can create projects to host your codebase. You can also use projects to track issues, plan work, collaborate on code, and continuously build, test, and use built-in CI/CD to deploy your app.
Projects can be available publicly, internally, or privately. GitLab does not limit the number of private projects you can create.
Project features
Projects include the following features:
Repositories:
-
Issue tracker: Discuss implementations with your team.
- Issue boards: Organize and prioritize your workflow.
- Multiple issue boards: Create team-specific workflows (issue boards) for a project.
- Repositories: Host your code in a fully-integrated platform.
- Branches: Use Git branching strategies to collaborate on code.
- Protected branches: Prevent collaborators from changing history or pushing code without review.
- Protected tags: Control who has permission to create tags and prevent accidental updates or deletions.
- Repository mirroring
- Signing commits: Use GNU Privacy Guard (GPG) to sign your commits.
- Deploy tokens: Manage access to the repository and Container Registry.
- Web IDE
- CVE ID Requests: Request a CVE identifier to track a vulnerability in your project.
Issues and merge requests:
- Issue tracker: Discuss implementations with your team.
- Issue boards: Organize and prioritize your workflow.
- Multiple issue boards: Create team-specific workflows (issue boards) for a project.
- Merge requests: Apply a branching strategy and get reviewed by your team.
- Merge request approvals: Ask for approval before implementing a change.
- Fix merge conflicts from the UI: View Git diffs from the GitLab UI.
- Review Apps: By branch, preview the results of the changes proposed in a merge request.
- Labels: Organize issues and merge requests by labels.
- Time Tracking: Track time estimated and spent on issues and merge requests.
- Milestones: Work toward a target date.
- Description templates: Define context-specific templates for issue and merge request description fields.
- Slash commands (quick actions): Create text shortcuts for common actions.
- Autocomplete characters: Autocomplete references to users, groups, issues, merge requests, and other GitLab elements.
- Web IDE
GitLab CI/CD:
- GitLab CI/CD: Use the built-in
Continuous Integration, Delivery, and Deployment tool.
- Container Registry: Build and push Docker images.
- Auto Deploy: Configure GitLab CI/CD to automatically set up your app’s deployment.
- Enable and disable GitLab CI/CD
- Pipelines: Configure and visualize your GitLab CI/CD pipelines from the UI.
- Scheduled Pipelines: Schedule a pipeline to start at a chosen time.
- Pipeline Graphs: View your pipeline from the UI.
- Job artifacts: Define, browse, and download job artifacts.
- Pipeline settings: Set up Git strategy (how jobs fetch your repository), timeout (the maximum amount of time a job can run), custom path for .gitlab-ci.yml, test coverage parsing, pipeline visibility, and more.
- Kubernetes cluster integration: Connect your GitLab project with a Kubernetes cluster.
- Feature Flags: Ship different features by dynamically toggling functionality.
- GitLab Pages: Build, test, and deploy your static website.
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.
- Security Dashboard
- Syntax highlighting: Customize your code blocks, overriding the default language choice.
- Badges: Add an image to the Project information page.
- Releases: Take a snapshot of the source, build output, metadata, and artifacts associated with a released version of your code.
- Package Registry: Publish and install packages.
- Code owners: Specify code owners for specific files.
- License Compliance: Approve and deny licenses for projects.
- Dependency List: View project dependencies.
- Requirements: Create criteria to check your products against.
- Code Intelligence: Navigate code.
Project integrations
Integrate your project with Jira, Mattermost, Kubernetes, Slack, and a lot more.
Import or export a project
- Import a project from:
- GitHub to GitLab
- Bitbucket to GitLab
- Gitea to GitLab
- FogBugz to GitLab
- Export a project from GitLab
- Importing and exporting projects between GitLab instances
GitLab Workflow - VS Code extension
To avoid switching from the GitLab UI and VS Code while working in GitLab repositories, you can integrate the VS Code editor with GitLab through the GitLab Workflow extension.
To review or contribute to the extension’s code, visit its codebase in GitLab.
Project APIs
There are numerous APIs to use with your projects:
- Badges
- Clusters
- Threads
- General
- Import/export
- Issue board
- Labels
- Markdown
- Merge requests
- Milestones
- Services
- Snippets
- Templates
- Traffic
- Variables
- Aliases
- DORA4 Analytics
DORA4 analytics overview
Project details include the following analytics:
- Deployment Frequency
For more information, see DORA4 Project Analytics API.