Git

In short: A distributed version control system that tracks changes to source code over time.

In more detail: Every change is stored as a “commit”, which lets a project’s complete history be reconstructed, compared, and reverted if needed. “Distributed” means every local copy contains the full history, not just a central server. GitHub and GitLab are hosting platforms for Git repositories, but not the same thing as Git itself.

In Depth

Origin

Git was written by Linus Torvalds (creator of Linux) in just ten days in 2005, after Linux kernel development was no longer allowed to use the proprietary system BitKeeper for free. The requirements came directly from the practice of one of the world’s largest open-source projects: thousands of simultaneous contributors, high speed even with huge histories, and guaranteed integrity (no tampered commit should be able to go unnoticed). Git achieves the latter by identifying every commit via a cryptographic hash of its entire content AND the hash of its predecessor — a chain where any later change to the history immediately gives itself away through a different hash.

Snapshots instead of diffs

A common misconception: Git does NOT store only the differences (diffs) from the previous commit per commit, but a complete snapshot of the entire project state each time (unchanged files are internally treated only as a reference to already-stored content, not duplicated). This makes operations like checking out any arbitrary old state very fast — Git doesn’t have to apply a long chain of diffs one after another, but loads the matching snapshot directly.

The basic workflow

git add file.txt                       # add a change to the "staging area"
git commit -m "Fixed calculation bug"  # create a snapshot
git push origin main                   # upload local commits to the remote

The staging area (also called the “index”) is a Git peculiarity: changes in the working directory aren’t committed automatically, but are deliberately marked for the next commit via git add — this allows bundling only a thematically related subset of many changed files into one commit, instead of necessarily committing everything at once.

Branches: cheap, movable pointers

A branch is technically nothing more than a movable pointer (a small text file with a commit hash) to a specific point in the history — creating a new branch is therefore a practically free operation, no matter how large the repository is. This enables the workflow common in practice: branching off main for every feature/bugfix, working on it in isolation, and merging the changes back via git merge or as a pull request. If two branches change the same lines of the same file differently, a merge conflict arises that Git can’t resolve automatically.

Distributed instead of centralised

Older version control systems like SVN or CVS were centralised: only the central server had the full history, local copies only contained the current state. With Git, EVERY local copy contains the project’s complete history. This has two important consequences: first, almost all Git operations (commit, switching branches, searching the complete log history, comparing old versions) work entirely offline — only push/pull/fetch need a connection to the remote. Second, the system is robust against server failures: if the central repository is lost, every collaborator with a cloned repository still has a complete, recoverable copy of the entire history.

Git is not GitHub

A common misconception among beginners: GitHub and GitLab are hosting platforms FOR Git repositories (with additional features like pull requests, issue tracking, CI/CD), but not Git itself — Git works completely even without any of these platforms, purely locally or with a self-hosted server.

See also: GitHub, GitLab, Merge Conflicts, Conventional Commits