What is Git? Distributed version control, explained for beginners
Almost every job in software and cloud assumes you already know Git, and almost nobody stops to explain what it actually is. Here is the whole idea in plain words, plus your first repository built one command at a time.
New to cloud? CAMPUX is a free, build-first course. Start here →
Git is a free, open-source distributed version control system that tracks changes to files, stores the full history of a project, and lets many people work on the same code without overwriting each other. "Distributed" means every clone is a complete copy of the repository, history and all. That sentence is the whole thing in miniature. The rest of this note unpacks it slowly, because once the model clicks, the commands stop feeling like magic spells you have to memorise.
What Git actually is (and what problem it solves)
Before version control, people saved progress the way you might dread: report_final.doc, then report_final_v2.doc, then report_final_ACTUAL.doc. It works until two people edit the same file and one set of changes quietly disappears. Version control is the tool that makes that mess go away. It records every change as a distinct point in time, remembers who made it and why, and lets you go back to any earlier state without keeping a drawer full of copies.
Git, written by Linus Torvalds in 2005 to manage the Linux kernel, is the version control system that won. It watches a folder on your computer, and whenever you tell it to, it takes a snapshot of every file in that folder. A history of those snapshots is called a repository — usually shortened to "repo." The snapshots themselves are called commits, and each one knows exactly what changed since the last, so you can inspect the whole timeline of a project and step to any point on it.
The reason this matters for a career, not just for tidiness: Git is the shared language of software teams. Code review, deployment pipelines, and infrastructure-as-code all sit on top of it. Learn Git and a large part of how modern engineering teams actually work stops being opaque.
The three places your work lives: working directory, staging, commit
The single idea that makes Git click is that your files pass through three states. Miss this and Git feels random; understand it and the commands read like plain English.
The working directory is just the folder you edit in. It is the files as they exist right now on disk — the version you open in your editor. Git watches this folder but does not record anything here on its own.
The staging area (also called the index) is a holding space where you gather the exact changes you want in your next snapshot. This is the step most tools skip and Git insists on. It lets you edit ten files but commit only the three that belong together, so your history stays meaningful instead of being one giant "changed some stuff" blob.
A commit is a permanent snapshot in the repository's history, with a message describing what it does. Once you commit, that state is saved for good and you can always return to it. The flow is one direction: you edit in the working directory, you add the changes you want to staging, then you commit staging into history.
So a single change moves like this: working directory → staging area → commit. Every Git command you will meet early on is really just moving files along that line, or looking at where they currently sit.
Think of packing a box to mail. Your desk is the working directory — stuff everywhere, half of it not going in the box. The open box is the staging area: you place in only the items you actually want to send. Sealing and labelling the box is the commit — now it is a fixed, described package you can hand off and track. git add puts things in the box; git commit seals it.
Why "distributed" matters
Older version control systems were centralised: one server held the history, and your computer only had the latest files checked out. If the server went down, or you were on a train with no signal, you were stuck. You could not see history, compare versions, or save a checkpoint without talking to that one machine.
Git is distributed, and this is the word people gloss over. When you copy a Git repository — the operation is called a clone — you do not just download the current files. You get the entire history, every commit ever made, onto your own machine. Your clone is a full, standalone repository, not a thin window onto someone else's.
The practical payoffs are large. You can commit, branch, view history, and undo changes completely offline, because all of it lives locally. There is no single point of failure: if the shared server vanished tomorrow, any one clone could restore the whole project. And syncing becomes a deliberate act — you push your commits up to a shared copy when you are ready, and pull other people's down when you want them, rather than being tied to a live connection for every save.
A clone is not a download of the files. It is a copy of the whole history, and it stands on its own.
Your first repository, command by command
Enough theory. Here is the actual sequence to put a project under Git and send it to a shared host, with each line explained. Open a terminal inside your project folder and follow along. (This assumes Git is installed; on most systems git --version confirms it.)
First, turn the current folder into a Git repository:
git init
This creates a hidden .git subfolder where Git will store all history and settings. Your files are untouched; the folder is now simply being watched. You run this exactly once per project.
Next, stage your changes — move them into that "open box" so they are queued for the next commit:
git add .
The . means "everything in this folder, including subfolders." You could name a single file instead, like git add report.md, when you want to commit just that one. Nothing is saved permanently yet; you have only chosen what goes in the next snapshot.
Now seal the box — record a permanent snapshot with a short message describing it:
git commit -m "Initial commit"
The -m flag lets you write the message inline, in quotes. That message is what future-you (and your teammates) will read when scrolling the history, so describe what the change does, not "stuff." This snapshot now lives in your local repository forever.
At this point everything is on your machine only. To share it, tell Git where the shared copy lives. Create an empty repository on a host such as GitHub first, then point your local repo at its address:
git remote add origin https://github.com/your-username/your-repo.git
A remote is just a named bookmark for a repository living somewhere else. By convention the main one is called origin. This command does not move any data — it only saves the address under that name so you do not retype the URL every time.
Finally, upload your commits to the remote:
git push -u origin main
This sends your local history to origin, onto the branch named main. The -u flag sets up tracking, so that after this first push you can simply type git push and git pull and Git remembers where they go. From here the daily rhythm is small: edit files, git add, git commit -m "...", git push. That loop is most of Git, most days.
Do not read the command list and nod. Make a throwaway folder, drop a text file in it, and run the six commands above for real. Then change the file, run git add and git commit again, and look at git log to see both snapshots. Watching your own edits turn into history is what makes the working-directory-to-staging-to-commit model stick — far better than any diagram.
Git vs GitHub — not the same thing
Beginners use these words interchangeably, and it causes real confusion, so let me be blunt about it. Git is the version control program that runs on your own computer. It creates the history, stages your changes, and makes commits, all locally, with no internet required. GitHub is a website that hosts Git repositories so you can store them online, share them, and collaborate.
Put another way: Git is the tool, GitHub is one place to keep the results. In the walkthrough above, every command up to git push ran entirely on your machine with Git alone. Only the push reached out to a host. And GitHub is not the only one — GitLab and Bitbucket do the same job, and a team can even host its own. You can use Git for years and never touch GitHub; you cannot use GitHub without Git underneath it.
Where to go next
You now have the mental model that most tutorials never state plainly: files move from the working directory to staging to a commit, every clone carries the full history, and a remote is just a named copy elsewhere. That is genuinely enough to start using Git on real work today. The next things worth learning are branches — working on a change in isolation — and how to combine branches back together, which is where git merge and git rebase come in, and how syncing works in detail, including what git fetch does versus pull.
If you would rather build the skill hands-on with guided reps, the bootcamp covers this end to end. Class 17 — Git Fundamentals walks the model and the core commands, and Class 18 — Repositories and Collaboration takes you into branches, pull requests, and working with a team. Open a terminal, run git init, and you are already started.
Common questions
What is Git used for?
Git tracks changes to files over time so you can see what changed, when, and by whom, and roll back to any earlier state. Teams use it to work on the same codebase without overwriting each other, to review changes before they merge, and to keep a complete history of a project. It is the standard tool for source code, but it works on any text files.
Is Git the same as GitHub?
No. Git is the version control program that runs on your computer and stores history in a local repository. GitHub is a website that hosts Git repositories online so you can share them and collaborate. Git works fully offline without GitHub; GitHub is one of several hosts, alongside GitLab and Bitbucket, that give your repository a home on the internet.
Do I need to know how to code to use Git?
No. Git tracks any text files, so writers, sysadmins, and data analysts use it for documents, configuration, and scripts without writing application code. The core moves, editing files, staging them, and committing, are the same whether the files hold source code or plain notes. Coding makes Git more useful, but it is not a requirement to start.
Is Git hard to learn for beginners?
The everyday workflow is small: edit, add, commit, push. You can be productive with those four commands in an afternoon. Git feels hard because its deeper features, branching, merging, and rebasing, expose the model directly, and error messages assume you know it. Learn the working directory, staging area, and commit first, and the rest stops being mysterious.