GitLab best practice: Difference between revisions
From pCT
| Line 25: | Line 25: | ||
=== Git commits === | === Git commits === | ||
==== Log message format ==== | ==== Log message format ==== | ||
== Handling merge requests == | |||
=== Automatic merges === | |||
=== Fast-forward merges === | |||
Revision as of 22:54, 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.
