GitLab workflow and branching strategies
This domain tests GitLab's collaboration model: how branches are protected, how forks and merge requests drive review, and which branching strategy fits a team's release model.
Branching strategies
- Feature branching: short-lived branches from
main, merged back via merge request. - GitLab Flow: feature branches plus environment branches such as
maintopre-productiontoproduction, or release branches; changes flow downstream. - Trunk-based: small, frequent merges into
main, with feature flags hiding incomplete work. - Fork workflow: contributors without push access fork the project, push to the fork, and open a merge request to the upstream.
Protected branches and review
GitLab protects branches under Settings > Repository > Protected branches. You choose which roles may merge and push, whether force push is allowed, and whether code owner approval is required. A typical main allows Maintainers to merge but blocks direct Developer pushes, forcing a merge request. Approval rules can require a number of approvals and can remove approvals when new commits are added.
Merge requests and merge methods
A merge request names a source and target branch and shows commits, diffs, discussions, approvals, and pipeline status. GitLab can merge with a merge commit, a fast-forward merge, or a semi-linear history. Squash merges combine the source branch's commits into one commit on the target, keeping the target history tidy. Delete-source-branch is a common project setting.
Worked example
An external contributor cannot push to main. They fork the project, create fix-login, push it to their fork, and open a merge request targeting upstream main. A maintainer reviews, the pipeline passes, required approvals are met, and the MR is squash-merged; the source branch is deleted. Direct push was never an option because main is protected.
Traps that cost marks
- Assuming GitLab protection is only a Git rule; the server rejects pushes and force pushes.
- Expecting approvals to survive new commits when the project removes approvals on update.
- Opening a merge request from a fork but targeting the fork's
maininstead of upstream. - Squashing and then expecting the individual commits on the target branch.