Install Git and Make Your First Commit

In the previous post we covered the mental model behind Git — the three areas, the distributed history, and the core vocabulary. This guide is hands-on: by the end you will have Git installed, properly configured, and a real repository with several commits in it.

Modern Git is required — version 2.30 or newer. Everything below assumes that.

Step 1: Install Git

On Windows

1. Visit git-scm.com/download/win. The download will start automatically.
2. Run the installer. The default options are sensible for beginners — accept them.
3. One option to confirm: on the “Adjusting your PATH environment” screen, leave the recommended option selected (Git from the command line and also from 3rd-party software). This makes the git command available in Command Prompt and PowerShell.

The Windows installer also includes Git Bash — a Unix-style terminal that ships with git, ssh, and the standard Unix utilities. It is the recommended terminal for Git on Windows, since most documentation assumes Unix-style commands.

On macOS

The cleanest path is Homebrew:

brew install git

If you do not have Homebrew, install it first with the one-liner on brew.sh. Alternatively, simply running git --version in the Terminal on a fresh Mac will prompt you to install the Xcode Command Line Tools, which include Git. Either approach is fine.

On Linux

# Ubuntu / Debian
sudo apt update && sudo apt install git

# Fedora
sudo dnf install git

# Arch Linux
sudo pacman -S git

Verify the installation

Open a terminal — Command Prompt, PowerShell, Git Bash, or Terminal — and run:

git --version

You should see something like git version 2.43.0. Anything from 2.30 onwards will work for everything in this series. If the number is older, update before continuing.

Step 2: Configure your identity

Git attaches a name and email to every commit. Set them once globally and Git will use them for every repository on your machine.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Use the email address you plan to use on GitHub later — it makes attribution work correctly when you push commits.

While you are here, set two more sensible defaults:

git config --global init.defaultBranch main
git config --global pull.rebase false

The first makes new repositories start on a branch called main rather than the older master. The second sets the default git pull behaviour to a merge rather than a rebase — safer for beginners. We will return to merge vs. rebase in the fourth post.

Check the values at any time with:

git config --global --list

Step 3: Create your first repository

Make a folder for the project and step into it. The commands below work on macOS, Linux, and Git Bash on Windows; in PowerShell, replace mkdir -p with plain mkdir.

mkdir -p ~/code/first-repo
cd ~/code/first-repo

Initialise the repository:

git init

You should see something like:

Initialized empty Git repository in /Users/you/code/first-repo/.git/

That .git folder is the repository. Everything Git knows about your project — every commit, branch, and configuration value — lives inside it. Do not edit or delete it manually. If you ever want to “un-Git” a project, deleting .git is how you do it; the working files are untouched.

Confirm the current state with:

git status

The output will look roughly like:

On branch main

No commits yet

nothing to commit (create/copy files to add)

Three things to read here: you are on the branch main, there are no commits yet, and Git is waiting for you to add something.

Step 4: Create a file and check the status

Create a simple text file:

echo "# First Repo" > README.md

(On Windows PowerShell, use "# First Repo" | Out-File README.md -Encoding utf8.)

Run git status again:

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present

Git has noticed the new file but is not yet tracking it. New files do not enter Git’s awareness automatically — you have to ask for them with git add. This is deliberate: many files in a project (build outputs, secrets, editor backups) should never be committed, and Git defaults to ignoring everything until told otherwise.

Step 5: Stage and commit

Move the file into the staging area:

git add README.md

Check again:

git status

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

The file has moved from “untracked” to “changes to be committed” — that is, it has crossed from the working tree into the staging area. Now record it as a commit:

git commit -m "Initial commit"

Output:

[main (root-commit) a1b2c3d] Initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

That short string a1b2c3d is the start of the commit’s SHA-1 hash — the unique 40-character identifier for this commit. Git lets you refer to a commit by any unambiguous prefix of its hash, which is why short prefixes are so common in documentation.

Step 6: View the history

git log

commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> main)
Author: Your Name <you@example.com>
Date:   Sat Jun 14 10:00:00 2026 +0000

    Initial commit

A more compact view that is often more useful:

git log --oneline

a1b2c3d (HEAD -> main) Initial commit

HEAD is Git’s term for “where you are right now” — the commit that the working tree was last based on. It currently points at main, which currently points at this one commit. As you add more commits, HEAD and main will move forward together.

Reading diffs

Between editing a file and staging it, you can ask Git what has changed:

git diff

This shows differences between the working tree and the staging area — that is, everything you have edited but not yet added. Lines starting with - were removed; lines with + were added.

After you have staged but not yet committed, use:

git diff --staged

…to see what is currently queued for the next commit. These two commands together are how experienced Git users sanity-check their work before every commit.

Writing good commit messages

A commit message is a note to your future self and to your collaborators. Follow these conventions:

• First line: a short summary, ≤ 50 characters, in the imperative mood (“Add login form”, not “Added login form” or “Adds login form”).
• Blank line.
• Body (optional): more detail — what changed and why. The “what” can usually be read from the diff; the “why” cannot.

To write a longer message, run git commit with no -m flag and Git will open your configured editor.

A good rule: each commit should be the smallest self-contained, working change. If your commit message has the word “and” in it, you probably want two commits.

Ignoring files

Most projects contain files you never want Git to track — compiled binaries, dependency folders (node_modules, venv), editor settings, secrets. Create a file called .gitignore in the root of the repository and list patterns one per line:

# Dependencies
node_modules/

# Build output
dist/
build/

# Environment files
.env
.env.local

# Editor
.vscode/
.idea/

# OS
.DS_Store
Thumbs.db

Commit the .gitignore itself — it is part of the project. From then on, anything matching those patterns will be silently skipped by git status and git add.

A complete cheat sheet for this post

git init                       # start a new repository in the current folder
git status                     # show working tree and staging state
git diff                       # show unstaged changes
git diff --staged              # show staged changes
git add <file>                 # stage a file
git add .                      # stage every change in the current directory
git commit -m "Message"        # create a commit from the staged changes
git log                        # full commit history
git log --oneline              # compact one-line history
git config --global --list     # show your global configuration

These ten commands cover roughly 70% of day-to-day Git use.

Recap

You now have:

• A modern Git installation (≥ 2.30) configured with your name and email.
• A working repository on your machine.
• Experience with the full edit → status → diff → add → commit → log cycle.
• A .gitignore that keeps junk out of your history.

Next steps

The next post introduces branches — the feature that turns Git from a glorified backup tool into a serious development environment. You will learn to create branches, switch between them, and merge their work back together.

→ Next: Git Branching — A Beginner’s Guide

Questions or feedback? Email codeloomdevv@gmail.com.