Source Code and Collaboration Workflows
Source Code and Collaboration Workflows
This domain tests the everyday Git and GitLab flow: branching, commits, merge requests, review, approvals, and merging. The exam expects you to know which setting controls which behavior and how a change moves from a branch to the default branch.
Branches and merge requests
- A branch is a movable pointer to commits. A feature branch isolates work; the default branch (often
main) is the integration branch. - A merge request (MR) proposes merging a source branch into a target branch. It shows commits, changed files, pipeline status, approvals, and discussion threads.
- Draft MRs (prefix the title with
Draft:orWIP:) signal work in progress and block merging until marked ready. - Reviewers comment on lines, reply in threads, and resolve discussions. Suggestions can be applied directly as commits.
Controls that shape collaboration
Protected branches restrict who can push or merge; Maintainers typically manage them. Merge methods are project settings: merge commit, squash and merge, or fast-forward. Squashing combines the MR's commits into one on the target branch. Approval rules and Code Owners (Premium tiers) can require specific reviewers. Fork workflows let contributors without write access propose changes from a personal copy.
Worked example
A Developer needs to fix a typo but main is protected and only Maintainers can merge. The Developer creates fix/typo-readme from main, commits the change, pushes the branch, and opens an MR targeting main. A pipeline runs; a Maintainer reviews and merges. The reasoning: protected branch rules block direct pushes, but the Developer can still push a feature branch and request a merge. The target branch must be main, not the feature branch.
Traps that cost marks
Do not assume the MR source and target are interchangeable; reversing them proposes the wrong change. Do not expect a Draft MR to merge before it is marked ready. Do not confuse resolving a thread with approving the MR-they are separate signals. Do not assume squash is always on; it is a project setting. Do not push directly to a protected branch to save time.
Review hygiene
Keep MRs small, write a descriptive title, link the issue, and let the pipeline finish before requesting review. Use commit messages that explain why, not just what.