GitLab/Workflows/Assumptions

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