Resources / Guide

Setting up git for the first time

Before the everyday workflow makes sense, git needs about five minutes of one-time setup. Most of it is painless. The part that reliably stops people cold is authentication — the moment you try to push and git asks for a password that, confusingly, isn't your password. Here's the whole setup, with that part explained properly.

Install git

On Windows, install Git for Windows — it brings the git command and Git Bash, a terminal that behaves the same way the tutorials assume. On macOS, running git --version will prompt you to install the Xcode command line tools, or you can use Homebrew (brew install git). On Linux it's your package manager (apt install git and friends).

Confirm it worked:

git --version

If that prints a version number, you're done with this part.

Tell git who you are

Every commit is stamped with a name and email. Set them once, globally, so every repo on your machine uses them:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Use the email that matches your git host account (the same one you use on GitHub, Azure DevOps, etc.) so your commits get attributed to you on the web side. A couple of other settings worth doing now:

# make "main" the default branch name for new repos
git config --global init.defaultBranch main

# keep line endings sane (Windows)
git config --global core.autocrlf true

That last one is a lightweight guard against line-ending noise; for anything serious, a committed .gitattributes in the repo is the real fix (its own topic).

You can check what's set at any time:

git config --list

The part that trips everyone: authentication

Here's where the five-minute setup turns into an afternoon if nobody warned you. You clone or push, git asks for a username and password, you type your account password — and it's rejected. That's not a bug. Most git hosts stopped accepting your account password over git years ago. You need one of two things instead.

Option A: HTTPS with a personal access token

When you clone over HTTPS (a URL starting https://), git authenticates with a personal access token (PAT) — a long generated string that stands in for your password. You create it in your git host's settings (GitHub: Settings → Developer settings → Personal access tokens; Azure DevOps and GitLab have equivalents), grant it repo access, and copy it somewhere safe — you usually can't see it again.

Then when git prompts for a password, you paste the token, not your account password. To avoid pasting it every time, let a credential helper remember it:

# Windows (Git for Windows ships with this)
git config --global credential.helper manager

# macOS
git config --global credential.helper osxkeychain

After that, you authenticate once and the helper holds onto the token.

Option B: SSH keys

The alternative is an SSH key — a key pair where the public half lives on your git host and the private half stays on your machine. Once it's set up, you never type a credential again; pushes and pulls just work. Generate a key:

ssh-keygen -t ed25519 -C "you@example.com"

Press enter through the prompts (the defaults are fine), then copy the public key — the contents of ~/.ssh/id_ed25519.pub — into your git host under SSH keys. Use the git@… form of the repo URL (the "SSH" option on the clone screen) rather than the https:// form, and you're authenticated by the key automatically.

Which one

For getting started on Windows, HTTPS + a token with the credential manager is the path of least resistance — it's built in and there's nothing to generate. SSH is a little more setup up front but more pleasant long-term because there's no token to expire or re-enter. Either is fine; the only wrong move is typing your account password and assuming git is broken when it's rejected.

You're ready

That's the whole one-time setup: install git, set your name and email, and sort out authentication once with a token or an SSH key. Do this and the everyday loop — clone, edit, commit, push — works without ever stopping to ask who you are again.

Standing up a team on git?

Host setup, access tokens, branch rules, the CI that runs on every PR — I help teams get version control and deployment configured cleanly from day one. If you want a hand, let's talk.

Work with me