=(s_("WikiHistoricalPage|You can view the %{most_recent_link} or browse the %{history_link}.")%{most_recent_link: most_recent_link,history_link: history_link}).html_safe
Forking a project to your own namespace is useful if you have no write
access to the project you want to contribute to. Even if you do have write
access or can request it, we recommend working together in the same
repository since it is simpler. See our [GitLab Flow](../../../topics/gitlab_flow.md)
document more information about using branches to work together.
Whenever possible, it's recommended to work in a common Git repository and use
[branching strategies](../../../topics/gitlab_flow.md) 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 repo you don't have access to.
## Creating a fork
...
...
@@ -27,7 +30,7 @@ Forking a project is, in most cases, a two-step process.
The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
CAUTION: **CAUTION:**
CAUTION: **Caution:**
In GitLab 12.6 and later, when project owners [reduce a project's visibility](../../../public_access/public_access.md#reducing-visibility),
it **removes the relationship** between a project and all its forks.
...
...
@@ -37,10 +40,11 @@ You can use [repository mirroring](repository_mirroring.md) to keep your fork sy
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 user `git pull` to update your local repo with the fork on GitLab. You'll have to fetch locally and push it back to the remote repo to update it.
Without mirroring, to work locally you'll have to use `git pull` to update your local repo
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 to be asked to sync, hence automating it is recommend.
With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommend.
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/).
msgid "Code Review Analytics displays a table of open merge requests considered to be in code review. There are currently no merge requests in review for this project and/or filters."
msgstr ""
msgid "Code owner approval is required"
msgstr ""
...
...
@@ -13602,22 +13605,22 @@ msgstr ""
msgid "PackageRegistry|NuGet Command"
msgstr ""
msgid "PackageRegistry|Registry Setup"
msgid "PackageRegistry|Pipeline %{linkStart}%{linkEnd} triggered %{timestamp} by %{author}"
msgstr ""
msgid "PackageRegistry|Remove package"
msgid "PackageRegistry|Published to the repository at %{timestamp}"
msgstr ""
msgid "PackageRegistry|There are no packages yet"
msgid "PackageRegistry|Registry Setup"
msgstr ""
msgid "PackageRegistry|There was a problem fetching the details for this package."
msgid "PackageRegistry|Remove package"
msgstr ""
msgid "PackageRegistry|There was an error fetching the pipeline information."
msgid "PackageRegistry|There are no packages yet"
msgstr ""
msgid "PackageRegistry|Unable to fetch pipeline information"
msgid "PackageRegistry|There was a problem fetching the details for this package."