diff options
Diffstat (limited to 'doc/user/project/repository')
| -rw-r--r-- | doc/user/project/repository/branches/default.md | 74 | ||||
| -rw-r--r-- | doc/user/project/repository/forking_workflow.md | 67 | ||||
| -rw-r--r-- | doc/user/project/repository/gpg_signed_commits/img/profile_settings_gpg_keys_paste_pub.png | bin | 13008 -> 0 bytes | |||
| -rw-r--r-- | doc/user/project/repository/gpg_signed_commits/index.md | 335 | ||||
| -rw-r--r-- | doc/user/project/repository/img/fork_form_v13_10.png | bin | 40932 -> 0 bytes | |||
| -rw-r--r-- | doc/user/project/repository/img/forking_workflow_choose_namespace_v13_10.png | bin | 18552 -> 0 bytes | |||
| -rw-r--r-- | doc/user/project/repository/jupyter_notebooks/index.md | 7 | ||||
| -rw-r--r-- | doc/user/project/repository/mirror/index.md | 4 | ||||
| -rw-r--r-- | doc/user/project/repository/mirror/push.md | 2 | ||||
| -rw-r--r-- | doc/user/project/repository/reducing_the_repo_size_using_git.md | 37 | ||||
| -rw-r--r-- | doc/user/project/repository/x509_signed_commits/index.md | 6 |
11 files changed, 264 insertions, 268 deletions
diff --git a/doc/user/project/repository/branches/default.md b/doc/user/project/repository/branches/default.md index d706a0e8f8a..f9fd1a48b9a 100644 --- a/doc/user/project/repository/branches/default.md +++ b/doc/user/project/repository/branches/default.md @@ -26,7 +26,7 @@ using the GitLab default only if no customizations are set: 1. A [project-specific](#change-the-default-branch-name-for-a-project) custom default branch name. 1. A [subgroup-level](#group-level-custom-initial-branch-name) custom default branch name. 1. A [group-level](#group-level-custom-initial-branch-name) custom default branch name. -1. An [instance-level](#instance-level-custom-initial-branch-name) custom default branch name. **(FREE SELF)** +1. An [instance-level](#instance-level-custom-initial-branch-name) custom default branch name. 1. If no custom default branch name is set at any level, GitLab defaults to: - `main`: Projects created with GitLab 14.0 or later. - `master`: Projects created before GitLab 14.0. @@ -81,13 +81,83 @@ overrides it. Users with at least the Owner role of groups and subgroups can configure the default branch name for a group: 1. Go to the group **Settings > Repository**. -1. Expand **Default initial branch name**. +1. Expand **Default branch**. 1. Change the default initial branch to a custom name of your choice. 1. Select **Save changes**. Projects created in this group after you change the setting use the custom branch name, unless a subgroup configuration overrides it. +## Protect initial default branches **(FREE SELF)** + +GitLab administrators and group owners can define [branch protections](../../../project/protected_branches.md) +to apply to every repository's [default branch](#default-branch) +at the [instance level](#instance-level-default-branch-protection) and +[group level](#group-level-default-branch-protection) with one of the following options: + +- **Not protected** - Both developers and maintainers can push new commits + and force push. +- **Protected against pushes** - Developers cannot push new commits, but are + allowed to accept merge requests to the branch. Maintainers can push to the branch. +- **Partially protected** - Both developers and maintainers can push new commits, + but cannot force push. +- **Fully protected** - Developers cannot push new commits, but maintainers can. + No one can force push. + +### Instance-level default branch protection **(FREE SELF)** + +This setting applies only to each repository's default branch. To protect other branches, +you must either: + +- Configure [branch protection in the repository](../../../project/protected_branches.md). +- Configure [branch protection for groups](../../../group/index.md#change-the-default-branch-protection-of-a-group). + +Administrators of self-managed instances can customize the initial default branch protection for projects hosted on that instance. Individual +groups and subgroups can override this instance-wide setting for their projects. + +1. On the top bar, select **Menu > Admin**. +1. On the left sidebar, select **Settings > Repository**. +1. Expand **Default branch**. +1. Select [**Initial default branch protection**](#protect-initial-default-branches). +1. To allow group owners to override the instance's default branch protection, select + [**Allow owners to manage default branch protection per group**](#prevent-overrides-of-default-branch-protection). +1. Select **Save changes**. + +#### Prevent overrides of default branch protection **(PREMIUM SELF)** + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211944) in GitLab 13.0. + +Instance-level protections for default branches +can be overridden on a per-group basis by the group's owner. In +[GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can +disable this privilege for group owners, enforcing the instance-level protection rule: + +1. On the top bar, select **Menu > Admin**. +1. On the left sidebar, select **Settings > Repository**. +1. Expand the **Default branch** section. +1. Clear the **Allow owners to manage default branch protection per group** checkbox. +1. Select **Save changes**. + +NOTE: +GitLab administrators can still update the default branch protection of a group. + +### Group-level default branch protection **(PREMIUM)** + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7583) in GitLab 12.9. +> - [Settings moved and renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/340403) in GitLab 14.9. + +Instance-level protections for [default branch](#default-branch) +can be overridden on a per-group basis by the group's owner. In +[GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can +[enforce protection of initial default branches](#prevent-overrides-of-default-branch-protection) +which locks this setting for group owners. + +1. On the top bar, select **Menu > Groups** and find your group. +1. On the left sidebar, select **Settings > Repository**. +1. Expand **Default branch**. +1. Select [**Initial default branch protection**](#protect-initial-default-branches). +1. Select **Save changes**. + ## Update the default branch name in your repository WARNING: diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md index b085372c8f2..ddeef65a6b5 100644 --- a/doc/user/project/repository/forking_workflow.md +++ b/doc/user/project/repository/forking_workflow.md @@ -18,36 +18,24 @@ submit them through a merge request to the repository you don't have access to. ## Creating a fork -To fork an existing project in GitLab: - -1. On the project's home page, in the top right, click **{fork}** **Fork**. - -  - -1. Select the project to fork to: +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15013) a new form in GitLab 13.11 [with a flag](../../../user/feature_flags.md) named `fork_project_form`. Disabled by default. +> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77181) in GitLab 14.8. Feature flag `fork_project_form` removed. - - Recommended method. Below **Select a namespace to fork the project**, identify - the project you want to fork to, and click **Select**. Only namespaces where you have - at least the Developer role for are shown. - -  - - - Experimental method. If your GitLab administrator has - enabled the experimental fork project form, read - [Create a fork with the fork project form](#create-a-fork-with-the-fork-project-form). - Only namespaces where you have at least the Developer role for are shown. - - NOTE: - The project path must be unique in the namespace. +To fork an existing project in GitLab: -GitLab creates your fork, and redirects you to the project page for your new fork. -The permissions you have in the namespace are your permissions in the fork. +1. On the project's home page, in the top right, select **{fork}** **Fork**: +  +1. Optional. Edit the **Project name**. +1. For **Project URL**, select the [namespace](../../group/index.md#namespaces) + your fork should belong to. +1. Add a **Project slug**. This value becomes part of the URL to your fork. + It must be unique in the namespace. +1. Optional. Add a **Project description**. +1. Select the **Visibility level** for your fork. For more information about + visibility levels, read [Project and group visibility](../../../public_access/public_access.md). +1. Select **Fork project**. -WARNING: -When a public project with the repository feature set to **Members Only** -is forked, the repository is public in the fork. The owner -of the fork must manually change the visibility. Issue -[#36662](https://gitlab.com/gitlab-org/gitlab/-/issues/36662) exists for this issue. +GitLab creates your fork, and redirects you to the new fork's page. ## Repository mirroring @@ -59,7 +47,7 @@ Without mirroring, to work locally you must use `git pull` to update your local with the upstream project, then push the changes back to your fork to update it. WARNING: -With mirroring, before approving a merge request, you are asked to sync. Because of this, automating it is recommended. +With mirroring, before approving a merge request, you are asked to sync. We recommend you automate it. Read more about [How to keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/). @@ -75,30 +63,9 @@ When creating a merge request, if the forked project's visibility is more restri  Then you can add labels, a milestone, and assign the merge request to someone who can review -your changes. Then click **Submit merge request** to conclude the process. When successfully merged, your +your changes. Then select **Submit merge request** to conclude the process. When successfully merged, your changes are added to the repository and branch you're merging into. ## Removing a fork relationship You can unlink your fork from its upstream project in the [advanced settings](../settings/index.md#removing-a-fork-relationship). - -## Create a fork with the fork project form **(FREE SELF)** - -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15013) in GitLab 13.11 [with a flag](../../../administration/feature_flags.md) named `fork_project_form`. Disabled by default. -> - [Enabled on self-managed and GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64967) in GitLab 13.8. - -FLAG: -On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../../administration/feature_flags.md) named `fork_project_form`. -On GitLab.com, this feature is available. - -This version of the fork project form is experimental: - - - -To use it, follow the instructions at [Creating a fork](#creating-a-fork) and provide: - -- The project name. -- The project URL. -- The project slug. -- Optional. The project description. -- The visibility level for your fork. diff --git a/doc/user/project/repository/gpg_signed_commits/img/profile_settings_gpg_keys_paste_pub.png b/doc/user/project/repository/gpg_signed_commits/img/profile_settings_gpg_keys_paste_pub.png Binary files differdeleted file mode 100644 index 6e2ff33eebb..00000000000 --- a/doc/user/project/repository/gpg_signed_commits/img/profile_settings_gpg_keys_paste_pub.png +++ /dev/null diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md index f5cea8a8075..00998c9a227 100644 --- a/doc/user/project/repository/gpg_signed_commits/index.md +++ b/doc/user/project/repository/gpg_signed_commits/index.md @@ -6,129 +6,96 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Signing commits with GPG **(FREE)** -You can use a GPG key to sign Git commits made in a GitLab repository. Signed -commits are labeled **Verified** if the identity of the committer can be -verified. To verify the identity of a committer, GitLab requires their public -GPG key. +You can sign the commits you make in a GitLab repository with a +GPG ([GNU Privacy Guard](https://gnupg.org/)) key. When you add a cryptographic +signature to your commit, you provide extra assurance that a commit +originated from you, rather than an impersonator. If GitLab can verify a commit +author's identity with a public GPG key, the commit is marked **Verified** in the +GitLab UI. You can then configure [push rules](../push_rules.md#enabling-push-rules) +for your project to reject individual commits not signed with GPG, or reject all +commits from unverified users. NOTE: -The term GPG is used for all OpenPGP/PGP/GPG related material and +GitLab uses the term GPG for all OpenPGP, PGP, and GPG-related material and implementations. -To view a user's public GPG key, you can: - -- Go to `https://gitlab.example.com/<username>.gpg`. -- Select **View public GPG keys** (**{key}**) in the top right of the user's profile. - -GPG verified tags are not supported yet. - -See the [further reading](#further-reading) section for more details on GPG. - -## How GitLab handles GPG - -GitLab uses its own keyring to verify the GPG signature. It does not access any -public key server. - -For a commit to be verified by GitLab: +For GitLab to consider a commit verified: - The committer must have a GPG public/private key pair. -- The committer's public key must have been uploaded to their GitLab - account. -- One of the emails in the GPG key must match a **verified** email address - used by the committer in GitLab. This address will be part of the public key. - If you want to keep this address private, use the automatically generated +- The committer's public key must be uploaded to their GitLab account. +- One of the email addresses in the GPG public key must match a **verified** email address + used by the committer in GitLab. To keep this address private, use the automatically generated [private commit email address](../../../profile/index.md#use-an-automatically-generated-private-commit-email) GitLab provides in your profile. - The committer's email address must match the verified email address from the GPG key. -## Generating a GPG key - -If you don't already have a GPG key, the following steps can help you get -started: - -1. [Install GPG](https://www.gnupg.org/download/index.html) for your operating system. - If your operating system has `gpg2` installed, replace `gpg` with `gpg2` in - the following commands. -1. Generate the private/public key pair with the command appropriate for your version - of `gpg`. This command spawns a series of questions: - - ```shell - # Use this command for the default version of gpg, including - # Gpg4win on Windows, and most macOS versions: - gpg --gen-key +GitLab uses its own keyring to verify the GPG signature. It does not access any +public key server. - # Use this command for versions of GPG later than 2.1.17: - gpg --full-gen-key - ``` +GPG verified tags are not supported. -1. The first question is which algorithm can be used. Select the kind you want - or press <kbd>Enter</kbd> to choose the default (RSA and RSA): +For more details about GPG, refer to the [related topics list](#related-topics). - ```plaintext - Please select what kind of key you want: - (1) RSA and RSA (default) - (2) DSA and Elgamal - (3) DSA (sign only) - (4) RSA (sign only) - Your selection? 1 - ``` +## View a user's public GPG key -1. The next question is key length. We recommend you choose `4096`: +To view a user's public GPG key, you can either: - ```plaintext - RSA keys may be between 1024 and 4096 bits long. - What keysize do you want? (2048) 4096 - Requested keysize is 4096 bits - ``` +- Go to `https://gitlab.example.com/<USERNAME>.gpg`. GitLab displays the GPG key, + if the user has configured one, or a blank page for users without a configured GPG key. +- Go to the user's profile (such as `https://gitlab.example.com/<USERNAME>`). In the top right + of the user's profile, select **View public GPG keys** (**{key}**). -1. Specify the validity period of your key. This is something - subjective, and you can use the default value, which is to never expire: +## Configure commit signing - ```plaintext - Please specify how long the key should be valid. - 0 = key does not expire - <n> = key expires in n days - <n>w = key expires in n weeks - <n>m = key expires in n months - <n>y = key expires in n years - Key is valid for? (0) 0 - Key does not expire at all - ``` +To sign commits, you must configure both your local machine and your GitLab account: -1. Confirm that the answers you gave were correct by typing `y`: +1. [Create a GPG key](#create-a-gpg-key). +1. [Add a GPG key to your account](#add-a-gpg-key-to-your-account). +1. [Associate your GPG key with Git](#associate-your-gpg-key-with-git). +1. [Sign your Git commits](#sign-your-git-commits). - ```plaintext - Is this correct? (y/N) y - ``` +### Create a GPG key -1. Enter your real name, the email address to be associated with this key - (should match a verified email address you use in GitLab) and an optional - comment (press <kbd>Enter</kbd> to skip): +If you don't already have a GPG key, create one: - ```plaintext - GnuPG needs to construct a user ID to identify your key. +1. [Install GPG](https://www.gnupg.org/download/) for your operating system. + If your operating system has `gpg2` installed, replace `gpg` with `gpg2` in + the commands on this page. +1. To generate your key pair, run the command appropriate for your version of `gpg`: - Real name: Mr. Robot - Email address: <your_email> - Comment: - You selected this USER-ID: - "Mr. Robot <your_email>" + ```shell + # Use this command for the default version of GPG, including + # Gpg4win on Windows, and most macOS versions: + gpg --gen-key - Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O + # Use this command for versions of GPG later than 2.1.17: + gpg --full-gen-key ``` -1. Pick a strong password when asked and type it twice to confirm. -1. Use the following command to list the private GPG key you just created: +1. Select the algorithm your key should use, or press <kbd>Enter</kbd> to select + the default option, `RSA and RSA`. +1. Select the key length, in bits. GitLab recommends 4096-bit keys. +1. Specify the validity period of your key. This value is subjective, and the + default value is no expiration. +1. To confirm your answers, enter `y`. +1. Enter your name. +1. Enter your email address. It must match a + [verified email address](../../../profile/index.md#change-the-email-displayed-on-your-commits) + in your GitLab account. +1. Optional. Enter a comment to display in parentheses after your name. +1. GPG displays the information you've entered so far. Edit the information or press + <kbd>O</kbd> (for `Okay`) to continue. +1. Enter a strong password, then enter it again to confirm it. +1. To list your private GPG key, run this command, replacing + `<EMAIL>` with the email address you used when you generated the key: ```shell - gpg --list-secret-keys --keyid-format LONG <your_email> + gpg --list-secret-keys --keyid-format LONG <EMAIL> ``` - Replace `<your_email>` with the email address you entered above. - -1. Copy the GPG key ID that starts with `sec`. In the following example, that's - `30F2B65B9246B6CA`: +1. In the output, identify the `sec` line, and copy the GPG key ID. It begins after + the `/` character. In this example, the key ID is `30F2B65B9246B6CA`: ```plaintext sec rsa4096/30F2B65B9246B6CA 2017-08-18 [SC] @@ -137,49 +104,46 @@ started: ssb rsa4096/B7ABC0813E4028C0 2017-08-18 [E] ``` -1. Export the public key of that ID (replace your key ID from the previous step): +1. To show the associated public key, run this command, replacing `<ID>` with the + GPG key ID from the previous step: ```shell - gpg --armor --export 30F2B65B9246B6CA + gpg --armor --export <ID> ``` -1. Finally, copy the public key and [add it in your user settings](#adding-a-gpg-key-to-your-account) +1. Copy the public key, including the `BEGIN PGP PUBLIC KEY BLOCK` and + `END PGP PUBLIC KEY BLOCK` lines. You need this key in the next step. -## Adding a GPG key to your account +### Add a GPG key to your account -NOTE: -After you add a key, you cannot edit it, only remove it. In case the paste -didn't work, you have to remove the offending key and re-add it. - -You can add a GPG key in your user settings: +To add a GPG key to your user settings: +1. Sign in to GitLab. 1. In the top-right corner, select your avatar. 1. Select **Edit profile**. -1. On the left sidebar, select **GPG Keys**. -1. Paste your _public_ key in the **Key** text box. - -  - -1. Select **Add key** to add it to GitLab. You can see the key's fingerprint, the corresponding - email address, and creation date. +1. On the left sidebar, select **GPG Keys** (**{key}**). +1. In **Key**, paste your _public_ key. +1. To add the key to your account, select **Add key**. GitLab shows the key's + fingerprint, email address, and creation date:  -## Associating your GPG key with Git +After you add a key, you cannot edit it. Instead, remove the offending key and re-add it. -After you have [created your GPG key](#generating-a-gpg-key) and [added it to -your account](#adding-a-gpg-key-to-your-account), it's time to tell Git which -key to use. +### Associate your GPG key with Git -1. Use the following command to list the private GPG key you just created: +After you [create your GPG key](#create-a-gpg-key) and +[add it to your account](#add-a-gpg-key-to-your-account), you must configure Git +to use this key: + +1. Run this command to list the private GPG key you just created, + replacing `<EMAIL>` with the email address for your key: ```shell - gpg --list-secret-keys --keyid-format LONG <your_email> + gpg --list-secret-keys --keyid-format LONG <EMAIL> ``` - Replace `<your_email>` with the email address you entered above. - -1. Copy the GPG key ID that starts with `sec`. In the following example, that's +1. Copy the GPG private key ID that starts with `sec`. In this example, the private key ID is `30F2B65B9246B6CA`: ```plaintext @@ -189,114 +153,103 @@ key to use. ssb rsa4096/B7ABC0813E4028C0 2017-08-18 [E] ``` -1. Tell Git to use that key to sign the commits: +1. Run this command to configure Git to sign your commits with your key, + replacing `<KEY ID>` with your GPG key ID: ```shell - git config --global user.signingkey 30F2B65B9246B6CA + git config --global user.signingkey <KEY ID> ``` - Replace `30F2B65B9246B6CA` with your GPG key ID. - -1. Optional. If Git is using `gpg` and you get errors like `secret key not available` - or `gpg: signing failed: secret key not available`, run the following command to - change to `gpg2`: +1. Optional. If Git uses `gpg` and you get errors like `secret key not available` + or `gpg: signing failed: secret key not available`, run this command to + use `gpg2` instead: ```shell git config --global gpg.program gpg2 ``` -## Signing commits +### Sign your Git commits -After you have [created your GPG key](#generating-a-gpg-key) and [added it to -your account](#adding-a-gpg-key-to-your-account), you can start signing your -commits: +After you [add your public key to your account](#add-a-gpg-key-to-your-account), +you can sign individual commits manually, or configure Git to default to signed commits: -1. Commit like you used to, the only difference is the addition of the `-S` flag: +- Sign individual Git commits manually: + 1. Add `-S` flag to any commit you want to sign: - ```shell - git commit -S -m "My commit msg" - ``` + ```shell + git commit -S -m "My commit message" + ``` -1. Enter the passphrase of your GPG key when asked. -1. Push to GitLab and check that your commits [are verified](#verifying-commits). + 1. Enter the passphrase of your GPG key when asked. + 1. Push to GitLab and check that your commits [are verified](#verify-commits). +- Sign all Git commits by default by running this command: -If you don't want to type the `-S` flag every time you commit, you can tell Git -to sign your commits automatically: + ```shell + git config --global commit.gpgsign true + ``` -```shell -git config --global commit.gpgsign true -``` +## Verify commits -## Verifying commits +You can review commits for a merge request, or for an entire project: -1. Within a project or [merge request](../../merge_requests/index.md), navigate to - the **Commits** tab. Signed commits show a badge containing either - **Verified** or **Unverified**, depending on the verification status of the GPG - signature. +1. To review commits for a project: + 1. On the top bar, select **Menu > Projects** and find your project. + 1. On the left sidebar, select **Repository > Commits**. +1. To review commits for a merge request: + 1. On the top bar, select **Menu > Projects** and find your project. + 1. On the left sidebar, select **Merge requests**, then select your merge request. + 1. Select **Commits**. +1. Identify the commit you want to review. Signed commits show either a **Verified** + or **Unverified** badge, depending on the verification status of the GPG + signature. Unsigned commits do not display a badge:  -1. By clicking on the GPG badge, details of the signature are displayed. +1. To display the signature details for a commit, select the GPG badge:  -  +  -## Revoking a GPG key +## Revoke a GPG key -Revoking a key **unverifies** already signed commits. Commits that were -verified by using this key changes to an unverified state. Future commits -stay unverified after you revoke this key. This action should be used -in case your key has been compromised. +If a GPG key becomes compromised, revoke it. Revoking a key changes both future and past commits: + +- Past commits signed by this key are marked as unverified. +- Future commits signed by this key are marked as unverified. To revoke a GPG key: 1. In the top-right corner, select your avatar. 1. Select **Edit profile**. -1. On the left sidebar, select **GPG Keys**. +1. On the left sidebar, select **GPG Keys** (**{key}**). 1. Select **Revoke** next to the GPG key you want to delete. -## Removing a GPG key +## Remove a GPG key + +When you remove a GPG key from your GitLab account: -Removing a key **does not unverify** already signed commits. Commits that were -verified by using this key stay verified. Only unpushed commits stay -unverified after you remove this key. To unverify already signed commits, you need -to [revoke the associated GPG key](#revoking-a-gpg-key) from your account. +- Previous commits signed with this key remain verified. +- Future commits (including any commits created but not yet pushed) that attempt + to use this key are unverified. To remove a GPG key from your account: 1. In the top-right corner, select your avatar. 1. Select **Edit profile**. -1. On the left sidebar, select **GPG Keys**. -1. Select the trash icon (**{remove}**) next to the GPG key you want to delete. - -## Rejecting commits that are not signed **(PREMIUM)** - -You can configure your project to reject commits that aren't GPG-signed -via [push rules](../push_rules.md). - -## GPG signing API - -Learn how to [get the GPG signature from a commit via API](../../../../api/commits.md#get-gpg-signature-of-a-commit). - -## Further reading - -For more details about GPG, see: - -- [Git Tools - Signing Your Work](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) -- [Managing OpenPGP Keys](https://riseup.net/en/security/message-security/openpgp/gpg-keys) -- [OpenPGP Best Practices](https://riseup.net/en/security/message-security/openpgp/best-practices) -- [Creating a new GPG key with subkeys](https://www.void.gr/kargig/blog/2013/12/02/creating-a-new-gpg-key-with-subkeys/) (advanced) -- [Review existing GPG keys in your instance](../../../admin_area/credentials_inventory.md#review-existing-gpg-keys) - -<!-- ## Troubleshooting - -Include any troubleshooting steps that you can foresee. If you know beforehand what issues -one might have when setting this up, or when something is changed, or on upgrading, it's -important to describe those, too. Think of things that may go wrong and include them here. -This is important to minimize requests for support, and to avoid doc comments with -questions that you know someone might ask. - -Each scenario can be a third-level heading, e.g. `### Getting error message X`. -If you have none to add when creating a doc, leave this section in place -but commented out to help encourage others to add to it in the future. --> +1. On the left sidebar, select **GPG Keys** (**{key}**). +1. Select **Remove** (**{remove}**) next to the GPG key you want to delete. + +If you must unverify both future and past commits, +[revoke the associated GPG key](#revoke-a-gpg-key) instead. + +## Related topics + +- [Sign commits and tags with X.509 certificates](../x509_signed_commits/index.md) +- [Commits API](../../../../api/commits.md) +- GPG resources: + - [Git Tools - Signing Your Work](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) + - [Managing OpenPGP Keys](https://riseup.net/en/security/message-security/openpgp/gpg-keys) + - [OpenPGP Best Practices](https://riseup.net/en/security/message-security/openpgp/best-practices) + - [Creating a new GPG key with subkeys](https://www.void.gr/kargig/blog/2013/12/02/creating-a-new-gpg-key-with-subkeys/) (advanced) + - [Review existing GPG keys in your instance](../../../admin_area/credentials_inventory.md#review-existing-gpg-keys) diff --git a/doc/user/project/repository/img/fork_form_v13_10.png b/doc/user/project/repository/img/fork_form_v13_10.png Binary files differdeleted file mode 100644 index 00c2f89a844..00000000000 --- a/doc/user/project/repository/img/fork_form_v13_10.png +++ /dev/null diff --git a/doc/user/project/repository/img/forking_workflow_choose_namespace_v13_10.png b/doc/user/project/repository/img/forking_workflow_choose_namespace_v13_10.png Binary files differdeleted file mode 100644 index 74f65cb663d..00000000000 --- a/doc/user/project/repository/img/forking_workflow_choose_namespace_v13_10.png +++ /dev/null diff --git a/doc/user/project/repository/jupyter_notebooks/index.md b/doc/user/project/repository/jupyter_notebooks/index.md index 5646f478d9f..cd0c6679d8d 100644 --- a/doc/user/project/repository/jupyter_notebooks/index.md +++ b/doc/user/project/repository/jupyter_notebooks/index.md @@ -25,11 +25,8 @@ GitLab. ## Cleaner diffs -> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6589) in GitLab 14.5 [with a flag](../../../../administration/feature_flags.md) named `jupyter_clean_diffs`. Enabled by default. - -FLAG: -On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../../../administration/feature_flags.md) named `jupyter_clean_diffs`. -On GitLab.com, this feature is available. +> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6589) in GitLab 14.5 [with a flag](../../../../administration/feature_flags.md) named `jupyter_clean_diffs`. Enabled by default. +> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75500) in GitLab 14.9. Feature flag `jupyter_clean_diffs` removed. When commits include changes to Jupyter Notebook files, GitLab: diff --git a/doc/user/project/repository/mirror/index.md b/doc/user/project/repository/mirror/index.md index cddbc6fd891..c9fa30e39a8 100644 --- a/doc/user/project/repository/mirror/index.md +++ b/doc/user/project/repository/mirror/index.md @@ -96,9 +96,7 @@ Prerequisite: 1. Select **Update now** (**{retry}**):  -## Mirror only protected branches **(PREMIUM)** - -> Moved to GitLab Premium in 13.9. +## Mirror only protected branches You can choose to mirror only the [protected branches](../../protected_branches.md) in the mirroring project, diff --git a/doc/user/project/repository/mirror/push.md b/doc/user/project/repository/mirror/push.md index 221616bd41c..ebc4430ac53 100644 --- a/doc/user/project/repository/mirror/push.md +++ b/doc/user/project/repository/mirror/push.md @@ -76,7 +76,7 @@ through the [remote mirrors API](../../../../api/remote_mirrors.md). To configure a mirror from GitLab to GitHub: -1. Create a [GitHub personal access token](https://docs.github.com/en/github/authenticating-to-github/keeping-your-account-and-data-secure/creating-a-personal-access-token) +1. Create a [GitHub personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) with `public_repo` selected. 1. Enter a **Git repository URL** with this format: `https://<your_access_token>@github.com/<github_group>/<github_project>.git`. diff --git a/doc/user/project/repository/reducing_the_repo_size_using_git.md b/doc/user/project/repository/reducing_the_repo_size_using_git.md index 37b16d90d93..83fafd409e8 100644 --- a/doc/user/project/repository/reducing_the_repo_size_using_git.md +++ b/doc/user/project/repository/reducing_the_repo_size_using_git.md @@ -13,8 +13,6 @@ Git repositories become larger over time. When large files are added to a Git re - They take up a large amount of storage space on the server. - Git repository storage limits [can be reached](#storage-limits). -Such problems can be detected with [git-sizer](https://github.com/github/git-sizer#getting-started). - Rewriting a repository can remove unwanted history to make the repository smaller. We **recommend [`git filter-repo`](https://github.com/newren/git-filter-repo/blob/main/README.md)** over [`git filter-branch`](https://git-scm.com/docs/git-filter-branch) and @@ -40,7 +38,8 @@ These refs are not automatically downloaded and hidden refs are not advertised, To purge files from a GitLab repository: -1. [Install `git filter-repo`](https://github.com/newren/git-filter-repo/blob/main/INSTALL.md) +1. Install either [`git filter-repo`](https://github.com/newren/git-filter-repo/blob/main/INSTALL.md) or + [`git-sizer`](https://github.com/github/git-sizer#getting-started) using a supported package manager or from source. 1. Generate a fresh [export from the @@ -63,31 +62,43 @@ To purge files from a GitLab repository: git clone --bare --mirror /path/to/project.bundle ``` -1. Navigate to the `project.git` directory: +1. Go to the `project.git` directory: ```shell cd project.git ``` -1. Using `git filter-repo`, purge any files from the history of your repository. Because we are +1. Using either `git filter-repo` or `git-sizer`, analyze your repository + and review the results to determine which items you want to purge: + + ```shell + # Using git filter-repo + git filter-repo --analyze + head .git/filter-repo/analysis/*-{all,deleted}-sizes.txt + + # Using git-sizer + git-sizer + ``` + +1. Proceed to purging any files from the history of your repository. Because we are trying to remove internal refs, we rely on the `commit-map` produced by each run to tell us which internal refs to remove. NOTE: - `git filter-repo` creates a new `commit-map` file every run, and overwrite the `commit-map` from + `git filter-repo` creates a new `commit-map` file every run, and overwrites the `commit-map` from the previous run. You need this file from **every** run. Do the next step every time you run `git filter-repo`. - To purge all files larger than 10M, the `--strip-blobs-bigger-than` option can be used: + To purge specific files, the `--path` and `--invert-paths` options can be combined: ```shell - git filter-repo --strip-blobs-bigger-than 10M + git filter-repo --path path/to/file.ext --invert-paths ``` - To purge specific large files by path, the `--path` and `--invert-paths` options can be combined. + To generally purge all files larger than 10M, the `--strip-blobs-bigger-than` option can be used: ```shell - git filter-repo --path path/to/big/file.m4v --invert-paths + git filter-repo --strip-blobs-bigger-than 10M ``` See the @@ -148,7 +159,7 @@ operations before continuing. To clean up a repository: 1. Go to the project for the repository. -1. Navigate to **Settings > Repository**. +1. Go to **Settings > Repository**. 1. Upload a list of objects. For example, a `commit-map` file created by `git filter-repo` which is located in the `filter-repo` directory. @@ -158,7 +169,7 @@ To clean up a repository: split -l 3000 filter-repo/commit-map filter-repo/commit-map- ``` -1. Click **Start cleanup**. +1. Select **Start cleanup**. This: @@ -229,7 +240,7 @@ Until `git gc` runs on the GitLab side, the "removed" commits and blobs still ex must be able to push the rewritten history to GitLab, which may be impossible if you've already exceeded the maximum size limit. -In order to lift these restrictions, the administrator of the self-managed GitLab instance must +To lift these restrictions, the Administrator of the self-managed GitLab instance must increase the limit on the particular project that exceeded it. Therefore, it's always better to proactively stay underneath the limit. If you hit the limit, and can't have it temporarily increased, your only option is to: diff --git a/doc/user/project/repository/x509_signed_commits/index.md b/doc/user/project/repository/x509_signed_commits/index.md index 27ef14d31c5..c9cddad1a91 100644 --- a/doc/user/project/repository/x509_signed_commits/index.md +++ b/doc/user/project/repository/x509_signed_commits/index.md @@ -20,15 +20,15 @@ The main difference is the way GitLab determines whether or not the developer's (A trust store is a repository of trusted security certificates.) Combined with any required intermediate certificates in the signature, the developer's certificate can be chained back to a trusted root certificate. -- For GPG, developers [add their GPG key](../gpg_signed_commits/index.md#adding-a-gpg-key-to-your-account) +- For GPG, developers [add their GPG key](../gpg_signed_commits/index.md#add-a-gpg-key-to-your-account) to their account. GitLab uses its own certificate store and therefore defines the -[trust chain](https://www.ssl.com/faqs/what-is-a-chain-of-trust/). +[trust chain](https://www.ssl.com/faqs/what-is-a-certificate-authority/). For a commit or tag to be *verified* by GitLab: - The signing certificate email must match a verified email address in GitLab. -- The GitLab instance must be able to establish a full [trust chain](https://www.ssl.com/faqs/what-is-a-chain-of-trust/) +- The GitLab instance must be able to establish a full trust chain from the certificate in the signature to a trusted certificate in the GitLab certificate store. This chain may include intermediate certificates supplied in the signature. You may need to add certificates, such as Certificate Authority root certificates, |
