GitLab best practice: Difference between revisions
→The developer fork: Adding instructions for fork synchronization |
No edit summary |
||
| Line 1: | Line 1: | ||
[[Main Page]] -> [[Documentation]] -> [[Gitlab best practice]] | [[Main Page]] -> [[Documentation]] -> [[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. | This page is a collection of links to Gitlab documentation and will evolve into some guidelines how to use Gitlab within the project. | ||
| Line 11: | Line 10: | ||
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 | * '''fork''': repository copy in a other user space of Gitlab server system | ||
* '''clone''': local working copy on a machine | * '''clone''': local working copy on a machine | ||
| Line 17: | Line 16: | ||
* '''rebase''': | * '''rebase''': | ||
== Roles == | |||
There are two very different use cases, the | There are two very different use cases, the | ||
# '''User role''': A ''user'' wants to download the code, compile it and use it. | # '''User role''': A ''user'' wants to download the code, compile it and use it. | ||
# '''Developer role''': A ''developer'' contributes to the development. | # '''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. | The ''developer fork'' is the main feature in Gitlabs/Githubs concept of distributed development, code sharing and code review. | ||
=== Synchronizing developer fork with main repository === | |||
'''This should be done regularly!''' | '''This should be done regularly!''' | ||
| Line 36: | Line 35: | ||
#:<pre> git push origin dev</pre> | #:<pre> git push origin dev</pre> | ||
== Git commits == | |||
=== Log message format === | |||
== Handling merge requests == | == Handling merge requests == | ||
Revision as of 22:58, 25 January 2017
Main Page -> Documentation -> 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.
Synchronizing developer fork with main repository
This should be done regularly!
There is unfortunately no simple synchronization feature for forks within Gitlab (from Gitlab Enterprise Edition 8.2 repository mirroring is provided). Synchronization is done in the local clone.
- Fetch branch from the master repository
git fetch https://gitlab.uib.no/pct/wpn.git dev
- Rebase local branch
git rebase FETCH_HEAD dev
- Push to fork
git push origin dev
Git commits
Log message format
Handling merge requests
Automatic merges
Fast-forward merges
Fast forward merges do in contrast to normal Gitlab merges not produce a separate merge commit. Gitlab Enterprise Edition offers the feature to use fast-forward merges directly from the Gitlab Web interface. UiB IT is providing Gitlab Community Edition, so we do not have this convenient feature right away.
Why fast-forward merges?
Many people consider a linear commit history as an advantage, i.e. not to have merge commits for every merge. A fast-forward merge can be done if only the branch to be merged has additional commits on top of the common commit history. The merge simply means to forward the tip of the target branch.
Workflow
As Gitlab does not provide the functionality, the merge needs to be done outside Gitlab in a local clone from the master repository.
In the workflow below
- adjust the project name wpn
- adjust the user
- adjust the branch name
- you can skip the cloning if you have a already a clone
Workflow for merging the dev brach from a user fork
- Make a local clone from the master repository
git clone https://gitlab.uib.no/pct/wpn.git
git checkout dev
- or update an existing clone
git checkout dev
git pull --ff-only origin dev
- Fetch branch dev from user fork
git fetch https://gitlab.uib.no/user/wpn.git dev
- Merge alias FETCH_HEAD
git merge --ff-only FETCH_HEAD
- Push the update to the master repository
git push origin dev
Gitlab will automatically recognize that the merge request was merged manually and will close it.
