Projects, Repository Settings, Visibility, Forks, Protected Resources, and Project Templates: Configuration, Design Choices, and Tradeoffs

1. Configuration starts by naming the source of truth

There is no universally “best” way to create a GitLab project. The correct choice depends on what already exists and which relationship must survive after creation. Begin with one question: where is the authoritative state today? If the answer is an existing local Git repository, create an empty remote and push it. If the answer is another GitLab project that you will contribute back to, a fork is usually the right relationship. If the answer is standardized scaffolding, a template is closer to the intent.

2. Blank, imported, template-derived, or forked?

3. Visibility is an exposure decision, not a collaboration shortcut

Do not choose Public merely because inviting members feels inconvenient. Visibility and membership solve different problems. A public project intentionally exposes reachable project content to unauthenticated users; a private project requires explicit/inherited access. On Self-Managed and Dedicated, Internal can expose the project to authenticated internal users while excluding external users, subject to administrator policy.

4. Personal namespace versus group-owned project

A personal namespace is convenient for experiments, but team services usually need ownership that survives an individual developer’s role change or departure. A group-owned project can inherit membership and policy from the group and fits an organizational governance model.

5. Fork network versus template or independent copy

A fork is a relationship, not just duplicate bytes. GitLab knows the upstream project, and fork-based merge requests can target it. A template-derived project is independent after creation: it may share initial files/history but does not promise upstream synchronization. An independent clone/push is even more explicit: Git history can be identical at one moment while GitLab has no fork relationship at all.

Choose a fork when contribution flow is the point. Choose a template when standardized starting state is the point. Choose an independent copy when separation is the point.

6. Template governance and sensitive copied state

Built-in templates are available across tiers. Group custom project templates are Premium/Ultimate, and instance custom project templates are Premium/Ultimate on Self-Managed/Dedicated. Current documentation also warns that template creation can copy more than files: exportable project settings, issues/MRs, labels, milestones, releases, and CI/CD configuration can be copied, while deploy keys, webhooks, members, and protected-ref access can vary depending on the creator’s permission.

That means “template” is a governance supply chain. Review the template project like a dependency: owners, CI configuration, protected-ref settings, webhooks, keys, stale users, and version/update strategy matter.

7. Protection defaults: preserve the policy intent, not a memorized menu

Basic protected branches/tags are available on Free. More granular protected-branch permissions, group-level protections, and Code Owner requirements can be tier-dependent. The design question is not “which checkbox should I click?” but “which actors should be able to create or mutate critical refs, and through which reviewed path?”

8. Worked design scenario: internal payment service

Scenario: a five-person team is starting a private internal payment API. They already have a local Git history, will add CI later, expect engineers to rotate, and do not need public contributions.

9. Architecture scorecard

Use this scorecard before approval:

• Maintainability: will paths/ownership remain stable as people change?
• Security: is visibility no broader than the audience, and are critical refs governed?
• Governance: can access and project ownership be audited through a group model?
• Reliability: does the creation method avoid ambiguous/unrelated histories?
• Compatibility: are features available on the actual GitLab offering/tier/version?
• Performance: are we avoiding unnecessary mirroring/import work? Project creation itself rarely needs performance tuning.
• Cost: is the mandatory path Free-compatible, with paid template/governance controls labeled optional?

10. Design exercise: write the project creation ADR before creating it

Create a short architecture decision record with these fields: namespace, owner, source_of_truth, creation_method, visibility, default_branch, fork_relationship, template_source, protected_refs_intent, retirement_strategy, and offering/tier assumptions. Then ask another learner to challenge two assumptions. The output is useful even if no GitLab resource is created.

Knowledge check

Summary

Project configuration is a set of architecture choices: authoritative history, ownership namespace, exposure level, upstream relationship, template source, critical-ref policy, and retirement behavior. Free GitLab supports a complete production-minded learning path; tier-gated templates and granular protections should be selected only when their governance value justifies the dependency.

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
• GitLab Docs — Custom project templates for groups
• GitLab Docs — Project templates for your instance