GitLab PM Associate key terms

A container that groups projects and users under one path, such as a group or personal account. It determines URL structure, permission boundaries, and where inherited settings apply.

A collection of projects and members that shares permissions, settings, and structure. Subgroups nest inside it, and membership can be inherited downward to child projects.

The core workspace holding a repository plus its issues, merge requests, pipelines, and settings. Every project sits inside a namespace and has its own visibility level.

A setting controlling who can see a project or group: private, internal, or public. It interacts with membership and can restrict features even for authenticated users.

A named permission set assigned to a user in a group or project, such as Guest, Reporter, Developer, Maintainer, or Owner. Higher roles include the abilities of lower ones.

A branch with rules limiting who may push or merge into it. Typical use keeps the default branch stable by requiring merge requests and restricting direct pushes.

The primary branch a project opens by default and treats as its mainline. It is usually protected and is the typical target for merge requests and pipeline schedules.

The version-controlled store of files and commit history for a project, built on Git. It holds branches and tags and is the source that pipelines and merge requests operate on.

A recorded snapshot of repository changes with an author, message, timestamp, and parent links. Commits form history and can trigger pipelines and link to issues.

A movable pointer to a line of commits, used to isolate work such as features or fixes. Branches can be protected, merged, and tied to pipeline runs.

A request to merge one branch into another, with discussion, review, approvals, and pipeline results attached. It is the main unit of code review and collaboration.

A configured requirement that a merge request receive a set number of approvals, optionally from specified users or groups, before merging. Rules can be scoped to protected branches.

The practice of examining proposed changes in a merge request through comments, suggestions, and approvals. It improves quality and spreads knowledge before code reaches the default branch.

A queue that merges merge requests one after another, each validated against the latest target branch state. It reduces breakage when many changes land close together.

A trackable work item describing a task, bug, or request, with assignees, labels, milestones, and discussion. Issues can be linked to merge requests and closed automatically on merge.

A work item that groups related issues across projects within a group, used for larger initiatives. Epics provide a higher-level view above individual issues and milestones.

A time-boxed target, such as a release or sprint end, to which issues and merge requests are assigned. It aggregates progress and burnup for planning and reporting.

A customizable tag applied to issues and merge requests to classify them by type, status, or team. Labels drive filtering, boards, and scoped label pairs like priority.

A kanban-style view of issues organized into lists, often by label or assignee. Boards visualize workflow stages and support moving work between columns.

A fixed-length time period, like a sprint, used to schedule and track issues within a group. Iterations support cadence-based planning and velocity reporting.

A timeline view showing epics or milestones across time to communicate planned delivery. It helps stakeholders see sequencing and dependencies at a high level.

A chart plotting remaining work over time against an ideal line for a milestone or iteration. It shows whether scope is being completed at the expected pace.

The top-level CI/CD run composed of stages and jobs, triggered by events such as pushes or schedules. Its status summarizes whether the delivered change passed all defined checks.

A YAML file, conventionally named .gitlab-ci.yml, stored in the repository that declares stages, jobs, rules, and variables. It defines what the pipeline executes and when.

A single unit of work in a pipeline, such as building, testing, or deploying, executed by a runner. Each job runs a script and reports logs and status.

A grouping of jobs that run in a defined order; later stages start only after earlier ones succeed. Stages organize pipelines into phases like build, test, and deploy.

An agent that executes pipeline jobs, either shared, group-scoped, or project-scoped. Runners pick up jobs matching their tags and report results back to the instance.

A file or set of files produced by a job and saved for later jobs or download, such as build output or test reports. Artifacts pass results between stages.

Files stored between pipeline runs to speed up repeated work, such as downloaded dependencies. Cache is best-effort and differs from artifacts, which are job outputs.

A named deployment target like staging or production, tracked with its current deployment. Environments enable review apps, deployment history, and controlled releases.

The act of releasing a version to an environment, recorded with who, when, and which commit. Deployment records support rollback, audit, and delivery visibility.

A pipeline that runs for a merge request's proposed changes before merging, rather than for the target branch. It validates code in isolation and can gate merging on success.

A configured timer that triggers a pipeline at set intervals, such as nightly builds. Schedules run against a chosen branch with optional variables.

A view of the end-to-end flow of work from idea to delivery, measuring stage durations. It reveals bottlenecks by showing time spent in each lifecycle stage.

A project- or group-level space for documentation pages stored alongside the codebase. Wikis support collaborative notes separate from the repository's source files.

A shareable block of code or text stored independently of a repository, with its own visibility. Snippets are useful for examples, logs, or quick collaboration.

A copy of a repository under another namespace that keeps a link to the original. Forks support contribution workflows where changes return via merge requests.

An HTTP callback configured to notify an external system when events occur, such as pushes or pipeline failures. Webhooks integrate projects with other tools.

A scoped credential used to authenticate API or Git operations on behalf of a user. Tokens have defined scopes and expiry and should be treated as secrets.