doc/user/project/merge_requests/confidential.md
{{< details >}}
{{< /details >}}
Merge requests in a public repository are also public, even when you create a merge request for a confidential issue. To avoid leaking confidential information when working on a confidential issue, create your merge request from a private fork in the same namespace.
Roles are inherited from parent groups. If you create your private fork in the same namespace (same group or subgroup) as the original (public) repository, developers receive the same permissions in your fork. This inheritance ensures:
For more information, see the patch release runbook for GitLab engineers.
Branches are public by default. To protect the confidentiality of your work, you must create your branches and merge requests in the same namespace, but downstream in a private fork. If you create your private fork in the same namespace as the public repository, your fork inherits the permissions of the upstream public repository. Users with the Developer role for the upstream public repository inherit those upstream permissions in your downstream private fork without action by you. These users can immediately push code to branches in your private fork to help fix the confidential issue.
[!warning] Your private fork might expose confidential information if you create it in a different namespace than the upstream repository. The two namespaces might not contain the same users.
Prerequisites:
To create a confidential merge request:
This merge request targets your private fork, not the public upstream project. Your branch, merge requests, and commits remain in your private fork. This prevents prematurely revealing confidential information.
Open a merge request from your fork to the upstream repository when: