Install & first-time config

The last lesson ended on a promise: introduce yourself to Git so your name lands on every snapshot. That introduction is literally two commands — but the error you hit before running them, and the reason Git is so insistent, is worth understanding once. Start with getting Git onto your machine at all.

Install Git

Pick the instructions for your platform. The goal is just to get Git on your PATH — keep this step fast.

macOS

The quickest path is Homebrew:

brew install git

No Homebrew? Run git --version in Terminal. macOS will offer to install the Xcode Command Line Tools automatically, which bundles a perfectly adequate Git.

Debian / Ubuntu Linux

sudo apt update && sudo apt install git

Windows

Download and run the installer from git-scm.com. The defaults are fine. This installs Git Bash and adds Git to your PATH.

Verify the installation

git --version

git version 2.44.0

The exact version number doesn’t matter — any recent 2.x release works for everything in these lessons.

Why Git needs your identity

Every Git commit stores two pieces of metadata that are baked into the commit hash and travel with the repository forever:

• Author name — who wrote the change
• Author email — how to reach them

This is not optional. Git enforces it because commit history is meant to be trustworthy and attributable. When you push to GitHub or share a repo with a team, every commit carries this identity permanently. You cannot edit it after the fact without rewriting history (which breaks other people’s clones).

Because of this, Git refuses to create a commit until these two values are set.

First-time setup

Run these three commands once, right after installing Git. Replace the placeholder values with your own.

git config --global user.name "Ada Lovelace"
git config --global user.email "ada@example.com"
git config --global init.defaultBranch main

What each line does:

• user.name — the human-readable name embedded in every commit you make on this machine.
• user.email — the email embedded in every commit. GitHub uses this to link commits to your account avatar.
• init.defaultBranch main — makes git init create a branch named main instead of the legacy master. Most platforms default to main today; setting this avoids a warning on every new repo.

Optional: set your preferred editor

Git opens a text editor when you run git commit without a -m flag. The default is vi, which surprises many people. Override it:

git config --global core.editor "code --wait"

Replace code --wait with nano, vim, emacs --wait, or whatever you prefer.

Inspect your config

After setting values, verify them:

git config --list

user.name=Ada Lovelace
user.email=ada@example.com
init.defaultbranch=main
core.editor=code --wait

To read a single key:

git config user.email

ada@example.com

Config scopes: system, global, local

Git reads config from three files and merges them at runtime. More specific always wins.

A common real-world pattern: set your personal email globally, then override it with your work email locally inside each work repo:

cd ~/work/company-project
git config --local user.email "ada@company.com"

Now commits in that repo use your work email; commits everywhere else still use your personal email.

What you can skip for now

The git config command has dozens of options (color.ui, pull.rebase, merge.tool, etc.). Ignore them until a workflow problem makes one relevant. The three commands in the “First-time setup” section above are the only ones you need before your first commit.

In one breath

Install Git however your platform makes easiest (brew, apt, or the Windows installer), confirm it with git --version, then run three one-time git config --global commands: user.name and user.email — which Git bakes permanently into every commit and refuses to commit without — plus init.defaultBranch main. Git merges config from three scopes, system → global → local, where the most specific always wins, so you set your personal identity globally and override it with a work email locally inside work repos. Everything else git config offers can wait until a real problem asks for it.

Practice

Before the quiz, trace the scopes: you set user.email globally to your personal address, then inside ~/work/acme you run git config --local user.email "you@acme.com". You commit once in ~/work/acme and once in ~/personal/blog. Which email lands on each commit, and which file — ~/.gitconfig or the repo’s .git/config — held the value that decided the work one?

A question to carry forward

Git is installed, and it knows your name — so your next git commit will succeed instead of erroring. But succeed at what, exactly? When you change three files and commit, does Git save all three? Only the ones you point at? Here is the surprise that trips up nearly everyone: between the files you are editing and the history Git permanently records, there sits a third place in the middle — a staging area you load by hand — and a commit snapshots that, not your working folder directly. Those three places are the single most clarifying idea in all of Git, and they are the next lesson.