Setting Up Git for the First Time: Name, Email, and Editor

You install Git, open the terminal eager to make your first commit, and the first thing you run into is an awkward question: who are you? Before it saves a single change, Git wants to know your name and your email. Setting up Git is that two-minute step almost nobody explains well, and it saves you headaches for years to come.

If you haven’t installed it yet, start with the guide to installing Git on Windows. And if all of this sounds like Greek to you and you’re not sure what Git is or what it’s for, read what Git is and your first steps first. Here I’m assuming you already have it installed and know how to open a terminal. That’s all you need.

Why does Git ask for a name and an email?

Git permanently records your name and email inside every commit, to leave a trace of who made each change.

A commit is a snapshot of the state of your code at a specific moment. Every time you make one, Git writes an authorship label next to that snapshot: your name and your email. Think of the signature you leave at the bottom of a contract. Once it’s signed, it stays there.

That’s why it matters to configure this before your first commit, not after. If you change your name or email later, the change only affects the commits you make from that point on. The ones you already made keep the old label. Git doesn’t do this to be difficult: history is a record of what happened, and rewriting it is a whole different matter.

How to configure your name and email

It’s done with two commands, one for the name and one for the email (the order between them doesn’t matter):

# Tu nombre: aparecerá como autor de cada commit (las comillas permiten espacios)
git config --global user.name "Tu Nombre"
# Tu email: la otra mitad de la etiqueta de autoría
git config --global user.email "tu@email.com"

Use the name you want to appear under and a real email, not a throwaway one. That email is what GitHub or GitLab later use to associate your commits with your profile. With these two lines, Git already knows who you are and you can start committing.

What does --global mean, and how is it different from local?

The --global flag tells Git to save that configuration for all your repositories, writing it to a single file in your user folder called ~/.gitconfig.

If you run the same command without --global inside a repository’s folder, Git saves it to that repo’s .git/config file instead, and it only applies there. When there are values in both places, the repository’s value wins: local configuration takes priority over global, and global over system ^[1].

Scope	Flag	File	Affects	Precedence
System	--system	/etc/gitconfig	every user on the machine	lowest
User	--global	~/.gitconfig	all your repositories	beats system
Repository	--local (or nothing, inside a repo)	.git/config	only that repo	beats everything

What’s local config actually good for in practice? Having different identities depending on the project. The typical case: on your laptop you use your personal email by default, but work repos need to use your corporate email. You go into the work repo’s folder and override the identity there, without touching the global one:

# Dentro de la carpeta del repositorio, sin --global:
# esto se guarda solo en .git/config de ESTE repo
git config user.name "Tu Nombre"
git config user.email "tu@empresa.com"

~/.gitconfig is an ordinary text file: you open it with any editor and read it as-is.

How to choose your default editor

Git opens a text editor whenever it needs you to write something longer, for example the message for a commit you didn’t pass -m to, or a merge message. With core.editor you decide which one opens:

# VS Code: el --wait hace que Git espere a que cierres la pestaña
git config --global core.editor "code --wait"
# nano: el editor de terminal más sencillo para empezar
git config --global core.editor "nano"
# vim: si ya lo conoces y te manejas con él
git config --global core.editor "vim"

The important detail is VS Code’s --wait. Without it, VS Code opens but Git doesn’t wait around: it assumes you’re already done, and you end up with an empty message. With --wait, Git pauses until you close the tab. You can set VS Code, nano, vim, or any other editor you use daily. If you have no preference, nano is the one that causes the least headaches when you’re starting out.

How to check that it’s configured correctly

git config --list shows your entire configuration at once. And if you add --show-origin, Git also tells you which file each value came from:

# Toda tu configuración, y el archivo de origen de cada valor
git config --list --show-origin
# O lee un solo valor suelto, sin ruido
git config user.name

--show-origin is the tool that saves you when something doesn’t add up. If a repo shows a strange email, this view tells you whether the value comes from your global ~/.gitconfig or from a local .git/config you set up months ago and forgot about. Reading a single value (git config user.name) is the quick check when you just want to confirm one thing.

One extra setting: the default branch

When you create a new repository, Git names its first branch. With init.defaultBranch you choose what it’s called:

# La rama inicial de los repos NUEVOS se llamará "main" en vez de "master"
git config --global init.defaultBranch main

For years that first branch was called master by default. Today the de facto standard on GitHub, GitLab, and similar platforms is main, so configuring this now saves you the manual step of renaming it in every new repo. Note that this only affects repositories you create from now on, not the ones you already have.

Common mistakes when configuring Git

Starting to commit without configuring anything

This is the classic one. You dive into coding, make forty commits in an afternoon, and days later discover they all carry an author that looks like Tu Nombre <tu@laptop.local> or is empty outright. Configuring the correct name now doesn’t fix the old commits: those already have their label recorded. That’s why the two identity commands are literally the first thing you do after installing Git.

Your Git email isn’t your GitHub password

This confuses a lot of people when they’re starting out. Your Git email isn’t an access credential, it’s just the authorship label that travels with every commit. GitHub uses it to associate your commits with your profile when it matches an email on your account, but never to let you sign in. For authentication you have your password, SSH keys, or tokens. Putting your password in user.email makes no sense, and it would end up written into the history on top of that.

Setting code without --wait

If you configure core.editor "code" on its own, Git will open VS Code and move on without waiting for you. The result: commits with an empty message. Add --wait.

Using --global when you meant per-project identity

If at work you leave your personal email in the global configuration, every company repo will carry that email in its history. The right move is to configure the corporate identity locally inside each work repo, as you saw in the table above.

Initial setup checklist

• user.name configured with git config --global user.name
• user.email configured with the real email you want to appear as the author
• core.editor points to an editor you know how to use (with --wait if it’s VS Code)
• init.defaultBranch set to main for new repositories
• git config --list --show-origin shows your values coming from ~/.gitconfig
• you understand these values only affect future commits

What’s next

Git is ready now: it knows who you are and will save your name in every commit you make. The natural next step is creating your first repository and making your first commit, where these settings start to really show.

If you’d rather practice this with guided exercises instead of just reading about it, we work through it step by step in the course Git from Zero to Professional.

One new concept every week

Subscribe

Sources

1. Official git-config documentation: the --system, --global, and --local scopes, their files, the precedence between them, and the user.name, user.email, core.editor, and init.defaultBranch keys.

Frequently Asked Questions

Is my Git email my GitHub password?

No. The email only signs the authorship of your commits and isn’t used to sign in. What actually gets you access to GitHub is an SSH key (if you connect over SSH) or a personal access token (if you connect over HTTPS); that’s configured separately, just once. If git push asks you for credentials, that’s what it’s about, not your user.email.

Can I change the name or email I set up in Git?

Yes. Just run git config --global user.name or user.email again with the new value. The catch is that the change only affects the commits you make from that point on; the ones you already made keep the old label. There are tools for rewriting the authorship of past commits: git commit --amend fixes the last commit, and git filter-repo (or the older git filter-branch) can rewrite many at once. That said, it’s advanced territory best avoided when you’re starting out.

Do I have to configure Git in every new repository?

No, not if you used --global. The global configuration lives in ~/.gitconfig and automatically applies to all your repos. You only repeat the configuration inside a specific repo when you want a different identity there, for example to keep your work projects separate from your personal ones.

Which editor should I set if I don’t know which one to choose?

nano. It’s the simplest one to start with: you use the shortcuts shown at the bottom of the screen, save with Ctrl+O, and exit with Ctrl+X. Once you’re comfortable, you can switch to VS Code (with code --wait) or whichever one you prefer.

Where is all this configuration stored?

In plain text files. The global configuration lives in ~/.gitconfig, inside your user folder, and each repository’s lives in its own .git/config. You can open them with any editor and see your values in plain text. In fact, git config --list --show-origin tells you exactly which file each one comes from.