Installing and Configuring Git
Before you can commit a single line of history, Git needs to be installed and told who you are. Installation varies by operating system, but the configuration model is consistent everywhere: Git reads settings from a layered set of configuration files, letting you set defaults machine-wide, per-user, or per-repository. Getting this setup right up front — correct identity, a usable editor, and sensible defaults — avoids a class of confusing early mistakes, like commits attributed to the wrong email address or being dropped into an unfamiliar text editor when writing a commit message.
Cricket analogy: Before a player can step onto the field, they need their kit sorted and their name correctly registered on the team sheet; Git needs installing and your identity configured first, since a wrongly registered name leads to commits (like scorecard entries) credited to the wrong player.
Installing Git
On macOS, Git is often available via Xcode Command Line Tools, or can be installed more explicitly with a package manager like Homebrew (brew install git). On Linux, it comes from the distribution's package manager (apt install git on Debian/Ubuntu, dnf install git on Fedora). On Windows, the most common route is Git for Windows, which bundles Git Bash — a Unix-like shell — alongside the git executable, or installing via a package manager like winget or Chocolatey. After installation, git --version confirms Git is on your PATH and reports the installed version.
Cricket analogy: Different cricket boards have different registration routes — some countries fast-track via a national academy (like Homebrew), others go through a formal board pathway (like a Linux package manager) — but every player ends up officially registered and able to check their status, just as git --version confirms the install.
# macOS (Homebrew)
brew install git
# Debian/Ubuntu
sudo apt update && sudo apt install git
# Fedora
sudo dnf install git
# Windows (winget)
winget install --id Git.Git -e --source winget
# Verify installation on any platform
git --versionThe Three Configuration Levels
Git configuration is layered across three scopes, each stored in a different file, with more specific scopes overriding broader ones: --system (applies to every user on the machine, stored in /etc/gitconfig), --global (applies to all repositories for the current user, stored in ~/.gitconfig), and --local (applies only to the current repository, stored in .git/config, and is the default scope when no flag is given). This layering lets you set a personal email address globally but override it with a work email address locally in a specific work repository.
Cricket analogy: A board sets a nationwide dress code for every team (system scope), a franchise sets its own kit rules for every player it fields (global scope), and a specific match might require an away-kit exception overriding both (local scope) — layered rules where the most specific wins.
# Set identity globally (used for every repo unless overridden)
git config --global user.name "Ada Lovelace"
git config --global user.email "[email protected]"
# Override the email for one specific work repository
cd ~/projects/work-repo
git config --local user.email "[email protected]"
# Set a default branch name and preferred editor
git config --global init.defaultBranch main
git config --global core.editor "code --wait"
# View the effective configuration and where each value came from
git config --list --show-originGit config values are resolved most-specific-wins: local overrides global, which overrides system. This is analogous to CSS specificity — a narrower, more targeted rule beats a broader default.
Useful Defaults Worth Setting
Beyond identity, a handful of settings save recurring friction: core.editor determines what opens when Git needs a message from you (for commits, rebases, or tag annotations) — many developers set this to their code editor's CLI wrapper instead of the default (often Vim, which is unfamiliar to newcomers). init.defaultBranch sets the name used for a repository's first branch when running git init (commonly set to main). pull.rebase controls whether git pull merges or rebases incoming changes. Aliases (git config --global alias.co checkout) let you shorten frequently typed commands.
Cricket analogy: A team decides which analyst reviews footage first (like core.editor), which format is the default fixture type when a new season starts (like init.defaultBranch), and whether a rain-affected match defaults to D/L recalculation or a straight replay (like pull.rebase); a shorthand call-sign for a common fielding drill (like an alias) saves time.
If core.editor is left at its default and you are unfamiliar with Vim, an unexpected commit message prompt can feel like being trapped — you can always exit without saving by pressing Esc then typing :q! and pressing Enter. Set a friendlier editor early to avoid this.
- Install Git via your platform's package manager (Homebrew, apt, dnf) or Git for Windows, then confirm with git --version.
- Configuration is layered: --system (machine-wide), --global (per-user), and --local (per-repository, most specific wins).
- Always set user.name and user.email before committing — this identity is baked permanently into every commit you make.
- core.editor and init.defaultBranch are high-value settings to configure early to avoid friction.
- git config --list --show-origin reveals the effective value of every setting and which file it came from.
- Local config (.git/config) is useful for overriding identity or behavior on a per-project basis, such as using a work email.
Practice what you learned
1. Which Git configuration scope takes precedence when the same setting is defined in more than one place?
2. Why must user.name and user.email be configured before making commits?
3. What does the command `git config --global core.editor "code --wait"` accomplish?
4. Where is the --system level Git configuration typically stored?
5. Which command reveals both the effective value of a Git config setting and which file it was set in?
Was this page helpful?
You May Also Like
What Is Git?
An overview of Git as a distributed version control system, its origin, design goals, and the core concepts that distinguish it from other tools.
Initializing a Repository
How to create a new Git repository with git init, what actually gets created inside the .git directory, and how this differs from cloning an existing one.
.gitignore and Clean Repositories
Learn how .gitignore patterns keep build artifacts, secrets, and local config out of version control, and how to handle already-tracked files that should be ignored.
Git Quick Reference
A condensed, practical cheat sheet of the Git commands you'll reach for daily, grouped by task, with just enough context to use each one correctly.
Related Reading
Related Study Notes in Software Engineering
Browse all study notesMicroservices Study Notes
Software Architecture · 30 topics
Software EngineeringTesting & TDD Study Notes
Software Testing · 30 topics
Software EngineeringDesign Patterns Study Notes
Software Design · 30 topics
Software EngineeringSoftware Engineering Study Notes
Python · 75 topics
Software EngineeringSystem Design Study Notes
Architecture · 46 topics