← 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.

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 developer has a full backup of the history — losing the entire project is practically impossible.

Where this helps a backend engineer

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 lets you build precise commits.
  • The system is distributed: everything is local, the server is a synchronization point. Commit ≠ push.
  • git status is your compass: it always shows where you are and what has changed.
  • Commits and history — how to make good commits and read history.
  • Branches and merging — the main mechanism of parallel work.
  • Linux terminal commands — if the terminal itself is still unfamiliar.