Configuring Git Properly

In one line

git config sets your identity, default editor, and useful shortcuts at three possible scopes — getting this right once, up front, prevents a surprisingly large share of early Git confusion.

0/5 · 0%

Think of it like this

Signing a form with your name before you're allowed to submit it — Git requires knowing WHO you are (a name and email) before it will let you make a single commit, since that identity gets permanently baked into every commit you ever make.

Key ideas

01
git config --global user.name "Your Name" and git config --global user.email "you@example.com" are almost always the very first two commands anyone runs after installing Git — without them, Git either refuses to commit or (worse) silently commits under a placeholder identity that makes your work invisible in git log and git blame.
02
Git config has THREE scopes, checked in order of increasing specificity: SYSTEM (--system, applies to every user on the machine, rarely used), GLOBAL (--global, applies to every repository for YOUR user, stored in ~/.gitconfig), and LOCAL (no flag, or --local, applies to just the CURRENT repository, stored in .git/config). A local setting always overrides a global one, which always overrides a system one.
03
A genuinely common real use of LOCAL config: setting a different user.email for a specific work repository than your personal global one, so work commits are correctly attributed to your work email without needing to change your global identity every time you switch projects.
04
git config --global init.defaultBranch main sets the default branch name for new repositories (historically master, now commonly main by convention) — worth setting explicitly rather than relying on whatever your Git installation happens to default to, since it varies.
05
Git ALIASES (git config --global alias.st status) let you define your own shortcuts for commands you type constantly — git st instead of git status, for instance. This is genuinely optional polish, but once you're comfortable with the real commands, aliases for your most frequent ones are a small, real quality-of-life improvement worth setting up.

Code & diagrams

git-config-setup.shmarkdown

The standard first-time setup — run this once per machine.

# Identity — required before your first commit
git config --global user.name "Amit Kumar"
git config --global user.email "you@example.com"

# Set a sane default branch name for new repos
git config --global init.defaultBranch main

# Pick a default editor for commit messages (nano is beginner-friendly)
git config --global core.editor "nano"

# See everything currently configured, and where it came from
git config --list --show-origin

# A repository-specific override — e.g. a different email for one work repo
cd ~/scratch/work-project
git config user.email "you@work-company.com"
git config user.email
# shows the local override, not your global email

# A couple of genuinely useful aliases
git config --global alias.st status
git config --global alias.co checkout
git config --global alias.last "log -1 HEAD"
git st       # now works exactly like git status

Explain it without notes

Why does Git require your name and email before you can commit, and what happens to that information once you do?

You work on both personal and work projects on the same laptop. What's the correct way to use a different Git identity for the work repository specifically, without changing anything for your personal projects?

Practice

Set your global user.name and user.email if you haven't already, then run git config --list --show-origin to confirm exactly which file each setting is coming from.

In a throwaway test repo, set a local user.email different from your global one, make a commit, and use git log to confirm the LOCAL email was the one actually used for that commit.

Trade-offs

↔
Aliases save real typing over time, but a heavily customized alias setup can make it genuinely harder to follow along with documentation, tutorials, or a teammate's screen-share, since git st means nothing to someone who's only ever seen git status — a reasonable middle ground is aliasing only your highest-frequency commands, and knowing the real command each one maps to.

Done when you can

I have my global user.name and user.email configured correctly.
I understand the three config scopes (system, global, local) and which one wins when they conflict.
I know how to override my identity for a single repository without touching my global config.