Setup & Config

Identity, SSH keys, and the config options that make git pleasant to work with daily

Why

Git requires your identity before it will record any commit. Beyond the basics, a handful of config settings — aliases, default branch name, push behaviour, credential helper — save time and prevent confusion on every project. Getting this right once means you never have to think about it again.

SSH keys are how GitHub authenticates you for push and pull without a password prompt. Understanding the difference between HTTPS and SSH remotes prevents a common "permission denied" blocker when setting up a new machine.

Intuition

Git config has three levels: system (/etc/gitconfig — all users on the machine), global (~/.gitconfig — your user account), and local (.git/config inside the repo). Each level overrides the one above it. Almost everything you set for personal use goes at the global level.

SSH authentication works via a key pair: a private key that stays on your machine and a public key you give to GitHub. GitHub uses the public key to verify that pushes and pulls are really from you — no password ever leaves your machine.

Explanation

First-time identity setup

# Required — git embeds these in every commit you make git config --global user.name "Your Name" git config --global user.email "you@example.com" # Set the default branch name for new repos (modern standard is main) git config --global init.defaultBranch main # Verify everything git config --global --list cat ~/.gitconfig

These are stamped into every commit. If you use a work machine, override email at the repo level: git config user.email "you@company.com" (no --global) inside that repo.

SSH key setup for GitHub

# 1. Generate an Ed25519 key (preferred over RSA) ssh-keygen -t ed25519 -C "you@example.com" # Accept default path (~/.ssh/id_ed25519), set a passphrase # 2. Add private key to ssh-agent (so you don't retype passphrase) eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519 # 3. Copy public key → paste into GitHub Settings → SSH keys cat ~/.ssh/id_ed25519.pub # 4. Test the connection ssh -T git@github.com # → "Hi username! You've successfully authenticated..." # Use SSH remote URLs (not HTTPS) to leverage the key git remote add origin git@github.com:user/repo.git # Convert existing HTTPS remote to SSH git remote set-url origin git@github.com:user/repo.git

HTTPS remotes ask for a username/token each push unless you configure a credential helper. SSH remotes authenticate silently via your key — preferred for daily development.

Useful global config options

# Default editor for commit messages, rebase editor git config --global core.editor "code --wait" # VS Code git config --global core.editor "vim" # Rebase instead of merge on git pull (cleaner history) git config --global pull.rebase true # Push only the current branch (safer default than pushing all) git config --global push.default current # Aliases — short commands for common operations git config --global alias.st status git config --global alias.co checkout git config --global alias.lg "log --oneline --graph --all --decorate" # Colour output (usually on by default, but explicit is safe) git config --global color.ui auto

The pull.rebase true and push.default current settings are the two most impactful for day-to-day workflow — they prevent accidental merge commits on pull and accidental pushes to the wrong branch.

Starting a repo: init vs clone

git init

Creates a new empty repo in the current directory. Use when starting a project from scratch locally. Then add a GitHub remote manually with git remote add origin <url>.

git clone

Downloads a full copy of an existing repo, sets up origin automatically, and checks out the default branch. Use when the repo already exists on GitHub.

# Clone with SSH (no password prompts) git clone git@github.com:user/repo.git # Clone into a specific directory name git clone git@github.com:user/repo.git my-project

← Previous Next →