debian-mirror-gitlab/doc/workflow/forking_workflow.md

52 lines
2.1 KiB
Markdown
Raw Normal View History

2015-04-26 12:48:37 +05:30
# Project forking workflow
2016-04-02 18:10:28 +05:30
Forking a project to your own namespace is useful if you have no write
access to the project you want to contribute to. 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](gitlab_flow.md)
document more information about using branches to work together.
2015-04-26 12:48:37 +05:30
## Creating a fork
2016-04-02 18:10:28 +05:30
Forking a project is in most cases a two-step process.
2015-04-26 12:48:37 +05:30
2019-12-04 20:38:33 +05:30
1. Click on the fork button located located in between the star and clone buttons on the project's home page.
2015-04-26 12:48:37 +05:30
2019-10-12 21:52:04 +05:30
![Fork button](img/forking_workflow_fork_button.png)
2015-04-26 12:48:37 +05:30
2019-10-12 21:52:04 +05:30
1. Once you do that, you'll be presented with a screen where you can choose
the namespace to fork to. Only namespaces (groups and your own
namespace) where you have write access to, will be shown. Click on the
namespace to create your fork there.
2016-04-02 18:10:28 +05:30
2019-10-12 21:52:04 +05:30
![Choose namespace](img/forking_workflow_choose_namespace.png)
2016-04-02 18:10:28 +05:30
2019-10-12 21:52:04 +05:30
**Note:**
If the namespace you chose to fork the project to has another project with
the same path name, you will be presented with a warning that the forking
2019-12-04 20:38:33 +05:30
could not be completed. Try to resolve the error before repeating the forking
2019-10-12 21:52:04 +05:30
process.
2016-04-02 18:10:28 +05:30
2019-10-12 21:52:04 +05:30
![Path taken error](img/forking_workflow_path_taken_error.png)
2016-04-02 18:10:28 +05:30
After the forking is done, you can start working on the newly created
2016-08-24 12:49:21 +05:30
repository. There, you will have full [Owner](../user/permissions.md)
2016-04-02 18:10:28 +05:30
access, so you can set it up as you please.
2015-04-26 12:48:37 +05:30
## Merging upstream
2016-04-02 18:10:28 +05:30
Once you are ready to send your code back to the main project, you need
to create a merge request. Choose your forked project's main branch as
the source and the original project's main branch as the destination and
create the [merge request](merge_requests.md).
2015-04-26 12:48:37 +05:30
![Selecting branches](forking/branch_select.png)
2016-04-02 18:10:28 +05:30
You can then assign the merge request to someone to have them review
2019-12-04 20:38:33 +05:30
your changes. Upon pressing the 'Submit Merge Request' button, your
2016-04-02 18:10:28 +05:30
changes will be added to the repository and branch you're merging into.
2015-04-26 12:48:37 +05:30
![New merge request](forking/merge_request.png)
2016-04-02 18:10:28 +05:30
[gitlab flow]: https://about.gitlab.com/2014/09/29/gitlab-flow/ "GitLab Flow blog post"