What Is Git? A Beginner's Guide to Version Control

If you've ever saved a file as 'final', 'final-v2' and 'final-really-this-time', you already understand the problem Git solves. It keeps a tidy, searchable history of every change to a project, so nothing gets overwritten by mistake.

I've written this guide from the official Pro Git book at git-scm.com, which is the reference most developers learn from. It's aimed at beginners, including writers, designers and business owners who work alongside developers and keep hearing the word.

Git defined in simple terms

Git is a version control system. That's a tool that records changes to files over time so you can recall specific versions later. Developers use it mostly for code, but it works for any set of files.

The Pro Git book explains that Git thinks of its data as a series of snapshots of a miniature filesystem. Each time you save the state of your project, which Git calls a commit, it records what all your files look like at that moment. If a file hasn't changed, Git stores only a link to the previous identical file instead of keeping a second copy.

Why version control exists in the first place

Pro Git describes how version control grew up in three stages, and each one fixed a problem with the last:

Type	How it works	Weak spot
Local	A simple database on one computer tracks changes	It doesn't help you collaborate with people on other systems
Centralised	One server holds all the versioned files and everyone checks files out from it	A single point of failure: if the server goes down, nobody can collaborate or save versioned changes
Distributed	Every user mirrors the whole repository, including its full history	Designed to remove that single point of failure

Git belongs to the third group. The book notes that if a server dies, any client's copy can be copied back up to restore it, so every clone is really a full backup of the data.

How Git keeps working when you're offline

One of Git's best-known traits is that most of its operations need only local files and resources. Browsing the project history reads from the local database, so it feels almost instant. You can work on a train or a plane, commit your changes to your local copy and upload them later. The book contrasts this with older systems where little works without a server connection.

The three states a Git file can be in

Git's workflow makes sense once you know its three states. Pro Git defines them like this:

• Modified. You've changed the file but haven't committed it yet.
• Staged. You've marked the current version so it goes into your next commit.
• Committed. The data is safely stored in your local database.

Those states correspond to three areas: the working tree where you edit files, the staging area that lists what goes into the next commit, and the Git directory where Git stores the project's history. A simple analogy is packing a parcel. You gather items on the table (modified), put the ones you want into the box (staged) and then seal and label it (committed).

Your first Git repository in two commands

A repository is the project folder that Git tracks. Pro Git gives two ways to get one. Run git init inside an existing folder to start tracking it, or run git clone with a web address to copy an existing repository, full history included.

The basic rhythm after that is:

1. Edit your files as normal.
2. Use git add to stage the files you want in the next snapshot.
3. Use git commit with a short message to record the snapshot permanently in your local history.

The message matters more than people expect. A clear one-line description of what changed makes the history useful to the next person, who is often you in six months.

Git's built-in safety net

Pro Git says everything in Git is checksummed before it's stored and then referred to by that checksum. That means Git can detect corruption or loss in transit, and it's impossible to change a file's contents without Git knowing. The checksum is a 40-character hexadecimal string made with the SHA-1 hash.

The book also notes that nearly every Git action only adds data to the database, which makes it hard to do something that can't be undone. Uncommitted changes can still be lost, but once a snapshot is committed it's very difficult to lose, especially if you regularly push your work to another repository.

Git and the other building blocks of the web

Git is only one piece of how a website or app gets built and kept running. Another is the system that turns a domain name into a server address, which I explain in what DNS is. It's also worth knowing about the weaknesses developers guard against when they review each other's commits, such as SQL injection.

Share your developer knowledge

Plenty of people are still learning tools like Git, and clear explanations from working developers are always welcome.

Developers who like to write can browse developer blogs that take contributor articles.

Frequently asked questions

Is Git the same as GitHub?

No. Git is the version control tool itself. Hosting services are separate websites that store Git repositories online. The Pro Git book treats Git as a tool you can use fully on your own computer.

Do I need to be a developer to use Git?

No. It tracks any set of files, although it's mostly used for code and has a command-line style that takes some getting used to.

What's a commit?

A commit is a saved snapshot of your project at a moment in time, with a message describing what changed.

Can I use Git without an internet connection?

Yes. Pro Git says most Git operations need only local files and resources, so you can commit offline and upload later.

What does 'staging' mean in Git?

Staging means marking which changes you want included in your next commit, so you can group related changes together.