Install and first repo
Install git, verify it, then set a one-time identity with git config --global user.name and user.email so every commit has an author. Then start a repo two ways: git init creates an empty .git in place, git clone copies an existing repo with its full history.
You now understand what git records and where your files live. Time to make it real on your own machine: install the tool, tell it who you are, and bring a repository into existence. This is a five-minute, once-per-machine setup — but skipping the identity step produces commits stamped with a wrong or guessed author, and that mistake is annoying to fix after the fact.
By the end of this lesson you will be able to verify your git install, set your identity globally, choose sensible defaults, and create a repository two ways: from scratch with git init or by copying an existing one with git clone.
After this lesson you can verify git is installed, set your name and email with git config —global, explain why every commit needs an identity, configure the default branch and editor, and describe the difference between git init and git clone.
First, confirm git is installed and see its version. Almost every system either ships git or installs it in one command (macOS: xcode-select --install or Homebrew; Debian/Ubuntu: apt install git; Windows: the Git for Windows installer). Verify with:
git --version
# git version 2.45.2If you see a version number, git is ready. The exact number rarely matters for day-to-day work, but knowing the command lets you confirm an install on any machine you sit down at.
Set your identity once, globally — every commit records an author. Recall that a commit stores who made it. Git refuses to invent that for you, so you tell it your name and email a single time and it stamps every future commit automatically:
git config --global user.name "Ada Lovelace"
git config --global user.email "ada@example.com"The --global flag writes these to your per-user config (~/.gitconfig) so they apply to every repository you touch on this machine. Without an identity, git will block your first commit and ask for it. The email matters: hosting platforms like GitHub match commits to your account by the commit email, so use the address you actually use there.
Set two more useful defaults: the initial branch name and your editor. New repos historically named their first branch master; the modern default across GitHub, GitLab, and git itself is main. Pin it so every new repo is consistent:
git config --global init.defaultBranch main
git config --global core.editor "code --wait" # or "vim", "nano", etc.core.editor is the program git opens when it needs you to write text — a commit message with no -m, or an interactive rebase. Setting it to an editor you know avoids the classic “stuck in vim” panic. You can inspect everything you have configured with:
git config --list # show all effective settings
git config user.email # show one valueCreate a fresh repository with git init. Run it inside a project folder and git creates a single hidden .git directory — the repository store you met two lessons ago. Your existing files are untouched and, at first, untracked.
mkdir my-project && cd my-project
git init
# Initialized empty Git repository in /…/my-project/.git/
git status
# On branch main
# No commits yet
# nothing to commit (create/copy files to get started).git holds all history and configuration for this repo; the files beside it are your working tree. A first git status in a brand-new repo confirms it: you are on branch main, with no commits yet.
Or copy an existing repository with git clone. When the project already lives somewhere (a teammate’s server, GitHub), you do not init — you clone. git clone <url> downloads the entire repository, including its full history, and checks out a working tree for you:
git clone https://github.com/git/git.git
# Cloning into 'git'...The difference is the starting point. git init gives you an empty repo with no commits, ready for your first one. git clone gives you a complete copy of someone else’s repo — every commit, every branch — because git is distributed and each clone is a full, independent repository (the point from lesson 1).
▸Why this works
Why insist on a real email instead of leaving it blank or fake? Because the author identity is permanent, baked into each commit’s content. Hosting platforms attribute contributions, blame, and access decisions by the commit email — a wrong address means your commits show up as someone else or as “unknown,” and rewriting history to fix it later is disruptive on a shared branch. Set it correctly once with --global and the problem never arises. If a particular repo needs a different identity (say, a work email), set it locally inside that repo with git config user.email "work@company.com" — a repo-local value overrides the global one for that repo only.
From a blank machine to a working repo.
You sit down at a fresh laptop and want to start a project.
git --versionprintsgit version 2.45.2— installed and ready.- You set your identity once:
git config --global user.name "Ada Lovelace"andgit config --global user.email "ada@example.com". You also pin defaults:git config --global init.defaultBranch main. - You scaffold the project:
mkdir todo-app && cd todo-app, thengit init. Git printsInitialized empty Git repository …/todo-app/.git/. git statusshowsOn branch main,No commits yet. You add a fileREADME.md;git statusnow lists it under Untracked files — exactly the three-areas map from the last lesson, now on a real repo.
Had you instead wanted to work on an existing project, step 3 becomes git clone <url> and you skip straight to a fully populated working tree with the whole history already present. Either way, your identity from step 2 will author every commit you make from here on.
▸Common mistake
A frequent beginner stumble: running git init inside the wrong directory — for example your home folder or an already-cloned repo — creating a nested or sprawling .git you did not intend. git status and git rev-parse --show-toplevel (which prints the repo root) tell you exactly where the repository boundary is. If you git init somewhere by mistake and there are no commits yet, you can simply remove the stray store with rm -rf .git and you are back to ordinary files. Always glance at your current directory before git init.
What is the key difference between git init and git clone?
Setting up git is a once-per-machine routine: verify the install with git --version, then set your identity — git config --global user.name and user.email — because every commit records an author and git will not guess it. Pin sensible defaults with init.defaultBranch main and core.editor, and inspect anything with git config --list. Then bring a repository into being one of two ways: git init creates a new, empty repo (a fresh .git directory in place, no commits yet), while git clone <url> copies an existing repo with its entire history and checks out a working tree — possible because every git clone is a full, independent repository. You now have git installed, your identity set, and a real repo on disk, ready to record its first commit.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.