| stage | group | info | disqus_identifier |
|---|---|---|---|
Create |
Source Code |
To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments |
Whenever possible, it's recommended to work in a common Git repository and use branching strategies to manage your work. However, if you do not have write access for the repository you want to contribute to, you can create a fork.
A fork is a personal copy of the repository and all its branches, which you create in a namespace of your choice. This way you can make changes in your own fork and submit them through a merge request to the repository you don't have access to.
Forking a project is, in most cases, a two-step process.
-
On the project's home page, in the top right, click the Fork button.
-
Click a namespace to fork to. Only namespaces you have Developer and higher permissions for are shown.
NOTE: Note: The project path must be unique within the namespace.
The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
CAUTION: Caution: In GitLab 12.6 and later, when project owners reduce a project's visibility, it removes the relationship between a project and all its forks.
CAUTION: Caution: When a public project with the repository feature set to "Members only" is forked, the repository will be public in the fork. The owner of the fork will need to manually change the visibility. This is being fixed in #36662.
You can use repository mirroring to keep your fork synced with the original repository. You can also use git remote add upstream to achieve the same result.
The main difference is that with repository mirroring your remote fork will be automatically kept up-to-date.
Without mirroring, to work locally you'll have to use git pull to update your local repository
with the upstream project, then push the changes back to your fork to update it.
CAUTION: Caution: With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommended.
Read more about How to keep your fork up to date with its origin.
When you are ready to send your code back to the upstream project, create a merge request. For Source branch, choose your forked project's branch. For Target branch, choose the original project's branch.
NOTE: Note: When creating a merge request, if the forked project's visibility is more restrictive than the parent project (for example the fork is private, the parent is public), the target branch will default to the forked project's default branch. This prevents potentially exposing the private code of the forked project.
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 changes are added to the repository and branch you're merging into.
You can unlink your fork from its upstream project in the advanced settings.