How Git Works: The 4 Areas and the Commands That Move Code Between Them
Most of us learn Git backwards. We memorise a sequence -git add, git commit, git push -and repeat it on faith. Then something unexpected happens, and the only fix we trust is deleting the folder and cloning again.
There’s a simpler way in.
Git isn’t a pile of commands. It’s four places your code can live, and every command you’ll ever type does one job: it moves your code from one of those places to another. Get the four places straight in your head and the commands stop feeling arbitrary -they start feeling obvious.
What Git actually is
Git is a version control tool. Two things follow from that:
- It records the full history of a project -every change, who made it, when, and why.
- It lets a whole team work on the same codebase at once without anybody overwriting anybody else.
That’s the entire pitch. Everything below is mechanics.
The 4 areas of a Git project
1. Working Directory -your desk
- The actual folder on your machine, the one you open in VS Code.
- Every edit you make lands here first.
- Git can see these changes, but it isn’t recording them into history yet.
2. Staging Area -the envelope
- Also called the index.
- Holds the changes you’ve deliberately chosen for your next commit.
- This is the step beginners find pointless -until the day they edit five files and need to commit only two of them.
3. Local Repository -your filing cabinet
- The hidden .git folder inside your project.
- Stores your complete commit history: every message, author, and timestamp.
- Because it’s on your machine, you can browse history, compare versions, or roll back to an earlier state with no internet at all.
4. Remote Repository -the team’s shared drive
- The copy hosted on GitHub, GitLab, or Bitbucket.
- The shared source of truth everyone pushes to and pulls from.
- Your work only becomes visible to teammates once it reaches here.
That’s the whole model: Working Directory → Staging Area → Local Repository → Remote Repository. Every command below is just a trip along that line, in one direction or the other.
The commands, in the order you’ll actually meet them
Starting a project
- git init -turns an ordinary folder into a Git repository. For projects you’re starting from nothing.
- git clone -copies an existing remote repository, full history included, onto your machine. For projects that already live on GitHub.
# brand-new project
mkdir my-project && cd my-project
git init
# project that already exists
git clone https://github.com/username/project.git
New project → init. Existing project → clone. You never need both.
Saving your work
- git add -moves changes from the working directory into the staging area, marking them as ready.
- git commit -takes everything staged and writes it permanently into your local repository.
git add index.html # stage one file
git add . # stage everything changed
git commit -m “Add login form validation”
Get Dhanush Kumar R’s stories in your inbox
Join Medium for free to get updates from this writer.
The commit message is for future-you. Six months from now, “fix stuff” will tell you nothing.
Checking where you stand
- git status -shows what’s changed in your working directory and what’s currently staged. When you’re confused about what Git is doing, this is almost always the answer.
- git log -displays your commit history: who committed, when, and with what message.
git status
git log — oneline — graph # a far more readable history
Sharing with your team
- git push -uploads your local commits to the remote so teammates can see them.
- git fetch -downloads new work from the remote but does not touch your files. A safe “let me look first” command.
- git merge -folds those downloaded changes into your current branch.
- git pull -does both in one shot.
git push origin main
git pull origin main
git pull = git fetch + git merge. Use pull for speed, fetch when you’d rather look before you leap.
Working on features safely
You rarely build a feature straight onto the main branch. You branch off, build in isolation, merge back when it works.
- git branch -creates a new line of work.
- git switch (or the older git checkout) -moves you onto it.
- git merge -brings the finished feature back into main.
git switch -c feature-login # create and switch in one line
# …build the feature…
git switch main
git merge feature-login
git switch is the newer, narrower command. git checkout does the same job plus half a dozen unrelated ones -which is exactly why it confuses people.
Seeing exactly what changed
- git diff -shows the specific lines that changed, not just which files.
git diff # working directory vs staging area
git diff — staged # staging area vs last commit
git diff main feature-login # one branch vs another
Quick reference
A typical day, start to finish
git pull origin main # get the latest team code
git switch -c feature-signup # branch off for your work
# …edit files…
git status # what did I change?
git diff # what exactly did I change?
git add . # stage it
git commit -m “Add signup form” # save it locally
git push origin feature-signup # share it
Nine commands. That’s roughly 90% of everyday Git.
Things worth remembering
- Every command is a move between four areas. Working directory, staging area, local repo, remote repo -that’s the whole map.
- When something breaks, don’t hunt for a magic command. Ask instead: where is my code right now, and where does it need to go?
- git status is your compass. It tells you which area your changes are sitting in, and the right next command usually becomes obvious.
- Commits are local until you push. Committing is not sharing.
- fetch is safe, pull is fast. One only looks; the other looks and merges.
- Branch for anything non-trivial. It costs one command and saves you from breaking main.
- Write commit messages for the person who reads them later. That person is usually you.
Start with the map, not the command list. Git gets a lot less intimidating very quickly.
