Jump to content

GitLab/Workflows/Assumptions

From mediawiki.org

The GitLab documentation is written with a number of underlying assumptions, based on feedback from the GitLab consultation and recent experimentation. This document aims to summarize some of the ones most relevant to workflow.

  • Many regular contributors to a repository in GitLab will have "Developer"-level permissions or above, allowing them to create branches directly on the mainline copy of a project's repository, and merge changes from merge requests. While not identical, this is roughly equivalent to +2 rights on Gerrit.
  • As on Gerrit, default branches will be protected, and review will be required before a merge.
  • Location of branches
    • Users with permission to create branches will create work branches directly on the mainline repositories and submit merge requests for these.
    • Users without permission to create branches will instead fork the repository to their own account and create a work branch there, then submit a merge request for those changes to the mainline repository.
  • Development flow
    • In most situations, branches will accumulate commits sequentially as they receive review, and be squashed to a single commit on merge into the default branch.
    • It's possible to rewrite history and force push to the branch associated with a merge request, so workflows involving rebasing or amending of commits will be supported, though this is considered an advanced workflow.
  • Within a project or group, GitLab labels can serve similar functions to Gerrit's notion of topics. This may not hold true across the entire GitLab installation.