Topic 02

Installing and Configuring Git

Concept

Installing Git puts the git binary on your machine; configuring it sets the identity, editor, and defaults that Git stamps onto everything you do. The configuration matters more than the install: without user.name and user.email set, every commit you make is mislabelled, and on a shared repository that misattribution is baked into history permanently.

The whole setup is a five-minute task you do once per machine, and getting it right up front saves you from a class of confusing problems later — commits attributed to the wrong person, branch-name mismatches with your remote, and entire files showing as changed because of line endings.

Installation per Platform

On Linux you install from the package manager — apt install git on Debian and Ubuntu, dnf install git on Fedora. On macOS, Homebrew's brew install git gives you a current build (the Xcode command-line tools ship an older one). On Windows, the official installer bundles Git plus Git Bash, a Unix-like shell that spares you the differences of the native command prompt. Confirm any install with git --version.

Identity Configuration

The first two commands on any new machine set who you are: git config --global user.name "Your Name" and git config --global user.email "you@example.com". Git copies these into every commit's author and committer fields. The email is not cosmetic — GitHub links a commit to your account by matching that email, so a wrong or unset address means commits that do not show up as yours.

Fixing a wrong identity after the fact is genuinely painful. The author of a commit is part of the data the commit hash is computed from, so changing it means rewriting history and re-hashing every affected commit. Set it correctly once and the problem never arises.

Config Scopes and Precedence

Git reads configuration from three levels. System config applies to every user on the machine; global config lives in ~/.gitconfig and applies to you; local config lives in .git/config and applies to one repository. When the same key is set at more than one level, the most specific wins — local overrides global overrides system. This is why a per-repo email can override your global identity for a work repository without touching your default.

When a setting behaves unexpectedly, git config --list --show-origin prints every value alongside the file it came from, which turns "why is my email wrong here" into a one-command answer.

Defaults Worth Setting Immediately

A handful of defaults are worth setting the moment Git is installed. init.defaultBranch main makes new repositories start on main rather than master, matching what your remote expects. core.editor picks the editor Git opens for commit messages. pull.rebase decides whether git pull merges or rebases — choose deliberately rather than relying on the version-dependent default. On Windows, core.autocrlf controls line-ending conversion, and getting it wrong makes entire files appear changed.

Common Mistakes

Leaving user.email unset or wrong and then pushing dozens of commits — they show as the wrong author, GitHub will not attribute them to you, and fixing it requires rewriting history.
Relying on the old default branch name on older Git, so new repos start on master and mismatch a remote whose default is main, producing a confusing first push.
The wrong core.autocrlf on Windows, which rewrites line endings so every file shows as modified and every diff is unreadable noise.
Configuring a plaintext credential store and committing the config, leaking a token straight into the repository.
Setting a value at the wrong scope — a per-repo override you forget about — then being baffled when a different repo behaves differently.

Best Practices

Set user.name and user.email as the very first thing on any new machine, before cloning anything.
Set git config --global init.defaultBranch main so local and remote default branches agree.
Choose pull.rebase (true or false) deliberately instead of inheriting a default that changes between Git versions.
Use git config --list --show-origin to find which file is supplying a surprising value before you start guessing.
Configure a real credential manager — Git Credential Manager or the OS keychain helper — rather than typing or storing tokens in plaintext.

Comparable toolsMercurial identity and editor in ~/.hgrcSubversion config in ~/.subversion/config

Knowledge Check

A push succeeds, but your commits show the wrong author on GitHub. Why, and how expensive is the fix?

user.email did not match your account; the author is part of each commit's hashed data, so fixing it means rewriting history
GitHub caches the authorship and will quietly correct it to your account within a day on its own, with no action from you
The push used HTTPS instead of SSH; simply re-pushing the same branch over an SSH remote relabels every one of the commits to you
It is purely cosmetic and can never be changed by anyone once the commits have been pushed up to the remote

The same config key is set in system, global, and local scope. Which value wins?

Local — the most specific scope overrides global, which overrides system
System — it is loaded last of the three and therefore has the final say over the others
Global — the user-level setting in ~/.gitconfig always takes priority over the other scopes
Git errors out and refuses to run any command until you resolve the conflicting scopes by hand

On Windows, every file in a freshly cloned repo shows as modified before you touch anything. What is the likely cause?

A core.autocrlf mismatch is converting line endings, so Git sees CRLF/LF differences as changes
The clone arrived corrupted over the network and the whole repository must be deleted and the clone re-run from scratch
Windows deliberately marks every file in the tree as modified on the first checkout as a built-in safety measure
user.email is still unset, and an unset commit identity flags every tracked file as changed

You got correct