Course 02 · Git

How Git growsa history

Git becomes much easier when you stop imagining folders being copied and start seeing snapshots connected into a tree. This guide makes that tree visible.

Beginner 18 min 5 experiments No prerequisites

01 · A map before the commands

Learn one picture in five moves.

We will start with the value Git gives you, then reveal the machinery only when it answers a useful question. Every later concept is a small change to the same commit tree.

The destination: look at a graph and predict what a command will move.

01
Save meaningful checkpointsWhy history is more useful than files named final-final-2.
why
02
Move changes through three placesWorking tree → staging area → repository.
local
03
Grow more than one futureBranches are movable labels, not copied projects.
branch
04
Combine those futuresMerge preserves the fork; rebase redraws one side.
history
05
Exchange history with other repositoriesFetch, integrate, and push without confusing local and remote.
share

02 · Why Git is useful

Git lets a project have memory—and parallel futures.

A commit gives a change a durable name and context. A branch lets you try an idea without disturbing another line of work. A remote lets several people exchange those histories.

The real payoff is not merely “backup.” It is the freedom to experiment, compare, explain, review, and recover.

↺RecoverReturn to a known checkpoint.

⑂ExperimentGrow an idea on its own branch.

◎ExplainRecord why each coherent change exists.

⇄CollaborateExchange histories and review differences.

03 · Move one change

Git gives a change three local places to be.

Edit a file, choose it for the next snapshot, then commit that snapshot to history. The staging area is the deliberate boundary between “everything I changed” and “the change I mean to record.”

Use the controls in order.

One file, three places

Clean repository

Working treeThe files you can edit

app.jsmatches commit A

clean

Staging areaThe proposed next snapshot

Nothing selected yet.

RepositoryCommitted snapshots

Initial interfacemain · HEAD

$ git status

Nothing to commit. Your working tree matches commit A.

04 · Read the graph

A commit is a snapshot with a parent.

Most commits point to one earlier commit. Follow those parent links and you get history. The long hexadecimal commit ID is Git's permanent name for that snapshot.

A branch such as main is only a movable label pointing at one commit. HEAD tells Git which branch—or occasionally which commit—you currently have checked out.

Commit C stores a project snapshot, metadata, and the identity of parent B.

The idea to keep

Git stores snapshots. Parent links make history. Branches and HEAD are labels that move.

Branch simulator

A branch is not another folder.

It is a lightweight pointer to a commit. Creating one does not copy the project; committing while it is checked out simply moves that pointer forward.

Start on main

Step 0 of 4

Two commits exist. main and HEAD both point to B.

main points to B

$ git log --oneline --graph

Nothing has diverged yet: A ← B, with main checked out.

what creation does

Add one pointer

git switch -c feature creates a label at the current commit and makes HEAD refer to it.

what committing does

Move that pointer

The new commit points back to the previous one. Only the checked-out branch advances.

what switching does

Restore a snapshot

Git updates the working tree to match the commit named by the branch you switch to.

History laboratory

Merge and rebase solve the same shape differently.

Both can integrate work from one branch with another. The important difference is the history they leave behind.

MERGE · preserve the fork

Create a commit with two parents.

The existing commits keep their identities. A new merge commit records that main and feature were joined here.

Original commits stayTopology stays visibleNew merge commit

before

git merge feature→

after

What changesA merge commit is added.

What history says“These two lines met here.”

Good default whenThe branch is shared or its shape matters.

Conflict experiment

A conflict is a question, not a catastrophe.

Git can combine different files and different lines automatically. When two histories change the same region differently, Git stops and asks which meaning should survive.

Resolve the highlighted line.

mainnav.js

12const label = "Explore";

featurenav.js

12const label = "Discover";

nav.js · conflict

needs a human decision

<<<<<<< main
const label = "Explore";
=======
const label = "Discover";
>>>>>>> feature

$ git status

Both branches changed line 12. Git has preserved both versions for you to resolve.

The idea to keep

Merge preserves the shape. Rebase rewrites one line into new commits. Conflicts can happen during either.

Repository exchange

“Remote” means another repository, not the real one.

Your repository is complete: it has commits, branches, and history. A remote such as origin is another repository whose state you can observe and exchange commits with.

The remote is one commit ahead

Step 0 of 4

your computerlocal repository

main → B

origin/main → B

You have commits A and B. Your last observation of origin also points to B.

hosting serviceorigin

ABC

main → C

Someone else pushed C. Nothing on your computer changes until you communicate.

Local knowledge is stale

$ git status

Your repository cannot know C exists until it talks to origin.

git fetch

Download new commits and update remote-tracking labels such as origin/main. Your branch and files stay put.

git pull

Fetch, then immediately integrate into the current branch—using merge or rebase depending on configuration.

git push

Upload commits and ask the remote branch to move forward. It can refuse if the remote has history you lack.

A calm everyday loop

Inspect before you move history.

A small habit prevents a surprising number of Git emergencies: ask where you are, make one coherent change, inspect it, then exchange history deliberately.

Later lessons can build on this picture to explain undoing with restore, reset, and revert; pausing with stash; naming releases with tags; and recovering with the reflog.

01git statusWhich branch? What changed?
02git diffIs the change what I intended?
03git add …Which pieces belong together?
04git commitWhat useful checkpoint did I make?
05git fetchWhat changed elsewhere?
06git pushShare only after integrating safely.

The whole model

Snapshots form a graph. Branches name positions. HEAD chooses your position. Fetch and push exchange the graph.