GitLab best practice: Difference between revisions
From pCT
| Line 8: | Line 8: | ||
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. | 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. | ||
=== Terminology === | |||
* '''fork''': repository copy in a other user space of Gitlab server system | |||
* '''clone''': local working copy on a machine | |||
* '''merge''': | |||
* '''rebase''': | |||
=== Roles === | === Roles === | ||
Revision as of 22:20, 12 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.
Terminology
- fork: repository copy in a other user space of Gitlab server system
- clone: local working copy on a machine
- merge:
- rebase:
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.
