What Git is

Git records the history of a folder as a series of snapshots, so you can see what changed, when, by whom and why, and go back to any earlier point. By the end of this lesson you have made a repository and your first two commits.

Why version control

Without version control, a project's history looks like this:

report.docx
report-v2.docx
report-v2-final.docx
report-v2-final-REALLY-final.docx
report-v2-final-Priya-edits.docx

Nobody knows which copy is current, what changed between them, or how to combine Priya's edits with yours. Version control solves this. A version control system keeps one folder with one current set of files, plus a full history behind it. It gives you:

• Undo for a whole project. Go back to how things were on Tuesday, for one file or for everything.
• History with reasons. Every change carries a message saying why it was made.
• Safe experiments. Try an idea on the side and throw it away if it does not work.
• Teamwork. Several people change the same project at once, and the tool combines their work.

Git is the most widely used version control system. It is free, it runs on every major operating system, and it works offline: the whole history lives on your computer.

Git is not GitHub

Git is the program on your computer. GitHub, GitLab, Bitbucket and Azure DevOps are websites that host Git repositories so people can share them. You can use Git without any of them.

Snapshots, not lists of edits

Each time you save your work into Git, it takes a snapshot: a picture of every tracked file as it is at that moment. That saved snapshot is a commit. Files that did not change are not stored again; the new snapshot points at the copy Git already has.

Every commit records:

Part	Example
A unique id, the hash	11d88dba8db94e9297aec76095b338a88b0da440, usually shortened to 11d88db
The author's name and email	Asha Rao <asha@example.com>
The date and time	Mon Nov 9 17:43:52 2026 +0530
A message	Add packing list
Its parent	The commit that came just before it

Because each commit points at its parent, the commits form a chain. That chain is the project's history:

c4906d4 ◄── 11d88db ◄── f11adbc ◄── 719f474
Add README   Add packing   Say which     Add sunglasses
             list          tickets       to packing list

The hash is calculated from the commit's contents, including its parent. Change anything in an old commit and its hash changes, and so do the hashes of every commit after it. That is how Git notices tampering and corruption, and it is why "rewriting history" (later in this track) always produces new commits.

The repository

A repository (or "repo") is a folder whose history Git tracks. Git keeps everything it knows in a hidden .git folder at the top:

trip-planner/            ← the repository
├── .git/                ← all the history, branches and settings
├── README.md
└── packing.txt

WARNING

Deleting the .git folder deletes the entire history. The files you can see stay, but every earlier version is gone. Never edit or remove files inside .git by hand.

Three places your work lives

This is the most important picture in Git. Your work moves through three places:

  Working tree              Staging area              Repository
  (files on disk)           (the index)               (commits)
 ┌──────────────┐         ┌──────────────┐         ┌──────────────┐
 │ edit files   │ git add │ the next     │  git    │ saved        │
 │ with any     │ ──────► │ commit,      │ commit  │ snapshots,   │
 │ editor       │         │ being built  │ ──────► │ with history │
 └──────────────┘         └──────────────┘         └──────────────┘
        ▲                                                  │
        └──────────── git restore / git switch ────────────┘
                   (put saved versions back on disk)

• The working tree is the files as they are on your disk right now, including edits you have not saved into Git.
• The staging area, also called the index, holds what will go into the next commit. You choose what goes in with git add.
• The repository holds the commits. git commit turns whatever is staged into a new commit.

Why a middle step? Because you rarely want to save everything at once. You might have fixed a bug and also left some debugging lines in another file. Staging lets you commit the fix and leave the rest out. The next lesson goes deeper.

Your first repository

Check that Git is installed

git --version

git version 2.53.0

Any recent version works for this track. If the command is not found: on Ubuntu or Debian install the git package (sudo apt install git); on Windows, install Git for Windows from git-scm.com, or use DhivaLabs Shell, which has Git built in.

Tell Git who you are

Every commit records an author. Set yours once (the next lesson explains why it matters):

git config --global user.name "Asha Rao"
git config --global user.email "asha@example.com"

Create the repository

mkdir trip-planner
cd trip-planner
git init -b main

Initialized empty Git repository in /home/you/trip-planner/.git/

-b main names the first branch main (branches are lesson 3). It needs Git 2.28 or newer. Without it, current Git versions still call the first branch master and print a hint about it.

Ask Git what is going on

git status is the command you will run most. It tells you which branch you are on and what has changed:

git status

On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Create a file and ask again:

echo "# Trip planner" > README.md
git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	README.md

nothing added to commit but untracked files present (use "git add" to track)

Untracked means Git sees the file but is not keeping its history yet.

Stage it and commit it

git add README.md
git status

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
	new file:   README.md

The file is now staged. Commit it with a message:

git commit -m "Add README"

[main (root-commit) c4906d4] Add README
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

c4906d4 is the start of the new commit's hash. Yours will be different, because the hash includes your name and the time. root-commit means it is the first commit, with no parent.

Add a second file and commit it the same way, then look at the history:

printf 'Passport\nTickets\nPhone charger\n' > packing.txt
git add packing.txt
git commit -m "Add packing list"
git log --oneline

11d88db Add packing list
c4906d4 Add README

git log --oneline shows one commit per line, newest on top. Plain git log shows the full hash, the author and the date as well.

The states a file can be in

git status --short (or -s) gives a compact view with a two-letter code per file. The left letter is the staging area, the right letter is the working tree:

Code	Meaning
??	Untracked: Git is not tracking this file yet
A	Added: a new file, staged
M	Modified in the working tree, not staged
M	Modified and staged
MM	Some changes staged, more changes not staged
!!	Ignored (shown only with --ignored)

A file that matches the last commit exactly does not appear at all.

See it in an app

BranchPilot shows the same three places on one screen: the Changes panel lists files under Untracked, Unstaged and Staged, the commit box makes the commit, and the commit graph shows the history. It opens repositories that already exist, so you create them with git init (or git clone) in a terminal first. See the BranchPilot beginner guide.

Check yourself

QuizWhat Git is

Question 1 of 6

What is a commit?

Score: 0

What you learned

• Version control keeps one set of files plus a full history of snapshots, each with a reason.
• A commit is a snapshot with a hash, an author, a date, a message and a parent.
• A repository is a folder with a hidden .git folder that holds the history.
• Work moves from the working tree, through the staging area, into commits.
• git init, git status, git add, git commit and git log --oneline are the first five commands.

Next steps

• Commits: stage exactly what you mean and write messages people can use
• BranchPilot beginner guide