Projects, Repository Settings, Visibility, Forks, Protected Resources, and Project Templates: Concepts, Architecture, and Mental Model

1. A project is a governance boundary, not just a remote repository

After Chapters 01 and 02, you know where GitLab runs and how identities authenticate. The next production question is: what exactly are you creating when you click New project? A Git repository stores commits, trees, blobs, tags, and refs. A GitLab project wraps a repository in hosted state: a namespace path, visibility policy, members and inherited access, issues/work items, merge requests, CI/CD configuration and history, registries, security features, webhooks, deployment metadata, and project settings.

This distinction prevents a common beginner error. Running git clone copies repository history and refs; it does not clone GitLab membership, issue state, protected-branch policy, CI variables, webhooks, container images, or billing/namespace ownership. Conversely, changing a project description or visibility does not create a Git commit.

2. Namespace → project → repository → refs: the core mental model

flowchart LR
NS[Namespace
personal/group] --> P[GitLab project
path + policy + hosted features]
P --> R[Git repository
objects + refs]
R --> B[branches/tags]
P --> H[hosted metadata
issues/MRs/settings]
P --> C[CI/CD + registries]
POL[visibility + roles + protected-ref policy] --> P
F[fork project
separate namespace/project] -. fork relationship .-> P

3. Project identity: name, slug, path, ID, and namespace

4. Visibility is hosted authorization, not Git cryptography

Visibility determines who can discover and access a project through GitLab. It does not encrypt Git objects. On GitLab.com, new projects are effectively chosen between Private and Public; the Internal level is documented for Self-Managed and Dedicated, where authenticated non-external users can access internal resources subject to policy.

5. Initialization choices can create the first Git history

A blank project with no repository commit is different from a project initialized with a README, license, or template. Selecting Initialize repository with a README creates the default branch and a first commit on the server. If you already have an unrelated local repository with its own first commit, pushing or pulling without planning can produce a non-fast-forward rejection or an unrelated-histories situation.

The safest production pattern is to declare the source of truth before project creation: either start hosted-first and clone that history, or create an empty GitLab project and push the existing local history. Do not independently initialize both sides and hope Git will infer that they belong together.

6. Forks, copies, imports, and templates preserve different relationships

7. Protected branches and tags are policy around refs

A protected branch is still an ordinary Git branch ref. GitLab evaluates hosted authorization before accepting certain pushes, deletes, force-pushes, or merges. Protected tags similarly control who may create protected tag names and help prevent accidental update/deletion. Basic protected branches and protected tags are available on Free; finer-grained user/group and Code Owner controls are tier-dependent.

Current GitLab documentation exposes protected-branch configuration through Settings → Repository → Branch rules; the older dedicated Protected branches settings are being removed. That is exactly why the course teaches the policy model before memorizing a menu path.

8. Project lifecycle operations have different blast radii

9. Read-only inspection before configuration

Use several surfaces because each proves something different. The web UI is useful for human-readable settings; glab gives structured command output; Git proves local/remote ref state; the REST API exposes machine-readable project metadata.

# Replace with a project you can safely inspect.
FULL_PATH="your-namespace/your-project"

# Hosted project metadata through glab.
glab repo view "$FULL_PATH" -F json   --jq '{id,path_with_namespace,visibility,default_branch,archived,topics}'

# Find the numeric project ID once, then make the target explicit.
PROJECT_ID="$(glab repo view "$FULL_PATH" -F json --jq .id)"
glab api "projects/$PROJECT_ID"   --jq '{id,path_with_namespace,visibility,default_branch,archived,empty_repo,topics}'

# Git answers a different question: which remote URL and refs exist locally?
git remote -v
git branch -vv
git ls-remote --heads origin

A missing field is evidence, not permission to guess. For example, default_branch: null can be legitimate for an empty project. Likewise, an empty protected-branches list means no returned rules for that project/context; it does not prove an instance administrator cannot impose other controls.

10. Why these defaults become production dependencies

CI pipeline sources, branch rules, package coordinates, container registry paths, release URLs, webhook targets, environment policies, deployment scripts, and dashboards often reference project identity and default-branch assumptions. A project path that looks cosmetic on day one can be a production interface six months later. Treat creation defaults as architecture: document the owner, namespace, visibility, source-of-truth history, default branch, and lifecycle policy before automation depends on them.

Knowledge check

Summary

A GitLab project is a namespace-scoped hosted container around a Git repository, not a synonym for the repository itself. Visibility, feature settings, forks, templates, protected refs, archive/delete state, and namespace ownership live in GitLab. Initialization choices can create real Git history. Production-safe project creation therefore starts by identifying the source of truth, owner, namespace, visibility, default branch, and downstream path dependencies before clicking Create.

Official references

• GitLab Docs — Create a project
• GitLab Docs — Project and group visibility
• GitLab Docs — Manage projects
• GitLab Docs — Projects API
• GitLab Docs — Forks
• GitLab Docs — Protected branches
• GitLab Docs — Protected tags
• GitLab Docs — Default branch
• GitLab Docs — Project topics
• GitLab CLI — repo commands