beginner30 minby DevFox

Installing Git

Get Git onto your machine and teach it who you are. Includes a short orientation to the terminal for anyone who has never opened one, and why Git needs your name at all.

Git is a program, and like any program it has to be on your computer before it can do anything for you. That is the whole job of this lesson — but if you have never typed a command into a terminal before, "install it" is not a small ask, and nobody should pretend otherwise.

So this one goes slowly. By the end you will have a terminal open without dread, a current version of Git installed, your name and email attached to every commit you will ever make, and a way to prove that all three actually worked.

Meeting the terminal

Git has no window full of buttons. You drive it by typing commands into a terminal — a program that takes one line of text, runs it, and prints whatever the command has to say back to you.

That sounds like a step backwards until you notice what it buys. A line of text is exact and repeatable: the same line does the same thing on your machine, on a colleague's, and on a server at three in the morning. It is also why every Git instruction you will ever read is written as something you can copy — including every instruction in this course.

Open one now. On macOS, press Cmd + Space, type "Terminal", and press Enter. On Windows, open the Start menu and type "PowerShell" — once Git is installed you will have a better option, which the Windows section covers. On Linux, try Ctrl + Alt + T, or search your applications for "Terminal".

What you get is a window with a line of text sitting in it, ending in something like $, %, or >. That line is the prompt, and it is the machine telling you it is ready and waiting. The text before the symbol is usually your username and the folder you are currently in — information, not something you type.

You type after the prompt, and nothing whatsoever happens until you press Enter. Until then you can type, retype, and delete as freely as in any text box. Pressing Enter is the moment you hand the line over.

Then comes the part that unsettles people most: when a command works, it usually prints nothing at all. You get a blank line and a fresh prompt, and that is the success message. Think of handing a note across a counter to a clerk who does exactly what it says and hands nothing back — the silence is your receipt. Commands speak up when something went wrong, or when you asked them for information.

Ask before you install

There is a good chance Git is already on your machine. It arrives bundled with Apple's developer tools, ships in many Linux installs by default, and gets pulled in quietly by other software you may already have.

Installing a second copy on top is not a disaster, but it does create a specific and genuinely baffling problem. You end up with two copies of Git in different folders, and which one runs depends on the order your system searches those folders. So you upgrade one, keep running the other, and the version number refuses to change no matter what you install. Ten seconds of checking now saves you that afternoon later.

Type this and press Enter:

bash

git --version

One of three things happens.

git version 2.51.0

Git is already here.

Skip the install sections and go straight to naming yourself. Read the number first — the next section explains what it tells you.

command not found

Git is not installed.

On Windows the wording is 'git' is not recognized. Same meaning. The install section for your system is next.

A dialog box appears

macOS is offering to fetch it.

You asked for a tool it knows how to install. The macOS section covers what that dialog installs and whether to accept it.

Three answers, three different next steps

How to read a version number

git version 2.51.0 is three numbers separated by dots, and each one tells you something different.

The first is the major version. Git has been on 2 since 2014, and that number moves only for a release that deliberately breaks old behaviour. In practice you can ignore it.

The second is the minor version, and this is the one worth reading. It goes up by one every few months as new features land, so it is effectively a date stamp: a big number means recent, a small number means your Git is old. The third is the patch version — bug fixes only, no new behaviour.

Three waypoints matter for this course.

2.40 and above
Comfortably modern. Everything in this course works as written.
2.28
Added the setting that names your first branch, which the next lesson uses.
2.23
Introduced git switch and git restore. This course prefers them over the older git checkout, because one command with one job is easier to reason about than one command with several.

Find your minor number on this stack. Below 2.23 you will meet commands that do not exist on your machine.

Installing on macOS

macOS gives you two sensible routes, and they differ mainly in how fresh a Git you end up with.

Apple's Command Line Tools

Fastest path from nothing to a working Git.

One command, no setup beforehand.

Apple ships its own build on Apple's schedule, so it commonly runs a year or more behind.

Homebrew

Current release, and easy to keep current.

A package manager whose whole job is installing and updating other programs, so you never hunt for a download page again.

You have to install Homebrew itself first.

Both work. The second is worth the extra step if you expect to live in a terminal.

The first is Apple's own. Run this and a dialog appears; click Install and wait:

bash

xcode-select --install

That installs the Command Line Tools, a bundle of developer basics that includes Git along with a C compiler and a handful of other utilities.

For the second route, Homebrew, the one-line installer lives at brew.sh. Then:

bash

brew install git

That gives you the current release, and brew upgrade git keeps it current later. If you expect to spend real time in a terminal, Homebrew pays for itself quickly.

If you took both routes you now have two copies of Git, which is the situation the previous section warned about. Run git --version to see which one wins; if it still reports Apple's older number, close the terminal window and open a fresh one.

Installing on Windows

Git grew up on Linux, and its whole world assumes a Unix-style shell — one where ls lists files and rm removes them. Windows' own shells use different names for those things. That mismatch is not a small annoyance; it means that copying commands from tutorials, answers, and courses would constantly fail for reasons that have nothing to do with Git.

The official installer fixes this, which is why it is the right choice rather than a convenience. Download it from git-scm.com/download/win, run it, and accept the defaults. There are a lot of screens; every one arrives with a reasonable option already selected, and you can safely click through. If you prefer one line, PowerShell can do it:

bash

winget install --id Git.Git -e

What you have installed is called Git for Windows, and the part that matters most is bundled with it: Git Bash, a small terminal that behaves like the Unix shells everyone else in the Git world uses. Open it from the Start menu, or right-click any folder and choose "Open Git Bash here" — a genuinely pleasant way to land in the right place.

Git itself works fine in PowerShell and Command Prompt, and every git command is identical everywhere. It is the commands around Git that differ. Use Git Bash and the examples you find online — including the ones in this course — work as written.

Installing on Linux

On Linux, software comes from your distribution's package manager: a catalogue of ready-built programs your system can install, update, and remove for you. Git is in every one of them, so this is a single command.

bash

sudo apt update && sudo apt install git   # Debian, Ubuntu, Mint
sudo dnf install git                      # Fedora, RHEL, Rocky
sudo pacman -S git                        # Arch, Manjaro

Two pieces of that deserve a name. sudo means "run this line as the administrator", which installing system-wide software requires. The apt update half refreshes the local copy of the catalogue before installing, so you get the newest version the catalogue offers rather than whatever it knew about last time.

There is one wrinkle worth knowing about. A distribution freezes its catalogue when the release ships and then mostly backports only security fixes, so a stable server release can hand you a Git that is three years old while cheerfully reporting itself as up to date. It is not lying; the catalogue really is current, and the catalogue is old.

Telling is easy now that you can read a version number. Run git --version and compare the minor number against the current release listed on git-scm.com. A gap of a few is fine. A gap of ten or more means you are working with a Git from another era. On Ubuntu you can opt into current releases:

bash

sudo add-apt-repository ppa:git-core/ppa
sudo apt update && sudo apt install git

Proving the install worked

Whichever route you took, go back to the command you started with:

bash

git --version

A version number is the entire confirmation. There is no other ceremony — Git is installed, and the number tells you which one you got.

Why Git needs to know your name

A commit is a permanent record of a change, and a large part of what makes it useful six months later is knowing who made it. When you ask Git who wrote a line, or when a review tool shows an author next to a change, that answer comes from inside the commit itself — the name and email were written into it at the moment it was created.

Git has no way to work that out for you. It cannot see your email account, and the username you log into your computer with is rarely what you want printed beside your work forever; admin, user, and jsmith-mbp-2019 all make poor bylines. So Git asks once, and then refuses to create a commit until you have answered.

Answer it now, substituting your own details:

bash

git config --global user.name "Ada Lovelace"
git config --global user.email "ada@example.com"

Take that line apart, because you will see this shape often. git config is Git's command for reading and writing settings. user.name and user.email are the names of the two settings. The quoted text is the value you are storing, and the quotes are there because the value contains a space — quoting values is a good habit to keep even when they do not.

The --global flag means "for me, on this computer, in every project", as opposed to only the project you happen to be standing in. That is why this is a once-per-machine job rather than something you repeat for every repository. Git has other places it can store settings, and the next lesson takes that apart properly.

As for what to put: use a name a human would recognise on a pull request — the name colleagues call you, not a handle you picked at fourteen. For the email, use an address you actually read, and if you expect to put code on GitHub, use one your GitHub account owns. That address is how GitHub matches commits to your profile instead of showing an anonymous grey avatar next to your work.

Reading your settings back

Settings are quiet. Both commands above printed nothing, which by the rules of the terminal means they worked — but Git also accepts settings it will never use. Type user.emial by mistake and Git stores it without complaint, because as far as it knows you may have invented a setting some tool of yours cares about. Your commits then go out with no email at all.

So read the settings back and look at them with your own eyes:

bash

git config --global --list

You get one key=value line per stored setting:

text

user.name=Ada Lovelace
user.email=ada@example.com

Extra lines may appear — installers sometimes add their own — and that is perfectly normal. What matters is that your two are present and spelled the way you meant.

To ask about a single setting instead of all of them, name it with no value:

bash

git config --global user.email

If something is wrong, run the original command again with the corrected value. A second write replaces the first rather than adding a second copy, so there is no mess to clean up and no way to make this worse by trying again.

A cheat sheet to keep

Every command from this lesson in one place:

bash

git --version                                # is Git here, and how old?
xcode-select --install                       # macOS: Apple's Git + tools
brew install git                             # macOS: Git via Homebrew
winget install --id Git.Git -e               # Windows, from PowerShell
sudo apt update && sudo apt install git      # Debian, Ubuntu, Mint
sudo dnf install git                         # Fedora, RHEL, Rocky
sudo pacman -S git                           # Arch, Manjaro
sudo add-apt-repository ppa:git-core/ppa     # Ubuntu: newer Git source
git config --global user.name "Ada Lovelace" # name on every commit
git config --global user.email "a@b.com"     # email on every commit
git config --global --list                   # read every setting back
git config --global user.email               # read one setting back

Where to go next

Your machine now has Git on it, you know how old that Git is and why that matters, and every commit you make from here carries your name. You also have a terminal open and some idea of what it is telling you, which is the part most people are never taught.

Next comes Configuring Git the way you want it. That lesson picks up where --global left off: where Git keeps settings and why there is more than one place, which text editor it opens when it needs words from you, what to name your first branch, how to stop invisible line-ending differences from ruining your diffs, and a handful of settings that quietly remove daily friction.

Before you move on, spend a minute in the terminal on purpose. Run git --version and say the three numbers out loud. Run git config --global --list and check your own name is spelled right. Both commands are harmless, and getting comfortable typing them is worth more than it looks — everything from here is more of the same, one line at a time.