Git and GitHub / Basic: the local Git model / Lesson 1

Git repositories, snapshots, and GitHub

Build an accurate local model before using a hosting platform or sharing changes with collaborators.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish Git objects and references from GitHub collaboration features.
Create and inspect an isolated temporary repository.

Separate the version-control system from the service

Git is a distributed version-control system that records project history locally. GitHub hosts Git repositories and adds pull requests, reviews, issues, access controls, and automation. A local commit does not automatically appear on GitHub, and deleting a local branch does not necessarily remove a hosted branch. You can learn most Git mechanics without a network connection. Treat the hosting platform as a collaboration layer with its own permissions and policies. This distinction helps explain why a correct local command may still be rejected by a server rule or missing account authorization.

Think in snapshots and relationships

A commit identifies a snapshot through a tree and records metadata plus parent relationships. File contents are stored as blob objects; directories are represented through trees. Branches are movable references to commits, and history is a directed acyclic graph of parent links. Git can display a patch between snapshots, but a commit is not merely a list of line edits. Object identifiers depend on content and metadata under the repository’s object format, so do not assume every installation uses one fixed hash length. The graph and content model explain both cheap branching and why rewritten commits receive new identities.

Start inside a disposable lab directory

All command examples in this course belong to isolated temporary repositories. The setup below creates a new directory and initializes a main branch; it does not connect a remote or modify an existing project. The explicit initial branch option requires Git 2.28 or later, while switch and restore were introduced earlier in Git 2.23. Check the installed manual when an option is unavailable. Shell examples assume a POSIX-style environment; Windows users can use Git Bash or translate filesystem commands carefully. Never paste setup commands into an important working directory without checking the path.

bash Create a new local-only laboratory repository

lab_dir=$(mktemp -d)
cd "$lab_dir"
git init --initial-branch=main
git rev-parse --show-toplevel

The final command prints the temporary repository’s absolute path, which varies by machine. No remote exists and no commit has been created. This contextual shell excerpt is non-runnable in the renderer; practical validation uses a separately managed temporary directory.

Keep identity and configuration scope explicit

Commit author information is metadata, not authentication. A name and email in a commit do not prove control of a GitHub account or permission to push. Configuration can come from system, global, repository, and command scopes; inspect origins before diagnosing surprising behavior. For labs, use command-scoped synthetic identity rather than changing a real global profile. Avoid printing complete credential configuration or embedding tokens in remote URLs. Repository settings can affect line endings, signing, hooks, and merge behavior, so a reproducible lab records the relevant assumptions instead of inheriting unexplained machine defaults.

bash Create a first snapshot using synthetic command-scoped identity

printf 'A local notebook\n' > notes.txt
git add -- notes.txt
git -c user.name="Lab Author" -c user.email="lab@example.invalid" commit -m "Create notebook"
git rev-list --count HEAD

Run only after the temporary setup. The final count is 1 because the lab contains one reachable commit. The commit summary includes a generated object id that is intentionally not predicted here. No global or actual project configuration is changed.

Verify the model before sharing

Use status to inspect local file state, log to inspect reachable commits, and branch or symbolic-reference inspection to understand the current name. A repository can contain objects not currently reachable from a branch, and a branch can exist before it has a first commit in a special unborn state. Do not infer that the project is backed up merely because a commit exists locally. Backups, hosted remotes, and access recovery are separate responsibilities. Build a habit of identifying location, current reference, and uncommitted work before any command that moves history or files.

Common errors and fixes

A local commit is missing from GitHub

Why it happens: Local history and hosted synchronization were conflated.
How to fix it: Inspect local refs and the intended sharing workflow without assuming automatic upload.
Prevent it next time: Distinguish commit, fetch, and push responsibilities.

Commits use an unexpected author

Why it happens: Identity came from an inherited configuration scope.
How to fix it: Inspect relevant configuration origins and use synthetic command scope in labs.
Prevent it next time: Verify author metadata before publishing.

A tutorial option is unavailable

Why it happens: The installed Git version predates that interface.
How to fix it: Check git --version and the installed command manual.
Prevent it next time: Record the lab’s version and shell assumptions.

Check your understanding

1. Explain why a commit email is not proof that the author can push to a repository.

Show worked solution

Author metadata is stored in the commit, while remote authentication and authorization are evaluated separately by the service. A signed commit can add a verifiable identity claim under a trust policy, but it still does not grant repository write access.

2. A branch name points to a commit. Does creating another branch duplicate every file?