Checkpoint Lab — Creating Repositories, Templates, Settings, Visibility, Topics, and Default Branches

1. Checkpoint scenario: provision Atlas Echo as if repository creation were infrastructure

You are the platform engineer for a fictional team. Your deliverable is not “a repo exists.” Your deliverable is evidence that the repository has the intended owner, visibility, default branch, metadata, Git state, and derivation model—and a runbook showing what must be inventoried before ownership changes or deletion.

You will create three synthetic resources: atlas-echo project, atlas-service-template, and one template-derived service. Use unique names so the lab is reproducible and isolated.

2. Preflight and role/plan assumptions

git --version
gh --version
gh auth status --active --hostname github.com
OWNER=$(gh api /user --jq .login)
STAMP=$(date +%Y%m%d%H%M%S)
PROJECT="atlas-echo-$STAMP"
TEMPLATE="atlas-service-template-$STAMP"
DERIVED="atlas-worker-$STAMP"
printf '%s\n' "$OWNER/$PROJECT" "$OWNER/$TEMPLATE" "$OWNER/$DERIVED"

• You are creating in your own personal namespace, so organization/team admin is not required.
• Public visibility is used only because all content is synthetic. If policy disallows public repositories, substitute --private consistently.
• The lab does not change visibility or transfer ownership live; those are security-sensitive lifecycle operations documented as design exercises.
• Repository deletion occurs only after all verification/evidence is captured.
• REST examples use X-GitHub-Api-Version: 2026-03-10.

3. Write the desired state before creation

4. Predictions before mutation

1. Prediction A: creating $PROJECT with --add-readme will create a hosted repository, one initial commit, and an effective default branch. It will not create a local clone.
2. Prediction B: editing description/topics will change hosted repository metadata but will not change the current Git commit OID.
3. Prediction C: generating $DERIVED from $TEMPLATE will create a new repository that is not a fork and does not share ordinary merge lineage with the template.

5. Create the project repository and verify Prediction A

gh repo create "$OWNER/$PROJECT" \
  --public \
  --description "Disposable Atlas Echo checkpoint" \
  --add-readme

gh repo view "$OWNER/$PROJECT" \
  --json nameWithOwner,visibility,description,defaultBranchRef,isEmpty,viewerPermission \
  --jq '{nameWithOwner,visibility,description,defaultBranch:.defaultBranchRef.name,isEmpty,viewerPermission}'

PROJECT_DEFAULT=$(gh repo view "$OWNER/$PROJECT" --json defaultBranchRef --jq .defaultBranchRef.name)
PROJECT_REMOTE_OID=$(gh api -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$PROJECT/commits/$PROJECT_DEFAULT" --jq .sha)
printf 'default=%s\ninitial_oid=%s\n' "$PROJECT_DEFAULT" "$PROJECT_REMOTE_OID"

Record the exact output. If owner, visibility, or description differs from the desired-state table, stop. Do not build more state on a misprovisioned repository. The initial commit OID proves the README created Git history.

6. Clone, add one commit, and prove exact ref movement

gh repo clone "$OWNER/$PROJECT"
cd "$PROJECT"
git status --short --branch
git remote -v
git rev-parse HEAD

mkdir -p app
printf '%s\n' 'Atlas Echo' > app/service.txt
printf '%s\n' '# Operations' '' 'Synthetic checkpoint only.' > OPERATIONS.md
git add app/service.txt OPERATIONS.md
git commit -m "docs: add Atlas Echo checkpoint content"
LOCAL_OID=$(git rev-parse HEAD)
git push origin HEAD
HOSTED_OID=$(gh api -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$PROJECT/commits/$PROJECT_DEFAULT" --jq .sha)
test "$LOCAL_OID" = "$HOSTED_OID"
printf 'verified=%s\n' "$HOSTED_OID"
cd ..

The before/after OIDs are your causality evidence: the branch moved from the README commit to your new commit after push. The repository owner/name and hosted description remain independent of that OID movement.

7. Change metadata and verify Prediction B

BEFORE_META=$(gh api -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$PROJECT/commits/$PROJECT_DEFAULT" --jq .sha)

gh repo edit "$OWNER/$PROJECT" \
  --description "Disposable Atlas Echo repository provisioning checkpoint" \
  --add-topic devops \
  --add-topic github-learning \
  --add-topic disposable-lab

gh repo view "$OWNER/$PROJECT" \
  --json description,repositoryTopics \
  --jq '{description,topics:[.repositoryTopics[].name]}'

AFTER_META=$(gh api -H "X-GitHub-Api-Version: 2026-03-10" \
  "/repos/$OWNER/$PROJECT/commits/$PROJECT_DEFAULT" --jq .sha)
test "$BEFORE_META" = "$AFTER_META"

Passing the OID comparison proves the hosted metadata change did not create a Git commit. This is the kind of independent verification infrastructure automation should perform rather than assuming every GitHub change appears in history.

8. Create a reusable template repository

gh repo create "$OWNER/$TEMPLATE" --public --add-readme --clone
cd "$TEMPLATE"
mkdir -p .github/workflows
printf '%s\n' '# Atlas Service Template' '' 'Generated projects must replace this README.' > README.md
printf '%s\n' 'SERVICE_NAME=replace-me' 'PORT=8080' > service.env.example
printf '%s\n' '.env' 'build/' > .gitignore
cat > .github/workflows/README.txt <<'EOF'
Workflow planning note only. Real GitHub Actions begins in later chapters.
EOF
git add .
git commit -m "chore: prepare Atlas service template"
git push origin HEAD
TEMPLATE_OID=$(git rev-parse HEAD)
cd ..

gh repo edit "$OWNER/$TEMPLATE" --template
gh repo view "$OWNER/$TEMPLATE" \
  --json isTemplate,defaultBranchRef \
  --jq '{isTemplate,defaultBranch:.defaultBranchRef.name}'

The template contains only inert starter files. The workflow directory includes text documentation, not executable workflow YAML, so this chapter does not accidentally introduce Actions permissions/security concepts before their dedicated chapters.

9. Generate a derived repository and verify Prediction C

gh repo create "$OWNER/$DERIVED" --public --template "$OWNER/$TEMPLATE"
gh repo view "$OWNER/$DERIVED" \
  --json nameWithOwner,isFork,parent,templateRepository,defaultBranchRef \
  --jq '{nameWithOwner,isFork,parent:(.parent.nameWithOwner // null),template:(.templateRepository.nameWithOwner // null),defaultBranch:.defaultBranchRef.name}'

gh repo clone "$OWNER/$DERIVED"
DERIVED_OID=$(git -C "$DERIVED" rev-parse HEAD)
printf 'template_oid=%s\nderived_oid=%s\n' "$TEMPLATE_OID" "$DERIVED_OID"
git -C "$DERIVED" log --oneline --decorate --all -5

The exact commit IDs need not match. The important evidence is the relationship: isFork=false and template provenance rather than parent/upstream fork metadata. GitHub documents template-generated histories as unrelated, which is why later template updates do not become ordinary upstream merges automatically.

10. Compare derived/template history with fork semantics

11. Ownership-transfer and lifecycle precautions: write the runbook before cleanup

Pretend $PROJECT must later move from your personal account into atlas-platform. Do not perform the transfer. Produce this inventory instead:

• Target organization exists; you have permission to create/receive the repository; no conflicting same-name repository/fork exists.
• Current owner/name, repository visibility, default branch, refs/tags, open PRs/issues/releases, collaborators, and fork-network state are recorded.
• Actions workflows/settings, environments/secrets names (never values), Pages, packages, webhooks, Apps/deploy keys, badges, external CI/CD, and deployment references are inventoried.
• Target organization plan/policy is checked for feature loss or visibility/creation/transfer restrictions.
• Consumer URLs and local remotes have an explicit update plan even though GitHub can redirect many old repository URLs.
• Backup/restore requirements distinguish Git data from hosted metadata. Conditional deleted-repository restoration is not the rollback plan.
• Change owner, verification owner, and rollback/communications steps are assigned.

12. Cleanup: delete only the three disposable repositories

First capture non-secret evidence: desired-state table, repository JSON, project/derived/template OIDs, template/fork fields, and your transfer inventory. Then delete the repositories one at a time through GitHub’s UI:

1. Open the exact repository and verify OWNER/NAME against your recorded lab variables.
2. Open Settings → General → Danger Zone → Delete this repository.
3. Read GitHub’s warnings, type the requested repository name, and confirm deletion.
4. Repeat only for $PROJECT, $TEMPLATE, and $DERIVED. Do not delete any similarly named non-lab repository.
5. Keep local clones temporarily so you can prove local Git survives hosted deletion; remove local directories afterward when evidence is complete.

13. Verify hosted cleanup and local independence

for R in "$PROJECT" "$TEMPLATE" "$DERIVED"; do
  gh repo view "$OWNER/$R" >/dev/null 2>&1
  printf '%s -> gh exit %s (expected nonzero after deletion)\n' "$OWNER/$R" "$?"
done

git -C "$PROJECT" log --oneline -2
git -C "$DERIVED" log --oneline -2

The GitHub lookups should fail after deletion, while the local clones can still read their Git history. That final contrast reinforces the chapter boundary: deleting a GitHub repository resource does not reach into a developer’s filesystem and erase a clone already on disk.

14. Final checkpoint verification checklist

• Desired owner, visibility, initialization, metadata, and default-branch intent were written before repository creation.
• Prediction A was verified with structured repository fields plus an exact initial commit OID.
• Local project commit and hosted default-branch commit matched after push.
• Prediction B was verified: metadata changed while commit OID stayed constant.
• Template repository reported isTemplate=true and contained no secrets/executable workflow privileges.
• Prediction C was verified: derived repository was not a fork and its relationship was explained correctly.
• Transfer/lifecycle inventory covered Git refs plus Actions, Pages, packages, webhooks, access/policy, forks, and backup concerns.
• Only disposable lab repositories were deleted and hosted deletion was independently verified.
• Local clone history remained readable after hosted deletion, proving the Git/GitHub boundary.

Knowledge check

15. What Chapter 03 adds to the production GitHub operating model

Chapter 01 gave you platform/account boundaries. Chapter 02 gave you secure authentication and credential boundaries. Chapter 03 adds repository provisioning and lifecycle discipline: declare owner/visibility/init/default branch/metadata, distinguish template and fork lineage, verify effective state with Git + gh/API, and treat rename/transfer/archive/delete as controlled changes over hosted dependencies.

A production platform can now define repository creation as policy-as-process even before full automation: one owner model, approved visibility classes, curated templates, standard metadata, verified branch defaults, chosen merge methods, and explicit lifecycle owners.

16. Chapter 03 completion summary

You created repositories as governed resources rather than empty remotes. You proved which changes modify Git objects/refs and which modify GitHub-hosted metadata, generated an independent project from a template, documented provenance, and cleaned up without relying on unsafe shortcuts.

The next chapter builds on this foundation by introducing branches, forks, remotes, synchronization, and contribution workflows. Those collaboration patterns only make sense once repository ownership, identity, visibility, and initialization are predictable.

Authoritative references

• Creating a new repository
• gh repo create
• gh repo view
• gh repo edit
• Creating a template repository
• Creating a repository from a template
• Forks
• Classifying your repository with topics
• Changing the default branch
• Renaming a repository
• Transferring a repository
• Archiving repositories
• Deleting a repository
• Restoring a deleted repository
• Backing up a repository
• REST API endpoints for repositories
• REST API versions