Git & GitHub Fundamentals · Module 01 of 12

Version control and the Git model

Understand why distributed version control exists and how the working tree, index, commits and references fit together.

Learning objectives

By the end of this module, you should be able to:

Explain the problem version control solves.
Distinguish the working tree, staging area and repository.
Describe commits, branches and HEAD without treating a branch as a directory.

Why version control exists

Source code changes over time and across people. Git records snapshots, authorship and relationships between changes so teams can inspect, compare, recover and collaborate instead of copying folders such as final-v2-really-final.

Git is distributed

A normal clone contains repository history and references locally. Most everyday history inspection, branching and committing works without contacting a server. A hosting service such as GitHub adds shared remotes, review, permissions and collaboration features.

Working tree → index → commit

The working tree is what you edit. The index (staging area) is the proposed content for the next commit. A commit records a snapshot plus metadata and a parent relationship. HEAD normally names the currently checked-out branch.

Worked examples

See the idea in practice.

Watch the three states

mkdir -p git-model-lab && cd git-model-lab
git init -b main
printf "one\n" > notes.txt
git status --short
git add notes.txt
git status --short

The first status shows an untracked file.
After git add, the file is staged for the next commit.
No remote server is needed for these local operations.

Hands-on lab

Lab — See working tree and index state

Goal: Create a repository and observe an untracked file becoming staged.

Before you start

Git 2.23 or newer is recommended so the labs can use git switch and git restore.
Run labs in a disposable working directory; the included validator creates and removes its own temporary repository.

STEP 1

Create an isolated repository

mkdir -p ~/gnu-git-labs/module01 && cd ~/gnu-git-labs/module01
git init -b main

STEP 2

Create content

printf "GNU Group Git Fundamentals\n" > README.md
git status --short

STEP 3

Stage it

git add README.md
git status --short

STEP 4

Inspect staged content

git diff --cached

Verify

README.md changes from untracked to staged.
git diff --cached shows the staged addition.

Expected outcome

A Git repository exists with main as the initial branch.
The staged snapshot is ready to become a commit.

If it fails

If git init -b is unavailable, update Git or use git init followed by git branch -M main.
If status is empty, confirm you are inside the intended repository.

Real-world connection

Every later Git workflow depends on knowing which state a change occupies before you publish it.

Avoid these traps

Common mistakes

Thinking git add uploads a file to GitHub.
Treating a branch as a duplicate folder.
Skipping git status before important operations.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What does git add change?

It updates the index/staging area with content for the next commit.

2Does a local commit require GitHub?

No. Git can commit locally without any remote.

3What does HEAD normally identify?

The currently checked-out branch/reference and therefore its current commit.