What is Git?
Git is a free, open-source distributed version control system designed to track changes in source code (or any set of files) over time, coordinate work between many people, and let you safely experiment without fear of losing earlier work. It is, by a very wide margin, the most widely used version control system in the world — almost every modern software project, from a one-person side hobby to operating systems used by billions, is built on top of Git.
If you have ever saved files as report-final.docx, report-final-v2.docx, report-final-v2-REALLY-FINAL.docx, you have already invented a crude version control system. Git replaces that whole mess with a single tidy timeline of every change to every file, kept inside an invisible folder called .git next to your project. You can move forward and backward through that timeline, fork it into parallel branches, share it with teammates, and merge their branches back into yours — all without leaving a trail of duplicate files on disk.
A short, plain-English definition
Git is a tool that records snapshots of your project, lets many people work on the same project at the same time without stepping on each other, and gives you a complete history you can rewind, compare, branch, and share.
Three ideas to unpack from that definition:
Snapshots, not diffs. Most older tools store the changes between versions. Git stores a complete picture of every tracked file at every commit. That sounds wasteful but Git is clever about deduplicating identical content, so it is actually very efficient.
Distributed, not central. Every developer has the entire history on their own machine. You can commit, branch, and view the log without a network connection. There is no single server that owns the truth — though teams usually pick one (like GitHub) to act as a shared meeting point.
A timeline you can navigate. Each snapshot is called a commit and gets a unique ID (a long hex hash). Commits form a graph — usually a tree of branches — that you can move through with simple commands.
What can you actually do with Git?
Save versions of your work — every meaningful change becomes a commit you can return to later.
Try ideas safely — create a branch, experiment, throw the branch away if it does not work out. Your main project is untouched.
Collaborate with others — share branches, review each other’s changes, merge them into a shared codebase.
Find when a bug was introduced — tools like
git bisectcan binary-search through history to pinpoint the commit that broke something.Audit who changed what and why —
git logandgit blameshow, line by line, who wrote each piece of code and the reasoning recorded in the commit message.Recover from mistakes — deleted a file, broke main, force-pushed at 2 a.m.? Git keeps almost everything in the reflog for around 90 days. Recovery is usually possible.
What makes Git distinctive?
Speed. Git was designed to be fast on huge codebases. Most operations happen against your local copy with no network calls, so they finish in milliseconds.
Branching is cheap. Creating a branch is just writing a 41-byte pointer. Branches are encouraged — feature branches, fix branches, throwaway experiments — they cost almost nothing.
Data integrity. Every file, directory, and commit is identified by a SHA-1 hash of its content. If even one byte changes, the hash changes. You cannot silently corrupt history.
Works offline. Commit, branch, view history, diff, search — all without a network. You sync to a remote only when you choose to.
Huge ecosystem. GitHub, GitLab, Bitbucket, every IDE’s built-in source control, hundreds of GUI clients, and basically every CI/CD pipeline understands Git.
A quick first taste
Below is the shortest possible Git story. Open a terminal in an empty folder and you can follow along:
First Git session
# Tell Git who you are (you only do this once per machine) git config --global user.name "Your Name" git config --global user.email "you@example.com" # Make a new folder and turn it into a Git repository mkdir my-project cd my-project git init # Create a file echo "# My Project" > README.md # See what Git thinks about it git status # Stage the file so Git knows you want to record it git add README.md # Commit — take a snapshot with a message describing the change git commit -m "Initial commit" # Look at the history git log
That is the entire fundamental loop: edit → git add → git commit. Everything else in Git — branches, merges, remotes, rebasing, history rewriting — is built on top of this basic rhythm.
Git, GitHub, the staging area, and the working tree — what is what?
Beginners often hit a wall of confusing names. Here is the map:
Git is the program — a command-line tool you install on your computer.
A repository (repo) is a folder Git is tracking. It contains your files plus a hidden
.gitdirectory with all the history.The working tree (or working directory) is the files you actually see and edit.
The staging area (or index) is a holding pen where you collect the changes you want in the next commit.
A commit is a snapshot of staged changes plus a message and author info, recorded in history.
A branch is a movable pointer to a commit. The default branch is usually called
main(older repos usemaster).A remote is another copy of the repo — typically on a server. The default remote is usually called
origin.GitHub, GitLab, Bitbucket are hosting services that host Git remotes and add a website, code review, issue tracker, and CI on top. They are not Git itself — they are services built around it.
Why learn Git?
It is the industry-standard version control system. Knowing Git is effectively a requirement for any software engineering job.
It is how open-source software is built. Every contribution to React, Linux, VS Code, TensorFlow — all of them — goes through Git and a pull request.
It saves you from yourself. Once you are comfortable with branches and commits, you stop being afraid to try things, because nothing is permanent.
It scales from solo projects to massive teams. The same five commands you learn today are the ones used by the engineers maintaining the Linux kernel.
It plays nicely with everything else. CI systems, deployment platforms, code review tools, IDEs — they all speak Git.
The rest of this tutorial walks you through Git from these first commands, through branches and merging, into collaboration on GitHub, and on to the advanced features (rebasing, submodules, hooks, internals) used by professional teams every day.