Your First Local Repository: Getting Git Running on Your Machine

You have read about what Git is and why it exists. Now it is time to open a terminal and actually use it. This article walks you through every step — from getting Git onto your computer to making your very first permanent snapshot of a project — and explains what is happening at each stage, not just which keys to press.

Step 1 — Installing Git

Git is a program that lives on your computer, not in a browser. Before you can use it, you need to install it. The good news is that on many systems it is already there. Open a terminal and type:

If you get a "command not found" error instead, you need to install Git. The diagram below shows what is happening when you install it, and where it ends up on your machine.

Once the installation finishes, run git --version again to confirm it worked. If you see a version number, you are ready.

Step 2 — Telling Git Who You Are

Before Git will let you make your first commit, it needs to know your name and email address. This is not optional. Every commit you ever make will be permanently stamped with this information — it is how, in a shared project, everyone can see who made which change and when. Think of it as signing your work before it goes into the archive.

You only need to do this once per computer. The --global flag means "apply this to every repository on this machine."

The third command — init.defaultBranch main — tells Git that every new repository should start on a branch called main. This arrived in Git 2.28 and has since become the modern standard. Without it, older versions of Git default to a branch called master. Setting it now avoids any inconsistency later.

Step 3 — Creating Your First Repository

A repository is just a regular folder that you have asked Git to watch over. Create one, step into it, and hand Git the keys with a single command: git init.

What just happened? Git created a hidden folder called .git inside your project. You will never need to open it, but it is worth knowing it is there. It holds Git's entire memory of your project: every snapshot you ever take, every commit message, every author name. If you delete the .git folder, Git forgets everything — your actual files remain, but the history is gone. If you copy the project folder somewhere else, the .git folder comes along and the history comes with it.

Step 4 — The Core Workflow: Edit, Stage, Commit

Here is the rhythm you will repeat for the rest of your career with Git. Every change you make goes through three stages: you edit a file in your working directory, you stage it to prepare it for a snapshot, and you commit it to record that snapshot permanently. Start by creating a file:

Reading the Room: git status

Before doing anything else, ask Git what it sees. This is the command you will run more than any other — before staging, after staging, after committing, whenever you feel uncertain about where things stand.

"Untracked" means Git can see the file but is not watching it yet. It exists in your working directory, but Git has made no promise to remember it. Notice also that Git itself suggests the next step: "use git add to track." The output of git status is always trying to tell you something useful — read it carefully.

Moving to the Staging Area: git add

Staging is the step that surprises most beginners. Why not just commit directly? The reason is that the staging area gives you control. It lets you choose exactly which changes become part of the next snapshot, even if you have touched multiple files. You might have fixed a bug and added a new feature at the same time — staging lets you turn those into two clean, separate commits instead of one confusing lump.

The colour shift from red to green in the terminal output is Git's visual cue that something has moved between areas. The file has not been saved to history yet — but it is ready to be.

Taking the Snapshot: git commit

Now you record the snapshot permanently. The -m flag lets you write the commit message inline. A commit message is a note to your future self — treat it seriously.

A good commit message uses the imperative mood — write it as if giving the project an instruction. "Add README with project title" reads as a clear, purposeful action. "added stuff" or "fix" tells your future self absolutely nothing. In six months, when something breaks and you are scanning through the history trying to find the culprit, you will be grateful for every commit message that actually explains what changed and why.

Reading Your History: git log

Every commit is recorded chronologically. At any point you can ask Git to show you the full history of the project so far.

The long string of letters and numbers is the commit hash — a unique fingerprint computed from everything in that snapshot: the file contents, the message, the author, the date, and the hash of the previous commit. Change any single character anywhere and the hash would be completely different. This is what makes Git's history tamper-proof.

Putting It All Together: a Real Walkthrough

Here is the complete sequence — building up a small project from scratch, making two commits, and reading the final history. Every command is one you just learned.

In about ten commands you created a version-controlled project with a clean, readable history. Both commits are permanent. Both can be recovered. Both tell a clear story of what changed and why.

Three Mistakes Every Beginner Makes

Knowing the commands is not enough — knowing where things go wrong is just as valuable. Here are the three stumbles that catch almost everyone at this stage.

Nothing Is Ever Really Lost

One thing worth knowing before you go further: once something is committed, it is exceptionally hard to lose. Even if you later run a command that seems destructive — deleting a branch, doing a hard reset — Git keeps a private journal called the reflog that records every position HEAD has ever been in. If you commit your work regularly, you have a safety net that most people do not even know exists.

The lesson is simple: commit early and commit often. Uncommitted work sitting only in your working directory is the only work that is genuinely fragile. Every time you commit, you add another save point to your timeline — and save points are free.