Ana now has Git installed on her laptop, but before typing her first command she needs the vocabulary. Git has a lexicon of its own — dense and very precise: each word (repository, index, HEAD, branch, remote) names one specific thing, and using a term loosely is the front door to confusion. The words are also ordinary English pressed into narrow technical service, so it is easy to believe you understand a term when you only recognise it.

This lesson is a reasoned glossary. We are not going to run operations — that comes in module 2 — but to define what each term means and how it relates to the rest. The goal is that when module 3 tells you to "merge Bruno's branch into main", every word in that sentence has a sharp meaning in your head.

1. Git's three areas
2. The three states of a file
3. The essential glossary
4. References: HEAD, branches and tags
5. Collaboration: remotes, clones and forks
6. Integration: merge and rebase
7. Vocabulary and the commands behind it
8. How all the terms fit together

All work with Git happens in three distinct places. Understanding that separation is 50 % of understanding Git.

This is the folder you see in the file browser: for Ana, the task-manager folder with index.html, styles.css, app.js and README.md. They are ordinary files, which you can open and edit with any program. Git does not interfere with them.

It holds one single version of the project: the one you are editing right now.

This is an intermediate zone that accumulates whatever will make up the next commit. Physically it is a binary file inside .git called index — which is why this zone goes by staging area, index or cache interchangeably, three names for the same thing.

Its reason to exist is control. Without it, committing would mean "save everything I have touched". With it, Ana can have modified five files and decide that only three of them, or even only certain lines of one file, form a change that stands on its own. The result is clean commits, each with a single intention.

This is the hidden .git folder inside the project. It holds the entire history: every commit, every version of every file, all the branches and tags, the local configuration and the references to the remotes.

Two practical consequences:

• Copy the project folder with its .git and you take the whole project along with its history.
• Delete .git and the history disappears, leaving an ordinary folder of files. The current files survive; nothing else does.

As a corollary of the three areas, any file in a Git project is in one of these states.

An example with Ana's folder, still without running any commands:

• Ana creates README.md in a freshly created Git project → the file is untracked.
• Ana stages it → it becomes staged.
• Ana commits → it becomes committed. It is now tracked and clean.
• Ana adds a line to README.md → it is modified again.

One file can be in two states at once: if Ana stages a change and then edits the file again, part of it is staged and part is modified but unstaged. This is bewildering at first and makes perfect sense once you see that the three areas hold independent versions.

This is the lesson's reference table. Come back to it whenever a term looks unfamiliar in later lessons.

Three of them deserve a paragraph of their own, because they cause the most confusion.

Commit. It is not "saving the file". It is recording a snapshot of the entire project at a specific moment, together with metadata: who made it, when, with what message and which earlier commit it starts from. It is identified by a hash such as a3f5c9e2b1d4..., shortened in practice to the first seven characters (a3f5c9e). Once created, it is immutable.

The word also works as a noun and a verb: you make a commit (create the snapshot) and you commit a change (record it). Both senses appear constantly, and which one is meant is almost always clear from the sentence — but the noun is the thing stored in .git, and the verb is the act of storing it.

Branch. Intuitively it is "a parallel line of development". Technically it is far simpler: a text file holding the hash of a commit. When Ana commits a change while on the main branch, Git updates that file so it points at the new commit. That is why creating a branch in Git is instant: it writes forty-one bytes to disk. Module 3 develops this in full.

HEAD. It is the answer to "where am I?". Normally HEAD points at a branch, and that branch points at a commit. When you switch branches, what changes is HEAD.

There is a special case called detached HEAD: HEAD pointing straight at a commit instead of at a branch. It happens when you position yourself at a specific point in the history to inspect it. It is not an error, although the message Git prints is alarming the first time. Module 3 covers it.

All three are references (refs): readable names that point at commits. What separates them is their behaviour.

An example with task-manager, told as a story rather than as commands:

• Ana works on the main branch. HEAD points at main.
• Bruno creates the form-validation branch to add validation to the form in index.html and works there. Bruno's branch moves forward; main stays where it was.
• When the application is released for the first time, the team puts the v1.0 tag on that commit. That tag will never move again: it will always point at exactly what was released.

Annotated tags are the recommendation for released versions, because they record who released what and when. Module 5 devotes a whole lesson to the subject.

These three terms describe how one repository relates to others. Module 4 puts them to work; here we only define them.

Remote. A repository other than yours that you synchronise work with. It is not "the server": it is any other Git repository, which may live on GitHub, on a company server or even in another folder on your own disk. One repository can have several remotes, each with a short name. By convention, the main one is called origin.

Clone. A complete copy of a repository: all the history, all the branches, all the tags. When Bruno clones the task-manager repository, he will hold exactly the same information as Ana, and Git will automatically set up the origin remote pointing at the place he cloned from.

Fork. A platform concept, not a Git one. It is a copy of someone else's repository under your own account on GitHub, GitLab or similar, which lets you work on it without having write access to the original. It is the basis of the open source contribution flow, covered in module 7.

The four verbs that will be in constant use from module 4 onwards:

The distinction between fetch and pull is the one that trips up beginners most: fetch is always safe because it modifies nothing of yours; pull can trigger merges and conflicts.

Two ways of bringing two lines of development together. We only define them here; module 3 deals with merging and module 5 with rebasing.

Merge. Brings one branch's changes into another by creating a new commit — the merge commit — that has two parents: the last commit of each branch. The history keeps the real shape of what happened: two lines that diverged and came back together.

Rebase. Takes a branch's commits and reapplies them one by one onto a different base, as though the work had been done from the most recent state all along. The result is a linear history with no visible fork. In exchange, the original commits are replaced by new ones with different hashes: it is a rewriting of the history.

Conflict. Both merging and rebasing can end in a conflict: it happens when the same lines of a file have been changed differently on the two sides, and Git cannot decide which is right. It is neither an error nor a failure: it is Git asking for a human decision. If Bruno and Carla modify the same rule in styles.css, there will be a conflict; if Bruno touches styles.css and Carla app.js, Git integrates both without intervention.

Git's command names are terse and its vocabulary reuses everyday words with narrow meanings. This table closes the gap between the word you would say out loud and the command that performs it.

A note on how people actually talk. In a real team you will hear all of these verbed, abbreviated and stretched: "I've committed it", "just cherry-pick it", "let's squash and merge", "open a PR", "your branch is behind". None of it is wrong in conversation. This course uses the precise term first and lets the shorthand appear afterwards, so that you recognise both.

To close, a mental map that puts every term in its place:

And the sentence that sums up everything above, applied to our project:

In her task-manager repository, Ana edits files in her working tree, stages the changes she wants to group together in the staging area and creates a commit that is recorded in .git for good. HEAD tells her which branch she is working on; that branch advances with every commit. When they release a version, they add a tag. Bruno clones the repository from the remote called origin, works on a branch of his own and, when he is done, his work is merged with Ana's.

If that sentence reads clearly from end to end, the lesson has done its job.

• Confusing "saving the file" with "committing". Saving in the editor only writes to disk; Git knows nothing about it until you stage and commit. They are two unrelated operations.
• Treating the staging area as a nuisance. At first it looks like one bureaucratic step too many. It is exactly the opposite: it is what lets each commit carry a single intention instead of being a junk drawer. Its value becomes obvious the moment you have changes from three different tasks mixed together in your folder.
• Thinking a branch is a copy of the folder. It is not. It is a forty-one-byte pointer. This confusion, inherited from SVN, makes people avoid creating branches for fear of "duplicating the project".
• Using "fork" and "clone" as synonyms. Cloning brings a copy onto your machine (that's Git). Forking copies the repository into your account on the server (that's the platform). The usual sequence is to fork and then clone your fork.
• Reading "checkout" as "commit". checkout means "position yourself at", never "save". It is a dangerous false friend, because in some centralised systems it meant "lock a file for editing".
• Reading a conflict as a failure. A conflict means Git has correctly spotted that two people changed the same thing and is asking you to decide. Seeing one is a sign that the system works.
• Tip: come back to this lesson. There is no need to memorise the table today. Keep it to hand and reread it at the start of each new module; the terms settle with use.

Ana has her task-manager repository with index.html, styles.css, app.js and README.md committed. Over an afternoon's work she does the following, in this order:

1. Edits styles.css to change the background colour.
2. Stages styles.css.
3. Creates a new file, personal-notes.txt.
4. Edits app.js to add task deletion.
5. Edits styles.css again to adjust a margin.

State which state each of the five files is in at the end of the afternoon. Watch out for step 5.

Rewrite these five pieces of shop-floor jargon in precise terms using the lesson's terminology, and say which module of the course each operation belongs to:

1. "Fork the repo and then clone it down."
2. "Just stage the CSS, keep the JS out of the commit."
3. "I pulled and got conflicts in app.js."
4. "Tag 1.0 on master."
5. "Rebase your branch onto main before you merge."

Say whether each statement is true or false and explain why:

1. If I delete the .git folder, I lose my project's files.
2. A tag moves automatically when I make a new commit.
3. git fetch can cause a merge conflict.
4. A file can be staged and modified at the same time.
5. A clone holds less information than the original repository.
6. HEAD always points at a branch.

Solution to Exercise 1

The interesting case is styles.css: the version in the staging area (with the new colour, without the margin) and the one in the working tree (with both changes) are different. If Ana committed right now, the margin adjustment would not go into the commit.

Solution to Exercise 2

1. "Make a copy of the repository in your own account (fork) and then clone it onto your machine." → Fork: module 7. Cloning: module 2 and module 4.
2. "Stage only the CSS file; leave the JavaScript out of the commit." → Module 2.
3. "I pulled the remote's changes and merge conflicts appeared in app.js." → Pulling: module 4. Conflicts: module 3.
4. "Put a tag named v1.0 on the last commit of the main branch." → Module 5.
5. "Rebase your branch onto main before merging it." → Rebase: module 5. Merge: module 3.

Solution to Exercise 3

1. False. The working tree files are ordinary files and they are still there. What you lose is the entire history: commits, branches, tags and local configuration. The project becomes an ordinary folder.
2. False. That is a branch's behaviour, advancing with every commit. A tag is fixed by definition: it always points at the same commit. That is precisely what makes it useful for marking released versions.
3. False. fetch only downloads information from the remote and updates the remote-tracking references; it touches neither your working tree nor your local branches, so it cannot cause conflicts. The one that can is pull, because it downloads and integrates.
4. True. It is exactly the case of styles.css in exercise 1. The three areas hold independent versions of the same file, so there can be differences between the repository and the staging area as well as between the staging area and the working tree.
5. False. A clone holds the complete history: every commit, branch and tag. That is precisely the defining feature of a distributed system, as we saw in the lesson What Is Git?. (Deliberately partial clones — shallow clones — do exist, but they are the exception rather than the rule; module 10 covers them.)
6. False. HEAD usually points at a branch, but it can point straight at a commit: that is the detached HEAD state, which happens when you position yourself at a specific point in the history. Module 3 covers it.

You now have the vocabulary that holds up the rest of the course. The key concepts are three areas (working tree, staging area and repository) and three states (modified, staged, committed), which together explain the basic workflow. On top of them sit the references — branches, tags and HEAD — which are names pointing at commits, plus the collaboration concepts (remote, clone, fork) and the integration ones (merge, rebase, conflict), all developed in modules 3, 4 and 5.

You have also seen how each word maps to the command that carries it out, which matters because Git's command names are terse and its terminology reuses everyday words with very narrow meanings.

We now know what things are called. The next question is what they look like inside: what exactly Git stores when you commit, why the identifiers are forty-character hashes, and what lives inside .git. That is the content of The Git Data Model, the lesson that supplies the mental model every following module rests on.