GitLab best practice

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.

• [1]]
• [2]
• [3]
• [4]

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

1. User role: A user wants to download the code, compile it and use it.
2. 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.

1. Fetch branch from the master repository

    git fetch https://gitlab.uib.no/pct/wpn.git dev

2. Rebase local branch

    git rebase FETCH_HEAD dev

3. Push to fork

    git push origin dev

Handling merge requests

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

1. 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

2. Fetch branch dev from user fork

    git fetch https://gitlab.uib.no/user/wpn.git dev

3. Merge alias FETCH_HEAD

    git merge --ff-only FETCH_HEAD

4. 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.