Getting Started with Git: Installation and Setup

💡 Git basics don’t have to be scary — install it in minutes, configure your identity, and you’ll have a working local repository before your coffee gets cold.

Why Git Feels Overwhelming at First (And Why It Shouldn’t)

You’ve heard the word “Git” thrown around in every coding tutorial, bootcamp, and job description. And yet, somehow, the actual setup process feels weirdly underdocumented for beginners.

Here’s the thing. Git basics are genuinely simple once someone walks you through them without assuming you already know what a “working tree” is.

I remember the first time I tried to set up Git — I spent 45 minutes confused about whether I needed GitHub to use Git. Spoiler: you don’t. Git is local software. GitHub is just a place to put your Git projects online. Two different things.

Let’s fix that confusion right now.

Installing Git on Your Operating System

💡 Git installs in under two minutes on any OS — pick your platform and follow one command.

The installation process differs depending on your system, but none of them are complicated.

On Windows: Download the Git installer from git-scm.com. Run it, click through the defaults — honestly, the default settings are fine for most beginners. When the installer asks about your default editor, picking “Notepad” or “VS Code” (if you have it) is perfectly reasonable.

On macOS: Open Terminal and type git --version. If Git isn’t installed, macOS will prompt you to install it through Xcode Command Line Tools automatically. Or you can use Homebrew: brew install git. Either works.

On Linux (Ubuntu/Debian): Run sudo apt-get install git. Done. Seriously, that’s it.

After installation, open your terminal and run git --version. If you see a version number like git version 2.43.0, you’re good to go.

flowchart TD
    A[Start: Need Git?] --> B{What OS?}
    B --> C[Windows]
    B --> D[macOS]
    B --> E[Linux]
    C --> F[Download from git-scm.com\nRun installer]
    D --> G[brew install git\nor Xcode CLI tools]
    E --> H[sudo apt-get install git]
    F --> I[git --version ✓]
    G --> I
    H --> I
    I --> J[Git installed!]

Setting Up Your Git Username and Email

💡 Your Git identity is stamped on every commit you make — set it once and forget it.

Before you touch a single file, you need to tell Git who you are. This is non-negotiable. Every commit you make gets tagged with your name and email, so when you’re working with a team, everyone knows who changed what.

Run these two commands:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

The --global flag means this applies to every Git project on your machine. You can always override it per-project later by running the same commands without --global inside a specific folder.

💡 Use the same email address you’ll use for GitHub — it’s how contributions get linked to your account.

Want to double-check everything saved correctly? Run git config --list. You’ll see all your configuration settings printed out.

A friend of mine skipped this step when first learning Git and ended up with dozens of commits attributed to “undefined” in a shared repo. His team lead was not thrilled. Don’t be that person.

Initializing a Repository and Understanding the Basic Git Workflow

💡 A Git repository is just a folder that Git is watching — git init is the magic on/off switch.

Navigate to your project folder in the terminal. Then run:

git init

That’s it. Git just created a hidden .git folder inside your project directory. Everything Git needs to track your changes lives in there. Don’t delete it.

Now, the basic Git workflow follows a three-stage rhythm that’s worth burning into your brain:

• Working Directory — where you edit files normally
• Staging Area — where you prepare changes before saving them
• Repository — where Git permanently stores your snapshots (commits)

Think of it like packing a suitcase. You pull clothes from your closet (working directory), decide what to pack (staging area), then zip the bag shut (commit). You can keep adding and removing from the pile before you zip — that flexibility is the whole point.

flowchart LR
    A[Working Directory\nEdit files] -->|git add| B[Staging Area\nPrepare changes]
    B -->|git commit| C[Repository\nSaved snapshot]
    C -->|git checkout| A

Here’s a quick reference for the first commands you’ll use after git init:

Honestly, these four commands cover 80% of what you’ll do with Git in your first month. The rest builds on top of this foundation.

💡 Run git status obsessively at first — it tells you exactly where you stand and what Git is thinking.

One thing that tripped me up early: git add . stages everything in your current folder. That’s usually fine for personal projects, but get into the habit of checking git status first so you don’t accidentally commit a file with your API keys in it. (Yes, that happens. Constantly.)

The moment that setup clicks — when you run your first commit and see the confirmation message — something changes. It stops feeling like a chore and starts feeling like a superpower. You now have an undo button for your entire project.

That’s a big deal.

Related Articles

• Essential Git Commands Every Developer Should Know
• Collaborating on GitHub: Forking, Cloning, and Pull Requests
• Git Workflow for Real-World Projects

Back to Complete Guide: GitHub Tutorial for Beginners: Complete Git and GitHub Guide