The Git guide

Git makes more sense
when you see the model.

Git is not really a collection of commands. It is a way of recording snapshots of a project and connecting those snapshots together. Once that picture clicks, the terminology becomes much less mysterious.

01 · Repository

What is a Git repository?

A repository is a project together with the history Git keeps for it. The hidden .git directory contains Git's internal information: commits, references, configuration and the data needed to reconstruct previous versions.

Think of it as: Your project + its complete Git history.
02 · Commit

A commit is a snapshot.

A commit records a version of your project at a particular point in time. It also contains metadata such as the author, message and links to the commit's parent snapshot.

That means a history is a chain — or, with branches and merges, a graph — of snapshots.

$ git log --oneline
8f31a2d Add conflict editor
4bc19ef Improve status view
91a73c1 Initial Git Lizard prototype
03 · Branch

A branch is a movable name for a line of history.

A branch does not copy your project. It is essentially a name pointing at a commit. Creating a branch gives you a separate line of development while the existing history remains intact.

Example: main → stable history  ·  feature/login → your new work
05 · Staging

The staging area is your next snapshot.

When you edit a file, the working tree changes. When you stage it, you tell Git which version of that file should go into the next commit.

Working treeYour current files
Staging areaWhat the next commit will contain
CommitThe saved snapshot
06 · Remote

A remote is another copy of the repository's history.

A remote such as a GitHub repository gives your local repository somewhere to exchange commits with. The remote is not your project itself — your local repository is still a complete Git repository.

That distinction explains why you can commit without an internet connection.

07 · Merge

Merging joins two lines of history.

Suppose main and feature/login have both moved forward. A merge combines the histories so the changes from the feature can become part of the target branch.

If both branches changed the same part of a file in incompatible ways, Git cannot safely choose for you. That is a merge conflict.

ours → change A
────────────
theirs → change B
You decide what the final code should be.
08 · Push & pull

Push sends commits. Pull brings history in.

Push sends commits from your local repository to a remote. Pull gets changes from the remote and integrates them into your current history.

Simple mental model: Commit locally → push your commits → pull other people's commits.
The big picture

Put the pieces together.

You edit files in your working tree. You stage the changes you want. You commit a snapshot. Branches give those snapshots different lines of development. HEAD tells you where you are. Remotes let repositories exchange history. Merges bring lines back together.

working tree
staging
commit
branch history

That is the core of Git. The commands are interfaces to this model.