← back to the section

Git is a version control system: it remembers the history of code changes and lets several people work on the same project without overwriting each other. Today it is not "one of the tools" but the habitat itself: code lives in Git, tasks are closed through Git, code review happens in Git. You cannot join any team — backend, frontend, testing — without it.

your machine working directory index repository Order.javanotes.txt Order.javanotes.txt empty Order.java git add git commit C1 C2 C3 git push server (GitHub) git statustwo files changed, nothing staged yet git add Order.javaonly this file goes into the next snapshot git commit -m "fix the total"snapshot C3 is written to local history the server still has C2your C3 is invisible: commit ≠ push git pushC3 is on the server, now it is shared git add → git commit → git pushthree steps: to the index, to history, to the server

The path of one change. git add puts only the chosen file into the index — notes.txt stays in the working directory. git commit turns the index into snapshot C3 and appends it to the local chain. At that moment the server still has C2: until git push runs, nobody but you sees the work.

The problem it solves

Without version control, a project's history looks like project_final_2_fixed_NEW.zip. Questions with no answers: what changed since yesterday? who changed this line and why? how do you roll back a bad edit without losing the good ones? how do two people edit the same file?

Git answers all of them: every saved state is signed with an author, a date, and an explanation; any state can be viewed, compared, and restored; parallel work is the normal mode, not a disaster.

Snapshots, not differences

The key mental model: Git stores snapshots of the entire project. Each commit is a "photographed" state of all files plus a reference to the previous snapshot. History is a chain of snapshots you can walk through like a timeline.

An important consequence follows: a commit is cheap and instant, because unchanged files are not copied but reused. Committing often is normal and right.

The three states of a file

A file in a Git project lives in one of three places:

  • Working directory — the ordinary files you edit.
  • Index (staging area) — the commit's "anteroom": here you explicitly put what will go into the next snapshot.
  • Repository — the saved commits.
git status              # what changed and what is in the index
git add file.txt        # put a file into the index
git commit -m "explanation"  # take a snapshot from the index

The index seems like an extra step at first ("why not commit everything right away?"), but it is a precision tool: out of ten changed files you can build a commit from only the three related to the task — the history stays meaningful.

Local and remote

Git is a distributed system: a full copy of the history sits on your machine. Commits, branches, browsing history — everything works locally, without a network. A remote repository (on GitHub, GitLab, Bitbucket) is the team's synchronization point: you send your commits there (push) and take others' commits from there (pull).

git clone https://github.com/team/project.git  # copy the project to your machine
git pull   # take what's new from the server
git push   # send your commits to the server

Two practical consequences follow. First: "committed" does not yet mean "sent" — colleagues will see your work only after a push. Second: every participant holds the whole history, so losing the project is practically impossible.

Where this is used

Git is not just "handing in code". History is a debugging tool: "when did it break?" is answered by browsing recent commits, "who wrote this line and why" — by git blame, "reproduce the bug from version 2.3" — by switching to that version's tag. And all delivery automation — the CI/CD pipeline — is triggered precisely by Git events: a push to a branch builds and tests the code, a merge into the main branch deploys it.

In short

  • Git stores history as a chain of snapshot commits; a commit is cheap — commit often.
  • Three states: working directory → index (git add) → repository (git commit).
  • The index is not an extra step but a way to build a commit from one task's files only.
  • The system is distributed: the whole history is local, the server is a synchronization point.
  • Commit is not push: until git push runs, nobody sees your work.
  • git status is your compass: it always shows where you are and what has changed.