A comprehensive tutorial series covering GitLab repository management, configuration, automated pipelines, and DevOps workflows.
GitLab began as an open-source project in 2011, started by a single commit with the goal of improving collaboration among team members . Over a decade later, it has evolved into an intelligent orchestration platform that brings development, security, and operations together into a single application . The core premise is simple but ambitious: instead…
GitLab organizes work through a three-tier namespace hierarchy: groups, subgroups, and projects. A project contains the repository, issues, merge requests, and CI/CD pipelines. A group is a container for projects and other groups. A subgroup is a group nested inside another group. The hierarchy is not cosmetic—it determines how permissions inherit, how visibility is enforced,…
GitLab supports two primary methods for authenticating Git operations and API requests: SSH keys and Personal Access Tokens (PATs). SSH keys are the preferred method for Git operations because they provide a secure, passwordless workflow after the initial setup. PATs are the mechanism for authenticating against the GitLab API, and they serve as the password…
A repository in GitLab is more than a Git directory. It is a project with a default branch, a set of permissions inherited from the namespace hierarchy, and a set of protected branches that enforce who can push and who can merge. The Git commands are the same as anywhere else—git clone, git checkout -b,…
A merge request in GitLab is the mechanism that turns a branch into a proposal. It is not a Git operation—Git has no concept of a merge request. It is a GitLab feature that wraps the branch in a review workflow: discussion, pipeline verification, and a merge gate. The exam tests the lifecycle: how the…