GitLab/Workflows/Assumptions

Policy Workflows Project setup assumptions Registering an account on GitLab Hosting a project on GitLab Pipeline conversion Mirroring projects Configuring CI Publishing documentation Code review Making a merge request Squashing Managing security patches Deploying services to production Gerrit to GitLab Localization updates wikitech:GitLab GitLab implementation

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.