How to Install Git on Windows: Git for Windows, winget and Setup

Git does not ship with Windows. You install it through Git for Windows, the official distribution that bundles the Git binaries with a Unix-like shell, a credential helper and supporting tools.

There are two supported ways to get it: the winget package manager, or the installer downloaded from the Git website. Both install the same software.

Before you start

• Windows 10 or Windows 11.
• Permission to install software on the machine.
• Lesson 3 — How Git Actually Works for useful background, though not required.

Version-sensitive lesson

Installer options and package identifiers change over time. The commands here follow the official guidance published at git-scm.com/install/windows. Version numbers you see will differ as Git releases new versions — that is expected, and the commands remain the same.

Step 1 — Check whether Git is already installed

Open PowerShell or Windows Terminal and run:

git --version

What it doesPrints the version of Git currently on your PATH.

Why we run itSome development tools bundle Git, so it may already be present. Checking first avoids installing a second copy.

Expected resultA line beginning git version. On Windows it usually includes a Windows-specific suffix, for example git version 2.55.0.windows.1.

If Git is not installed, PowerShell reports:

git : The term 'git' is not recognized as the name of a cmdlet, function, script file, or operable program.

Continue to the next step.

Step 2 — Install Git for Windows

Choose one of these. They install the same distribution.

winget (recommended)

winget is Microsoft’s package manager, included with current Windows 10 and Windows 11 installations.

winget install --id Git.Git -e --source winget

The flags matter:

• --id Git.Git selects the package by its exact identifier rather than by a fuzzy name match.
• -e requires an exact match, so a differently named package cannot be substituted.
• --source winget restricts the search to the official winget repository.

winget downloads the installer and runs it silently with sensible defaults. When it finishes, open a new terminal — the current session will not have the updated PATH.

To upgrade later:

winget upgrade --id Git.Git -e

Official installer

1. Go to git-scm.com/install/windows.
2. Download the standalone installer for your architecture — 64-bit for most machines, ARM64 for Windows on ARM devices such as Copilot+ PCs.
3. Run the downloaded .exe and work through the setup wizard. The defaults are well chosen; see installer choices below for the three worth understanding.

This route is the one to use on a machine without winget, or when you want to review the options rather than accept defaults.

Open a new terminal after installing

Installation updates the system PATH, but already-open terminals keep the environment they started with. If git --version still fails immediately after installing, close the window and open a fresh one. This accounts for a large share of “the installer said it worked” reports.

Step 3 — Verify the installation

In a new terminal:

git --version

git version 2.55.0.windows.1

To see where the executable actually lives:

Get-Command git | Select-Object -ExpandProperty Source

A default installation puts it under C:\Program Files\Git\.

Installer choices that matter

If you used the graphical installer, three of its screens are worth understanding. If you used winget, it chose sensible defaults for all three and you can change them later with git config.

Default editor

The installer offers a list including Vim, Nano, Notepad++ and Visual Studio Code. Vim is the historical default and is difficult to leave if you have not used it. Pick something you can exit. Notepad or VS Code are both reasonable.

Adjusting your PATH environment

Three options are offered. The recommended middle option — “Git from the command line and also from 3rd-party software” — adds Git to the system PATH so it works in PowerShell, Command Prompt and Windows Terminal, without adding the entire suite of bundled Unix tools. Take it unless you have a specific reason not to.

Line ending conversions

This is the option that causes real problems if set carelessly, and it is covered in full below.

Step 4 — Choose your terminal

Git for Windows installs Git Bash, and Windows already provides PowerShell and Command Prompt. Understanding what each gives you saves confusion later.

Shell	What it is	Notes
Git Bash	A Bash shell bundled with Git for Windows	Unix-style commands (ls, cat, grep); paths look like /c/Users/you
PowerShell	Windows’ modern shell	Full Git support; Windows-style paths; better for Windows tooling
Command Prompt	The legacy Windows shell	Works, but has the fewest conveniences
Windows Terminal	A terminal application, not a shell	Hosts any of the above in tabs; the recommended way to run all of them

Every Git command in this curriculum works identically in all three shells. Git Bash is useful when you are following documentation written for Linux or macOS, because the surrounding shell commands match too.

Windows Terminal is worth installing

Windows Terminal ships with current Windows versions and is available from the Microsoft Store otherwise. It gives you tabs, split panes, proper Unicode support and configurable profiles for PowerShell, Git Bash and WSL side by side.

Step 5 — Configure your identity

Git records an author name and email on every commit and will not commit until they are set.

1. Set your name.

   git config --global user.name "Your Name"

2. Set your email.

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

3. Confirm both.

   git config --global --list

Commit identity is permanent

Author name and email become part of the commit object, and therefore part of the data its ID is derived from. Changing them afterwards means rewriting history into entirely new commits. Set them before your first commit.

Step 6 — Set the default branch name

git config --global init.defaultBranch main

Without this, git init creates a branch named master and prints a hint recommending you configure a default. Setting main matches current convention on every major hosting platform.

Step 7 — Choose an editor

VS Code

git config --global core.editor "code --wait"

--wait is required. Without it, code returns immediately and Git receives an empty commit message.

Notepad

git config --global core.editor notepad

Always available. Save and close the window to complete the commit.

Vim

git config --global core.editor "vim"

Write and quit with :wq. Abort with :q!, which cancels the commit.

Line endings: the Windows-specific issue

This is the one genuinely Windows-specific Git topic, and understanding it prevents a class of confusing diffs.

Windows text files traditionally end lines with a carriage return plus a line feed (CRLF). Linux and macOS use a line feed alone (LF). Git stores file content byte for byte, so a file committed with CRLF endings differs from the same file committed with LF endings — even when the visible text is identical.

On a mixed-platform team, that produces diffs showing every line as changed when nothing meaningful was edited.

Git’s answer is the core.autocrlf setting:

Value	On checkout	On commit	Suits
true	LF → CRLF	CRLF → LF	Windows
input	No conversion	CRLF → LF	macOS and Linux
false	No conversion	No conversion	Repositories that manage this themselves

Git for Windows sets core.autocrlf=true by default, which is the right choice for Windows. Files are stored in the repository with LF and appear in your working tree with CRLF. Check yours:

git config --get core.autocrlf

A .gitattributes file is the better long-term answer

core.autocrlf is a per-machine setting, so it relies on every contributor configuring their machine correctly. A .gitattributes file committed to the repository sets the policy for everyone automatically:

* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

text=auto lets Git normalise text files to LF in the repository while checking them out with each platform’s native endings. The explicit lines handle files that must keep one specific ending regardless of platform.

Credential Manager

Git for Windows bundles Git Credential Manager (GCM), and the installer enables it by default. GCM stores credentials in Windows Credential Manager — the operating system’s encrypted credential store — rather than in a plain-text file, and it handles browser-based and multi-factor authentication flows for the major hosting providers.

Check that it is configured:

git config --get credential.helper

manager

If that returns nothing, enable it:

git config --global credential.helper manager

The first time you push to an HTTPS remote, GCM opens a browser window to authenticate. After that, credentials are retrieved from the Windows credential store automatically.

Do not use the store helper

credential.helper store writes credentials to a plain-text file in your user profile. On Windows there is no reason to accept that risk when GCM is already installed and uses the encrypted OS credential store.

To clear a stored credential — after rotating a token, for example — open Credential Manager from the Windows Control Panel, select Windows Credentials, and remove the entry for the host.

Inspecting your configuration

git config --list --show-scope --show-origin

This prints every setting with the scope and file it came from. On Windows the three scopes resolve to:

Scope	Typical location
System	C:\Program Files\Git\etc\gitconfig
Global	C:\Users\<you>\.gitconfig
Local	.git\config inside the repository

Local overrides global, and global overrides system.

Troubleshooting

git is not recognised after installing. Open a new terminal. If it still fails, confirm Git is on the PATH:

$env:PATH -split ';' | Select-String 'Git'

If nothing matches, re-run the installer and choose the recommended PATH option.

Every line shows as changed in a diff. A line-ending mismatch. Check git config --get core.autocrlf and consider adding a .gitattributes file as described above.

warning: LF will be replaced by CRLF. Informational, not an error. Git is telling you it is applying the conversion you configured.

Git Bash cannot find a program that works in PowerShell. The two shells have different PATH handling. Use PowerShell for Windows-native tooling and Git Bash for Unix-style workflows.

A credential prompt appears on every push. GCM is not configured. Run git config --global credential.helper manager.

Authentication fails after changing a password or rotating a token. A stale credential is cached. Remove the host’s entry from Windows Credential Manager and try again.

fatal: detected dubious ownership in repository. Git refuses to operate on a repository owned by a different user account — a safety check against a real attack. If the ownership is legitimate (a repository on another drive, or one created by a different account on the same machine):

git config --global --add safe.directory C:/path/to/repo

Add specific paths. Do not disable the check globally.

Long path errors on deeply nested files. Windows historically limited paths to 260 characters:

git config --global core.longpaths true

Working in WSL

If you use Windows Subsystem for Linux, note that WSL has its own filesystem and its own Git installation. Installing Git for Windows does not install Git inside WSL, and the two keep separate configuration files.

Inside a WSL distribution, install Git with that distribution’s package manager — for Ubuntu, follow Lesson 4.

Keep repositories on the filesystem that owns them

Working on files stored under /mnt/c/... from inside WSL is noticeably slow, and line-ending and permission handling gets confusing. Keep Linux projects in the WSL filesystem and Windows projects on the Windows filesystem.

Uninstalling Git

Use Settings → Apps → Installed apps, find Git, and choose uninstall. Or via winget:

winget uninstall --id Git.Git -e

Uninstalling does not delete repositories

Uninstalling removes the Git program. Your project folders and their .git directories are untouched. Conversely, deleting a project’s .git folder destroys that project’s entire history irreversibly, whether or not Git is installed.

Your global configuration in C:\Users\<you>\.gitconfig is not removed. Delete it manually for a clean slate.

What You Learned

• Git for Windows is the official distribution; install it with winget install --id Git.Git -e --source winget or the installer from git-scm.com.
• Open a new terminal after installing so the updated PATH takes effect.
• Git Bash, PowerShell and Command Prompt all run Git identically; Windows Terminal hosts any of them.
• core.autocrlf=true is the correct Windows default, and .gitattributes is the better team-wide fix.
• Git Credential Manager stores credentials in the encrypted Windows credential store.
• Configuration resolves across system, global and local scopes, with local winning.
• WSL has its own separate Git installation and configuration.

Try It Yourself

1. Run git --version and note the Windows-specific version suffix.
2. Run git config --list --show-scope and identify which settings came from the system scope — those are the ones the installer chose for you.
3. Check git config --get core.autocrlf. Predict what it will be before you run it.
4. Create a scratch folder, run git init, and confirm the branch is named main.

Next Lesson

If you also use macOS, the next lesson covers it. Otherwise skip ahead and build a real repository.

Lesson 6 — Installing Git on macOSXcode Command Line Tools or Homebrew, and which binary you actually run.

Lesson 7 — Your First Git RepositoryBuild a repository from scratch and understand every command you run.