GitLab best practice: Difference between revisions
From pCT
No edit summary |
|||
Line 6: | Line 6: | ||
* [https://about.gitlab.com/2016/03/08/gitlab-tutorial-its-all-connected/]] | * [https://about.gitlab.com/2016/03/08/gitlab-tutorial-its-all-connected/]] | ||
* [https://docs.gitlab.com/ee/workflow/gitlab_flow.html#merge-pull-requests-with-gitlab-flow] | * [https://docs.gitlab.com/ee/workflow/gitlab_flow.html#merge-pull-requests-with-gitlab-flow] | ||
Git implements distributed repositories, git itself does not even make an assumption about a master repository. It is however good to have such a master repository and dedicated strategy how to contribute to it. | |||
=== Roles === | |||
There are two very different use cases, the | |||
# '''User role''': A ''user'' wants to download the code, compile it and use it. | |||
# '''Developer role''': A ''developer'' contributes to the development. | |||
=== The developer fork === | |||
The ''developer fork'' is the main feature in Gitlabs/Githubs concept of distributed development, code sharing and code review. |
Revision as of 14:06, 11 January 2017
Main Page -> Documentation -> Gitlab best practice
Gitlab best practice
This page is a collection of links to Gitlab documentation and will evolve into some guidelines how to use Gitlab within the project.
Git implements distributed repositories, git itself does not even make an assumption about a master repository. It is however good to have such a master repository and dedicated strategy how to contribute to it.
Roles
There are two very different use cases, the
- User role: A user wants to download the code, compile it and use it.
- Developer role: A developer contributes to the development.
The developer fork
The developer fork is the main feature in Gitlabs/Githubs concept of distributed development, code sharing and code review.