GitHub Platform Foundations, Plans, Accounts, Organizations, and Repository Models: Guided Hands-On Workflow and Core Operations

1. Scenario and safety model

In this lesson you will create a disposable repository named github-platform-lab under your personal account. The mandatory path uses public visibility because it works with GitHub Free and keeps plan dependencies minimal. Put only synthetic learning content in it.

2. Preflight: inspect tools and active identity before creating anything

Start with state that cannot mutate a repository:

git --version
gh --version
gh auth status --active --hostname github.com

If gh is not installed, use the web path below. If it is installed but not authenticated, follow the official gh auth login flow locally. Do not paste tokens, recovery codes, or SSH private keys into lesson notes or prompts.

3. Create the disposable repository

Option A — GitHub web UI

1. Use the repository creation flow on GitHub.com.
2. Owner: your personal account.
3. Name: github-platform-lab.
4. Visibility: Public.
5. Initialize it with a README so a default branch exists immediately.
6. Before submitting, predict what new hosted state will exist: a repository resource plus an initial Git commit/ref.

Option B — GitHub CLI

gh repo create github-platform-lab --public --add-readme --clone

The command creates a GitHub repository owned by the active authenticated user, initializes it with a README, and clones it. It does not create an organization, team, issue, or pull request. The default branch name comes from the account/repository creation configuration, so the lesson deliberately does not assume main or master.

4. Read the repository's major surfaces in the web UI

Open the repository. GitHub's repository navigation exposes different views of the same repository resource. Exact tab visibility can depend on enabled features, permissions, viewport, and product changes, so treat names as current navigation—not as a permanent wire protocol.

Your first task is not to click everything. Record which surfaces exist and what resource each surface represents.

5. Inspect hosted repository state with structured GitHub CLI output

From any directory, replace YOUR_USER with your account name:

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

Prefer this machine-readable form to scraping the CLI's decorative default output. Important fields:

• nameWithOwner identifies the resource unambiguously.
• visibility tells you public/private/internal hosted visibility.
• defaultBranchRef.name reports the configured default branch without assuming its name.
• isInOrganization distinguishes personal from organization ownership.
• viewerPermission reports the effective repository role GitHub exposes for the authenticated viewer.

6. Inspect the same resource through the REST API

Inside the cloned repository, gh api can substitute {owner} and {repo} from repository context. Explicitly select the current API version:

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, private, archived, has_issues, has_projects, owner: .owner.login}'

As of this lesson's verification date, GitHub's REST API supports 2026-03-10 and 2022-11-28. Requests without an explicit version default to an older supported version, which is precisely why production integrations should select a version intentionally and test upgrades.

If you use raw curl against a public repository, you can omit authentication, but unauthenticated requests have a much lower primary rate limit. The course does not need a personal access token for this chapter.

7. Connect GitHub-hosted state to a local Git clone

If you created the repository in the web UI, clone it now:

gh repo clone YOUR_USER/github-platform-lab
cd github-platform-lab

If you used --clone during creation, enter the directory. Then inspect local state before changing it:

git remote -v
git branch --show-current
git status --short --branch
git log --oneline --decorate --graph --all -5
git ls-remote --symref origin HEAD

git remote -v reads local remote configuration. git branch --show-current reads local HEAD state. git ls-remote --symref origin HEAD asks the remote repository what symbolic ref its HEAD advertises. This is Git protocol state, not an Issues or permissions query.

8. Make one small Git change and prove causality

Configure a safe lab identity locally if needed. The email is deliberately non-routable and is commit metadata, not a GitHub credential.

git config user.name "Learner Example"
git config user.email "learner@example.invalid"
git switch -c platform-map
printf "GitHub platform lab\n" > platform-map.txt
git add platform-map.txt
git diff --cached -- platform-map.txt
git commit -m "docs: add platform map marker"
LOCAL_OID=$(git rev-parse HEAD)
printf 'local commit: %s\n' "$LOCAL_OID"
git push -u origin platform-map

PowerShell equivalent for the file/variable steps

git config user.name "Learner Example"
git config user.email "learner@example.invalid"
git switch -c platform-map
"GitHub platform lab" | Set-Content platform-map.txt
git add platform-map.txt
git diff --cached -- platform-map.txt
git commit -m "docs: add platform map marker"
$LOCAL_OID = git rev-parse HEAD
"local commit: $LOCAL_OID"
git push -u origin platform-map

Prediction before the push: the local commit already exists; the push should create/update the hosted platform-map branch ref and transfer any missing objects. It should not change the repository default branch, create an issue, change visibility, or grant a permission.

Verify independently:

gh api \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  'repos/{owner}/{repo}/commits/platform-map' --jq .sha

git rev-parse HEAD

The two commit IDs should match. The same commit identity is now observable locally and through GitHub's hosted API.

9. Inspect access without granting anything

For a personal repository you own, GitHub will normally expose your viewer permission as administrative. Do not turn this into an exercise in adding random collaborators. The goal is to observe the boundary, not widen it.

gh repo view --json nameWithOwner,viewerPermission,isInOrganization \
  --jq '{repo: .nameWithOwner, permission: .viewerPermission, organizationOwned: .isInOrganization}'

If you already have access to a disposable organization, you may optionally inspect its repository's People/Teams access settings without changing them. That extension is not required. Organization role management belongs to later governance chapters.

10. Build a hosted-state record

Create a local file named hosted-state.txt outside the repository or keep it as notes. Record:

• Repository coordinate.
• Account owner type: personal or organization.
• Visibility.
• Default branch.
• Your effective permission.
• Whether Issues and Projects are enabled.
• Current pushed branch platform-map and its commit ID.
• GitHub host (github.com for the mandatory path).

This is the beginning of an operational habit: capture resource identity and state before modifying settings.

11. UI, CLI, API, and Git: choose the interface that matches the question

12. Challenge: choose the right surface before touching the repository

For each question, name the interface/resource you would inspect first. Do not run a mutation.

1. “Which commit is my local branch on?”
2. “Can this account administer repository settings?”
3. “Which branch does GitHub consider the default?”
4. “Did a push create a new remote branch?”
5. “Is Issues enabled for this repository?”
6. “Why can I read a public repository but not push?”

A strong answer names both the state and the trust boundary—for example, “use gh repo view --json viewerPermission because authorization is GitHub-hosted state, not a local Git property.”

13. Small failure drills

Wrong directory

gh repo view --json nameWithOwner

If you run this outside a repository and do not supply a repository argument, the CLI may not know which repository you mean. The correction is not “re-authenticate”; it is to target OWNER/REPO explicitly or enter the correct clone.

Wrong GitHub host

If you work with GHES, gh auth status --hostname github.com checks the public GitHub.com host, not your employer's server. Host identity is part of the target. Use the actual enterprise hostname and matching documentation.

14. Verification checklist

• The lab repository is disposable and contains no sensitive data.
• You know its exact OWNER/REPO, visibility, and default branch.
• You inspected authentication without printing a token.
• You captured structured gh repo view output rather than parsing decorative output.
• You used an explicitly versioned REST request.
• You can explain what the platform-map push changed and what it did not change.
• The local and hosted commit ID for platform-map match.

Knowledge check

15. Summary

You created a free-compatible disposable repository and observed one resource through four views: web UI, GitHub CLI, REST API, and local Git. The key operating habit is now concrete: inspect resource identity, default branch, visibility, permission, and refs before changing anything; then verify mutations through an independent view.

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 auth status
• gh repo create
• gh repo clone
• gh repo view
• gh api
• REST API endpoint: Get a repository