• Default branch protection
  • Disable group owners from updating default branch protection
• Default project creation protection
• Default project deletion protection
• Default deletion adjourned period
  • Override default deletion adjourned period
• Default project visibility
• Default snippet visibility
• Default group visibility
• Restricted visibility levels
• Import sources
• Project export
• Enabled Git access protocols
• Custom Git clone URL for HTTP(S)
• RSA, DSA, ECDSA, ED25519 SSH keys
• Allow mirrors to be set up for projects

Visibility and access controls

GitLab allows administrators to enforce specific controls.

To access the visibility and access control options:

1. Log in to GitLab as an admin.
2. Go to Admin Area > Settings > General.
3. Expand the Visibility and access controls section.

Default branch protection

This global option defines the branch protection that applies to every repository’s default branch. Branch protection specifies which roles can push to branches and which roles can delete branches. In this case Default refers to a repository’s default branch, which in most cases is master.

This setting applies only to each repositories’ default branch. To protect other branches, you must configure branch protection in repository. For details, see Protected Branches.

To change the default branch protection:

1. Select the desired option.
2. 変更を保存するをクリックします。

For more details, see Protected branches.

To change this setting for a specific group, see Default branch protection for groups

Disable group owners from updating default branch protection

GitLab 13.0から導入されました。

By default, group owners are allowed to override the branch protection set at the global level.

In GitLab Premium or higher, GitLab administrators can disable this privilege of group owners.

To do this:

1. Uncheck the Allow owners to manage default branch protection per group checkbox.

Default project creation protection

Project creation protection specifies which roles can create projects.

To change the default project creation protection:

1. Select the desired option.
2. 変更を保存するをクリックします。

For more details, see Default project-creation level.

Default project deletion protection

By default, a project can be deleted by anyone with the Owner role, either at the project or group level.

To ensure only admin users can delete projects:

1. Check the Default project deletion protection checkbox.
2. 変更を保存するをクリックします。

Default deletion adjourned period

GitLab 12.6 で導入されました。

By default, a project or group marked for removal will be permanently removed after 7 days. This period may be changed, and setting this period to 0 will enable immediate removal of projects or groups.

To change this period:

1. Select the desired option.
2. 変更を保存するをクリックします。

Override default deletion adjourned period

Alternatively, projects that are marked for removal can be deleted immediately. To do so:

1. Restore the project.
2. Delete the project as described in the Administering Projects page.

Default project visibility

To set the default visibility levels for new projects:

1. Select the desired default project visibility.
2. 変更を保存するをクリックします。

For more details on project visibility, see Public access.

Default snippet visibility

To set the default visibility levels for new snippets:

1. Select the desired default snippet visibility.
2. 変更を保存するをクリックします。

For more details on snippet visibility, see Public access.

Default group visibility

To set the default visibility levels for new groups:

1. Select the desired default group visibility.
2. 変更を保存するをクリックします。

For more details on group visibility, see Public access.

Restricted visibility levels

To set the available visibility levels for projects, snippets, and selected pages:

1. Check the desired visibility levels.
2. 変更を保存するをクリックします。

For more details on project visibility, see Public access.

Import sources

To specify from which hosting sites users can import their projects:

1. Check the checkbox beside the name of each hosting site.
2. 変更を保存するをクリックします。

Project export

To enable project export:

1. Check the Project export enabled checkbox.
2. 変更を保存するをクリックします。

For more details, see Exporting a project and its data.

Enabled Git access protocols

With GitLab’s access restrictions, you can select with which protocols users can communicate with GitLab.

Disabling an access protocol does not block access to the server itself via those ports. The ports used for the protocol, SSH or HTTP(S), will still be accessible. The GitLab restrictions apply at the application level.

To specify the enabled Git access protocols:

1. Select the desired Git access protocols from the dropdown:
   • Both SSH and HTTP(S)
   • Only SSH
   • Only HTTP(S)
2. 変更を保存するをクリックします。

When both SSH and HTTP(S) are enabled, users can choose either protocol.

When only one protocol is enabled:

• The project page will only show the allowed protocol’s URL, with no option to change it.
• A tooltip will be shown when you hover over the URL’s protocol, if an action on the user’s part is required, e.g. adding an SSH key, or setting a password.

On top of these UI restrictions, GitLab will deny all Git actions on the protocol not selected.

Custom Git clone URL for HTTP(S)

GitLab 12.4で導入されました。

You can customize project Git clone URLs for HTTP(S). This will affect the clone panel:

For example, if:

• Your GitLab instance is at https://example.com, then project clone URLs are like https://example.com/foo/bar.git.
• You want clone URLs that look like https://git.example.com/gitlab/foo/bar.git instead, you can set this setting to https://git.example.com/gitlab/.

To specify a custom Git clone URL for HTTP(S):

1. Enter a root URL for Custom Git clone URL for HTTP(S).
2. Click on Save changes.

RSA, DSA, ECDSA, ED25519 SSH keys

These options specify the permitted types and lengths for SSH keys.

To specify a restriction for each key type:

1. Select the desired option from the dropdown.
2. 変更を保存するをクリックします。

For more details, see SSH key restrictions.

Allow mirrors to be set up for projects

This option is enabled by default. By disabling it, both pull and push mirroring will no longer work in every repository and can only be re-enabled by an admin on a per-project basis.