The previous lesson explained why Git exists and introduced Ana, Bruno and Carla, the team who will build task-manager. Before Ana can turn her folder into a repository she needs something elementary: Git installed. This lesson covers installation on the three usual operating systems — Linux, macOS and Windows — how to verify it worked, how to consult the built-in help, and how to keep Git up to date. It also clears up what Git Bash is, what graphical clients are, and why the whole course works on the command line.

This is a thoroughly hands-on lesson: by the end you will have a working Git on your machine and know how to check it.

1. Before you start: check whether you already have Git
2. Installing on Linux
3. Installing on macOS
4. Installing on Windows
5. Verifying the installation
6. The built-in help: git help
7. Git Bash, terminals and graphical clients
8. Why the command line in this course
9. How to update Git

Many systems ship Git preinstalled, or other tools have installed it. Before downloading anything, open a terminal and run:

There are two possible outcomes:

Something like this means you already have Git. Check that the version is reasonably recent (2.30 or above is enough for the whole course; 2.40 or above is ideal) and skip to section 5.

If you see this — or 'git' is not recognized... on Windows — Git is either not installed or not on the PATH. Follow the section for your system.

A note on versions. Git is extraordinarily stable and backwards compatible: almost everything you learn will still work the same way ten years from now. Even so, some modern conveniences (such as git switch and git restore, covered in modules 2 and 3) need Git 2.23 or above, and certain sensible defaults arrived in 2.28. It is worth not staying on an old version.

On Linux, Git comes from your distribution's package manager. That is the recommended route: the system handles dependencies and updates for you.

Breaking the commands down:

• sudo runs the command with administrator privileges, which installing system-wide software requires. It will ask for your password.
• apt update refreshes the list of available packages and their versions. It does not upgrade any program; it only brings the catalogue up to date. Skipping this step is the most frequent reason for ending up with an old version.
• apt install git downloads and installs the git package and its dependencies.

On older systems that have yum instead of dnf, the equivalent command is sudo yum install git.

The basic git package includes everything essential, but some distributions split out extras worth having:

• gitk is a graphical history viewer that ships with Git.
• git-gui is a minimal graphical client for staging and committing changes.
• git-email enables sending patches by e-mail, as projects like the Linux kernel do.

None of them is essential for this course.

Stable distributions tend to lag a little. If you need the most recent release, there is an official repository maintained by the Git team:

add-apt-repository adds an extra package source; from then on apt treats it like any other and will offer Git updates automatically.

On macOS there are three routes. The order below is also the order of preference.

Homebrew is the de facto package manager on macOS. If you don't have it yet:

This command downloads the official installation script and runs it. Broken down: curl downloads the URL (-fsSL means "fail on errors, silent mode, show errors, follow redirects") and $( ) hands the result to bash to execute.

Once Homebrew is available:

Homebrew installs Git into /opt/homebrew/bin/git (Apple Silicon) or /usr/local/bin/git (Intel), paths that take precedence over the system version in the PATH. That way you always have an up-to-date version.

macOS includes a version of Git inside Apple's developer tools. Install them with:

A system window will appear asking for confirmation. They are also triggered automatically the first time you type git in a terminal without having them installed.

The upside: nothing else is needed. The downside: the version tends to trail by several months or years, and it only moves with system updates.

There are .dmg installers at git-scm.com/download/mac. It is a valid option if you would rather avoid package managers, but updating is then down to you.

Windows does not include Git, so you have to install it. There are three routes.

Download the installer from git-scm.com/download/win and run it. The wizard asks quite a few questions; these are the ones that matter, with the recommended answers:

If you hesitate on a screen not listed here, leave the default: they are sensible choices and almost all of them can be changed later with git config.

If you prefer an unattended installation:

Or with Chocolatey:

winget comes bundled with modern Windows 10 and 11. The -e flag forces an exact match on the identifier so you don't install a similarly named package by mistake.

WSL runs a real Linux distribution inside Windows. If you develop with Unix-world tools (Node.js, Python, Docker), it usually gives the best experience.

Once inside the distribution (Ubuntu by default), Git installs exactly as on any Linux:

An important warning about WSL. The Windows Git and the WSL Git are two separate installations, with independent configurations. On top of that, working from WSL on files stored on the Windows disk (/mnt/c/...) is noticeably slow and causes trouble with permissions and line endings. The recommendation is to keep your repositories inside the Linux file system (~/projects/...) and use only the WSL Git.

Whatever your system, close the terminal and open it again (so it picks up the PATH changes) and run:

The expected output, with whatever number applies:

Some further useful checks:

That last command prints a long list. You don't need to understand it; it is there to confirm the installation is complete rather than truncated.

Git ships its full documentation inside the program itself. Learning to consult it is worth more than memorising options.

This command opens the manual page for git config. On Linux and macOS it appears in the less pager: navigate with the arrow keys or space, search with /word and quit with q. On Windows, git help opens the HTML version in your browser by default.

There are three equivalent ways to ask for a command's manual:

For a quick look, without opening the full manual, there is the options summary:

The lowercase -h prints a handful of lines with the syntax and the main options straight into the terminal. It is the one you will reach for most from day to day.

Try git help -g: Git includes topic guides such as gittutorial, giteveryday and gitglossary, which you read with git help giteveryday.

Git Bash is a Windows-only component that comes with the official installer. It is not Git: it is a terminal emulator bundled with a Bash interpreter and a set of Unix utilities (ls, grep, ssh, curl, vim…) compiled for Windows.

It exists for a practical reason: Git's documentation, the examples you find online and hooks (scripts that run automatically, module 6) all assume a Unix environment. Git Bash provides that environment without leaving Windows.

If you are on Windows, use Git Bash to follow the course: the commands in the lessons will work exactly as written. On Linux and macOS, the system terminal is already enough.

A graphical client (GUI) is an application with windows and buttons that runs Git commands underneath. The best known ones:

Graphical clients are useful, above all for reviewing differences and navigating the history. There is nothing wrong with using them, and many professionals combine the terminal for doing and a GUI for looking.

This course uses the command line exclusively, for concrete reasons:

1. It is the only complete interface. Every graphical client implements a subset of Git. Sooner or later you will need something your GUI doesn't offer, and then you will have to open the terminal anyway.
2. It is universal. A continuous integration server, a remote machine over SSH or a colleague's laptop doesn't have your GUI installed, but they all have git in the terminal.
3. It teaches the model, not the tool. Buttons hide what is happening. Typing git commit after git add forces you to grasp that there are two steps, and that understanding is what lets you solve problems.
4. The documentation and the answers are written as commands. Any manual, issue or answer you find will be expressed in commands, not in "click here".
5. It is faster once learned. And it automates: commands chain together in scripts, graphical interfaces don't.

A practical tip. Learn on the terminal first, then add whichever graphical client you fancy. The reverse order leaves gaps that are hard to close.

Keeping Git current brings security fixes, performance improvements and new commands. The update commands by system:

On Windows, modern Git versions also bundle an update command of their own:

This command checks whether a newer version of Git for Windows exists, downloads it and launches the installer. It only exists on Windows.

To find out which version is the latest release, check git-scm.com or run your package manager's update command: if there is nothing new, it will tell you.

Updating breaks nothing. Existing repositories keep working exactly the same after an update: the on-disk format has been backwards compatible for over a decade. Updating is safe.

• Not closing the terminal after installing. The PATH is read when the terminal session starts. If you have just installed Git and git --version fails, close it and open it again before giving up on anything.
• Forgetting apt update before apt install. Without refreshing the catalogue you can end up installing a very old version, or get a package-not-found error.
• On Windows, not ticking the PATH option. If you pick "Use Git from Git Bash only", git won't work in PowerShell or in VS Code. The fix is to re-run the installer.
• Mixing the Windows Git and the WSL Git on the same folder. It causes permission clashes, mismatched line endings and crossed configurations. Pick one and keep your repositories in its native file system.
• Installing Git from a hand-unzipped .zip. It works, but the system has no record of it and updating becomes a problem. Always use the package manager or the official installer.
• Tip: set your editor during the Windows installation. Leave the default and you will land in Vim the first time Git asks you to write a message. It can be changed later (lesson 01-06), but it is an unpleasant surprise.
• Tip: install gitk on Linux as well. It is a history viewer that helps a lot in visualising what you are learning, and it doesn't get in the way of using the terminal.

Run the commands needed to answer these five questions about your machine, and note down both the command you used and the result:

1. Which version of Git do you have installed?
2. Where does the executable live?
3. Is there more than one Git installation on your PATH?
4. How many subcommands does your installation offer?
5. Which conceptual guides does the documentation include?

Without searching online, use only Git's built-in help to find out:

1. What the --global option of git config does.
2. Which Git command "shows the working tree status" (look for it in the list of common commands).
3. The name of the bundled guide that summarises everyday Git use.

State which command you ran in each case.

The task-manager team is a mixed bunch: Ana works on Ubuntu, Bruno on a MacBook with Apple Silicon and Carla on Windows 11. Write brief instructions for each of them covering: (a) the installation command or method, (b) how to verify it worked and (c) one warning specific to their platform.

Solution to Exercise 1

Solution to Exercise 2

1. --global in git config:

The documentation states that --global writes to the user's configuration file (~/.gitconfig), which applies to all of that user's repositories. That is the level we will use in lesson 01-05.

2. The status command:

In the common commands section, status appears with the description "Show the working tree status". The command is git status and we will put it to work in module 2.

3. The everyday guide:

The guide is giteveryday, which you read with git help giteveryday. It summarises the twenty commands that cover 95 % of real-world use.

Solution to Exercise 3

Ana — Ubuntu

Warning: the version in Ubuntu's official repositories may trail by several releases. If she needs the latest, she should add the ppa:git-core/ppa PPA before installing.

Bruno — macOS (Apple Silicon)

Warning: macOS ships its own Git at /usr/bin/git via the Command Line Tools. If which git returns that path instead of the Homebrew one, the PATH is in the wrong order and he will keep using the old version.

Carla — Windows 11

Download the installer from git-scm.com/download/win and, during the wizard, choose "Git from the command line and also from 3rd-party software" on the PATH screen, main as the initial branch name, and her usual editor.

Warning: if she doesn't tick the PATH option, git will work only inside Git Bash and will fail in PowerShell and in her editor. She should also follow the course from Git Bash so that the commands in the lessons work literally as written.

You now have Git installed and verified. On Linux it comes from the distribution's package manager; on macOS the most practical route is Homebrew (with the Command Line Tools as a no-prerequisites alternative); and on Windows it is the official Git for Windows installer, which additionally provides Git Bash, the terminal environment to follow the course in. The basic check is always the same — git --version — and the full documentation lives inside the program itself, reachable with git help <command> or, for quick questions, git <command> -h.

We have also justified the course's methodological decision: we will work on the command line because it is the complete, universal interface, and the one that teaches Git's model instead of hiding it. Graphical clients are an excellent complement, not a substitute.

Having the tool is not enough: you need to understand its vocabulary. In the next lesson, Basic Git Terminology, we will build the glossary that everything else rests on — repository, staging area, commit, HEAD, branch, remote — and look at the diagram of the three states any file in Git passes through.