Forking workflow using gitlab web interface only : how to keep fork repositories updated from official repository of a project ? (like a 'git pull upstream master' command)

To make short : if people use gitlab only across web interface (adding, removing files, committing, etc …) without any command line and without any local git clone, in a “forking workflow” or “fork and pull workflow”) logic, then how is it possible to keep update the fork repositories from the official repository (again, using only gitlab web interface).

To say it differently : how to get a similar behavior between forks and official repositories than using git pull upstream master command line, without any local clone and without any command lines, using only gitlab web interface ?


a similar question was asked in this topic lately: Refreshing a Fork

If you are using you can use the mentioned mirroring capabilities.


Hi @dnsmichi

Thanks a lot for the link you give “Refreshing a Fork” where it is explained how a fork repository can monitor an other repository, using “gitlab repository mirror” or “git CLI”. I’m going to read it quietly and will be back to ask few questions if necessary, or to conclude.

Thanks again Michael.

@dnsmichi , I’ve read your posts into “Refreshing a fork” topic, and I’ve tried to reproduce the solutions you mentioned. I’ve also read the Gitlab documentation related to “Repository mirroring”.

I still have question to make it running, to keep a fork repository update with a repository (let say, the original official repository from which the fork has been made) using only the web interface of gitlab.

Having forked a project (a repository), I went to Settings > Repository > Mirroring repositories. Then I tried to understand what should be filled.

Question : assuming the repository to mirror is a repository, and assuming the fork is hosted on too, in the URL field, should it be the SSH address or the https address ? And, what should be the password ?

I’ve tried with https URL but I do not know what to put as password. Thank you for your help.


if the upstream repository is public, then just use https pull without any username/password. I use that for keeping my fork of www-gitlab-com uptodate, I prefer fixing typos on the website with the Web IDE on my ipad - :wink:

If the repo is private, you may need username and password token.


1 Like

Thank you very much. It works fine. Super !

Then, lets resume.

When using only gitlab web interface of , it is possible to keep a public fork repository hosted on permanently update from a public repository also hosted on (from which the public fork has been made). This is called mirroring repository.

Doing this is simple :

  1. Go to the public repository hosted on , the one your fork is created from. Copy its https clone URL (clic on clone button on home page of this public repository)
  2. Then go to your public fork project (created from the previous repository), and to Settings > Repository > Mirroring repositories . In the URL field, paste the clone URL of the previous repository (the one your fork is created from).
  3. Choose “pull”
  4. Do not fill password field
  5. Enable (fill the square) of option which allow to clean history of commits and to get a clean merge

Then what does it mean ?

That means, with it is possible to use only its web interface , when people want to run a collective project without any command line in a “forking workflow” way (also named “fork & pull workflow” way), including the permanent updating of developers forks repositories master branch from official original repository master branch.

Thank you @dnsmichi for this help. It is cool to know this is possible. People without command line knowledge could then participate to public projects on in a “forking workflow” way. Super.

1 Like

Cool, thanks for the detailed summary :slight_smile:

And yes, the mirroring capabilities are a key feature for GitLab and collaboration, especially with going the Web IDE route.

Somehow the pull functionality is from the enterprise version which you get on for free. If you try that workflow with on-premise with CE, it won’t work.

On GitHub, I had written a which includes these details for shell updates, since forks and PRs might be running stale. It doesn’t have such sync capabilities to my knowledge, which makes social coding a bit more complicated these days. Except for the problem that first time contributors don’t necessarily know what a fork means :wink: