A fork is a personal copy of the repository and all its branches, which you create
in a namespace of your choice. Make changes in your own fork and
submit them through a merge request to the repository you don’t have access to.
If your fork does not have a remote pointing to the original repository,
use one of these examples to configure a remote called upstream:
# Use this line to set any repository as your upstream after editing <upstream_url>
git remote add upstream <upstream_url>
# Use this line to set the main GitLab repository as your upstream
git remote add upstream https://gitlab.com/gitlab-org/gitlab.git
After ensuring your local copy has the extra remote configured, you are ready to update your fork.
In your local copy, ensure you have checked out the
default branch
,
replacing
main
with the name of your default branch:
git checkout main
If Git identifies unstaged changes, commit or stash them before continuing.
Fetch the changes to the upstream repository:
git fetch upstream
Pull the changes into your fork, replacing main with the name of the branch
you are updating:
git pull upstream main
Push the changes to your fork repository on the server (GitLab.com or self-managed):
Repository mirroring
keeps your fork synced with the original repository.
This method updates your fork once per hour, with no manual
git pull
required.
For instructions, read
Configure pull mirroring
.
With mirroring, before approving a merge request, you are asked to sync. You should automate it.
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 defaults 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 select
Submit merge request
to conclude the process. When successfully merged, your
changes are added to the repository and branch you’re merging into.
If you unlink a fork in this way and if
pool repositories
are used, all objects are
copied from the pool into the fork.
After this copy is complete, the relationship is broken and the fork becomes an independent project. From this point, any updates to objects in the pool are
not propagated to the project that was previously a fork.
If you didn't find what you were looking for,
search the docs
.
If you want help with something specific and could use community support,
post on the GitLab forum
.
For problems setting up or using this feature (depending on your GitLab
subscription).
