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.