Checkpoint Lab — GitHub Platform Foundations, Plans, Accounts, Organizations, and Repository Models

1. Checkpoint goal: prove the Git/GitHub boundary with evidence

This lab integrates the chapter. You will use one disposable repository, document its hosted state, compare that state through the web UI, GitHub CLI, REST API, and local Git, predict two changes, perform them, verify them independently, draw the platform boundary, and archive the repository if you created it for this course.

2. Preflight and evidence directory

Create an evidence directory outside the Git repository so checkpoint notes are not accidentally published:

Git Bash / Bash / zsh

mkdir -p ../github-platform-evidence
git --version
gh --version
gh auth status --active --hostname github.com | tee ../github-platform-evidence/auth-status.txt

PowerShell

New-Item -ItemType Directory ..\github-platform-evidence -Force | Out-Null
git --version
gh --version
gh auth status --active --hostname github.com | Tee-Object ..\github-platform-evidence\auth-status.txt

If you are not using gh, record the signed-in username and repository URL manually without copying cookies/session data. Never use --show-token.

3. Baseline A: web UI inventory

Open YOUR_USER/github-platform-lab. Record:

• Owner and repository name.
• Visibility.
• Default branch.
• Whether Issues, Pull requests, Actions, Projects, Security, and Insights surfaces are visible.
• Whether Settings is available to your account (it may be in an overflow menu on smaller layouts).
• The current platform-map branch if you completed Lesson 02.

Do not change any setting during the baseline.

4. Baseline B: structured GitHub CLI inventory

gh repo view --json \
nameWithOwner,visibility,defaultBranchRef,isInOrganization,viewerPermission,hasIssuesEnabled,hasProjectsEnabled,isArchived,url \
--jq '{repo: .nameWithOwner, visibility, defaultBranch: .defaultBranchRef.name, organizationOwned: .isInOrganization, permission: .viewerPermission, issues: .hasIssuesEnabled, projects: .hasProjectsEnabled, archived: .isArchived, url}' \
| tee ../github-platform-evidence/repo-view.json

This is hosted repository metadata. It is not a substitute for git status.

5. Baseline C: REST API inventory

gh api \
  -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  'repos/{owner}/{repo}' \
  --jq '{full_name, visibility, default_branch, archived, has_issues, has_projects, owner: .owner.login}' \
  | tee ../github-platform-evidence/repository-api.json

Record the API version with the evidence. That makes the observation reproducible even when GitHub later introduces a new API version.

6. Baseline D: local Git inventory

git remote -v
git status --short --branch
git branch -vv
git log --oneline --decorate --graph --all -10
git ls-remote --symref origin HEAD
git ls-remote --heads origin

Write down one clear distinction: Git can show refs/objects and local state; it cannot show your GitHub repository role, issue count, or organization policy.

7. Prediction 1: create a hosted branch ref without changing the default branch

If platform-map already exists from Lesson 02, create checkpoint-map. Before running commands, write this prediction:

Creating and pushing checkpoint-map will create a local branch/commit and a hosted branch ref. It will not change repository visibility, default branch, viewer permission, or Issues configuration.

git switch -c checkpoint-map
printf "boundary=git-ref\n" > checkpoint.txt
git add checkpoint.txt
git diff --cached -- checkpoint.txt
git commit -m "docs: record checkpoint boundary"
CHECKPOINT_OID=$(git rev-parse HEAD)
git push -u origin checkpoint-map

PowerShell equivalent for Prediction 1

git switch -c checkpoint-map
"boundary=git-ref" | Set-Content checkpoint.txt
git add checkpoint.txt
git diff --cached -- checkpoint.txt
git commit -m "docs: record checkpoint boundary"
$CHECKPOINT_OID = git rev-parse HEAD
git push -u origin checkpoint-map
"local=$(git rev-parse checkpoint-map)"
gh api -H "X-GitHub-Api-Version: 2026-03-10" 'repos/{owner}/{repo}/commits/checkpoint-map' --jq '"hosted=" + .sha'
gh repo view --json defaultBranchRef --jq '"default=" + .defaultBranchRef.name'

Verify through two independent paths:

printf 'local=%s\n' "$(git rev-parse checkpoint-map)"
gh api -H "X-GitHub-Api-Version: 2026-03-10" \
  'repos/{owner}/{repo}/commits/checkpoint-map' --jq '"hosted=" + .sha'
gh repo view --json defaultBranchRef --jq '"default=" + .defaultBranchRef.name'

The local and hosted commit IDs should match. The default branch should remain what it was before.

8. Prediction 2: create a GitHub Issue without changing Git history

This is a deliberately shallow use of Issues; Chapter 05 will teach issue management deeply. The purpose here is to prove a platform-resource boundary.

Creating an Issue will add a GitHub-hosted issue resource. It will not create a Git commit, change a branch ref, or modify the local working tree.

First capture the current commit and status:

BEFORE_ISSUE_OID=$(git rev-parse HEAD)
git status --porcelain=v1

PowerShell baseline for Prediction 2

$BEFORE_ISSUE_OID = git rev-parse HEAD
git status --porcelain=v1

Web UI path

Open Issues → New issue. Title: Checkpoint: map hosted-only state. Body: Synthetic Chapter 01 lab issue.

GitHub CLI path

gh issue create \
  --title "Checkpoint: map hosted-only state" \
  --body "Synthetic Chapter 01 lab issue."

Now verify:

test "$BEFORE_ISSUE_OID" = "$(git rev-parse HEAD)" && echo "Git commit unchanged"
git status --porcelain=v1

PowerShell verification for Prediction 2

if ($BEFORE_ISSUE_OID -eq (git rev-parse HEAD)) { "Git commit unchanged" }
git status --porcelain=v1

Then inspect the issue through the web UI or gh issue list. The hosted platform changed; Git history did not.

9. Compare observations across interfaces

10. Produce the platform-boundary diagram

Recreate this diagram in your notes and annotate every arrow with one observation from the lab:

flowchart TD
  WT["Working tree / index"] -->|git commit| LG["Local Git objects + refs"]
  LG -->|git push| HG["GitHub-hosted Git refs + objects"]
  ACCOUNT["Authenticated user"] -->|authorized API/UI action| PLATFORM["GitHub platform resources"]
  HG --> PLATFORM
  PLATFORM --> ISSUE["Issue #N"]
  PLATFORM --> PERM["Visibility / permission / settings"]
  POLICY["Organization / enterprise policy"] --> PLATFORM
          

Label the git push arrow with the checkpoint-map commit ID. Label the account/platform arrow with the issue number. This proves that one action changed Git-backed state while the other changed GitHub-only state.

11. Deployment and plan annotation

Add these lines to your evidence:

host=github.com
account_type=personal
mandatory_plan_path=GitHub Free
repository_visibility=public
enterprise_only_features_used=none
rest_api_version=2026-03-10

If you performed an optional Enterprise Cloud/GHES observation, record it separately with the exact host/deployment and GHES version where applicable. Do not mix enterprise assumptions into the mandatory GitHub.com evidence.

12. Cleanup preflight: preserve what you may want before archiving

Archiving makes a repository read-only and can be reversed. Before archiving:

1. Confirm the exact repository coordinate.
2. Confirm your local clone contains the commits you care about.
3. Save the evidence directory outside the repository.
4. Close the synthetic issue if you want a tidy final state; this is a hosted issue-state change, not a Git operation.
5. Do not delete the repository as part of a copied one-line lab command.

git status --short --branch
git log --oneline --decorate --graph --all -10
git remote -v

13. Archive the disposable repository

Use the web UI Settings flow or the CLI. The CLI command prompts for confirmation by default:

gh repo archive YOUR_USER/github-platform-lab

Read the confirmation carefully and verify the coordinate before accepting. We deliberately do not use --yes because interactive confirmation is a useful guardrail in a teaching lab.

Verify:

gh repo view YOUR_USER/github-platform-lab \
  --json nameWithOwner,isArchived,visibility \
  --jq '{repo: .nameWithOwner, archived: .isArchived, visibility}'

Expected: archived: true. The local clone and its Git history remain on your computer; GitHub's hosted repository is now archived/read-only.

14. Rollback: unarchive if you need the lab again

Archiving is reversible. If a later exercise genuinely requires this repository, restore it explicitly:

gh repo unarchive YOUR_USER/github-platform-lab

Again, verify isArchived afterward. If you choose to delete the repository instead, treat deletion as a separate destructive operation: review the current GitHub deletion documentation, confirm you have any needed backup/evidence, and use the web UI's explicit Danger Zone confirmations. Deletion is not necessary to pass this checkpoint.

15. What this adds to a production GitHub operating model

You now have a repeatable method for describing GitHub state:

1. Name the host and deployment.
2. Name the account/owner/repository coordinate.
3. Record visibility and effective role.
4. Separate Git objects/refs from GitHub-only resources.
5. Use structured UI/CLI/API/Git inspection before mutation.
6. Predict which resource will change.
7. Verify the result from an independent interface.
8. Use explicit cleanup/rollback.

This method scales directly into branch governance, pull requests, Actions, environments, packages, security products, APIs, Apps, and enterprise administration.

16. Final verification checklist

• Repository coordinate, owner type, visibility, default branch, viewer permission, and host are documented.
• UI, gh, REST, and local Git observations agree where they describe the same state.
• You predicted the checkpoint-map branch/ref change before pushing and verified the exact commit SHA.
• You predicted the Issue creation would not change Git history and verified HEAD/worktree remained unchanged.
• Your diagram distinguishes local Git, hosted Git, GitHub resources, authenticated identity, and policy.
• No token/private key/session data was recorded.
• The disposable repository was archived, or you documented why an existing pre-approved lab repository was retained.
• You know how to unarchive as rollback.

Knowledge check

17. Chapter 01 completion summary

You can now reason about GitHub as a hosted developer platform layered on Git: user identities act on repositories owned by personal or organization accounts; enterprise accounts can centralize higher-level governance; visibility and authorization are separate; plans/deployments influence feature availability; and GitHub-only resources must be observed and protected alongside Git refs/objects.

Authoritative references

• Types of GitHub accounts
• Access permissions on GitHub
• About repositories
• About versions of GitHub Docs
• GitHub CLI manual
• GitHub REST API versions
• gh repo archive
• gh repo unarchive
• gh issue create
• REST API endpoint: Get a repository
• Setting repository visibility