Install and Configure Git on Windows, macOS & Linux

How to Install and Configure Git on Windows, macOS, and Linux

Installing Git is easy. Installing it in a way that produces correct commit identities, predictable line endings, a usable editor, and secure authentication requires a little more care.

This guide walks through Git installation on Windows, macOS, and Linux, then builds a clean first-time configuration. It explains not only which commands to run, but what each setting controls, where Git stores it, and how to diagnose common problems.

By the end, you will have a working Git command-line environment and a configuration that is ready for the first real repository.

What You Will Configure

A complete beginner setup includes more than verifying that the git command exists. The essential tasks are:

Install Git using an appropriate method for your operating system.
Verify which Git executable and version your terminal is using.
Configure the name and email written into future commits.
Choose a default branch name for new repositories.
Select the editor Git opens for commit messages and other operations.
Understand configuration scopes and precedence.
Choose a deliberate line-ending policy.
Use a secure credential helper for HTTPS authentication.
Check the final configuration and its source files.
Create a test repository to confirm the environment works.

Before Installing Git

Before downloading anything, check whether Git is already installed:

git --version

A successful result looks similar to:

git version 2.x.x

The exact version number depends on the operating system, package source, and update date.

If the terminal reports that git is not recognized or cannot be found, Git is either not installed or its executable directory is not available through the system’s PATH.

If Git is installed, also identify which executable is being used.

On Windows PowerShell:

Get-Command git

On Command Prompt:

where git

On macOS or Linux:

which git

This check is useful when multiple Git installations exist. For example, a computer may have one Git version installed by the operating system and another installed by a package manager.

Choose an Installation Method Deliberately

There are three common ways to install Git:

Official or maintained installer: Common on Windows.
Operating-system package manager: Common on Linux and useful on macOS.
Build from source: Appropriate for advanced users who need a specific version or compilation options.

For most developers, the maintained installer or the normal package manager is the best choice. Building from source adds maintenance work and is rarely necessary for a first setup.

Installing Git on Windows

The standard Windows distribution is Git for Windows. It includes the Git command-line tools and Git Bash, a terminal that provides a Unix-like shell environment on Windows.

You can install Git for Windows through the graphical installer or through Windows Package Manager.

Method 1: Install Git for Windows with the Installer

Open the official Git installation page for Windows.
Choose the installer that matches your processor architecture, usually x64 or ARM64.
Run the downloaded setup file.
Review the installation screens and choose settings intentionally.
Finish the installation and reopen any terminals that were already running.

The installer changes over time, so some labels may differ slightly. The following decisions are the ones that matter most.

Choosing Components

The default components are suitable for most beginners. Git Bash is particularly useful because many Git tutorials use shell syntax that works naturally there.

Optional context-menu entries such as “Git Bash Here” can be convenient, but they are not required for Git itself.

Choosing the Default Editor

Git sometimes opens a text editor when it needs a commit message, merge message, rebase plan, or tag description.

Choose an editor you can confidently save and close. Visual Studio Code is a practical option when it is already installed. Vim is powerful, but selecting it without knowing its basic commands can leave a beginner apparently trapped inside an editor.

You can change this setting later, so the installer choice is not permanent.

Adding Git to PATH

The installer normally offers options controlling where the git command can be used.

For a typical development computer, choose an option that allows Git to run from Git Bash and other command-line environments such as PowerShell, Command Prompt, IDE terminals, and automation tools.

A restrictive PATH option may cause Git to work in Git Bash but fail in PowerShell or an IDE.

Choosing an SSH Implementation

Git for Windows can use an included OpenSSH client or another SSH installation already present on the computer.

The bundled OpenSSH option is usually the simplest choice for a new setup because it provides a predictable environment. Use an external SSH client only when you already have a deliberate system-wide SSH configuration.

Choosing the HTTPS Backend

The installer may offer an HTTPS transport choice. The default selection is generally appropriate. Corporate environments with custom certificates or managed Windows trust stores may require a specific option defined by the organization’s IT policy.

Do not disable certificate verification to work around HTTPS errors. Fix the trusted certificate configuration instead.

Choosing Line-Ending Behavior

Windows commonly uses CRLF line endings, while Linux and macOS commonly use LF. Git for Windows may offer a default conversion policy during installation.

For a new developer, accepting the default is usually workable. However, line endings are a project-level concern, so teams should eventually define them through a committed .gitattributes file rather than relying only on individual installer choices.

A detailed explanation appears later in this guide.

Terminal and Console Options

Git Bash normally uses its own terminal environment, while Git commands can also run in Windows Terminal, PowerShell, Command Prompt, and IDE terminals.

There is no requirement to use one terminal exclusively. What matters is that the same intended Git executable is being found in each environment.

Credential Manager

When the installer offers Git Credential Manager, it is generally useful for developers who authenticate to remote repositories over HTTPS. A credential manager can integrate with secure system storage and modern sign-in flows instead of forcing you to enter or manually store tokens repeatedly.

Method 2: Install Git with winget

Open PowerShell or Command Prompt and run:

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

After installation, close and reopen the terminal, then verify:

git --version
where git

Which Windows Terminal Should You Use?

Git works in several Windows shells:

Git Bash: Convenient for Unix-like commands and many online tutorials.
PowerShell: Strong integration with Windows administration and modern developer tooling.
Command Prompt: Supported, but less expressive than PowerShell for scripting.
Windows Terminal: A terminal application that can host PowerShell, Command Prompt, Git Bash, and WSL profiles.
IDE terminal: Useful when working directly inside Visual Studio Code, PhpStorm, IntelliJ IDEA, or similar tools.

Learning Git does not require learning Bash first. Use a terminal you understand, but pay attention to shell-specific commands such as file creation, environment variables, and path syntax.

Installing Git on macOS

macOS offers several installation methods. The best choice depends on whether you want the Apple-provided command-line tools or prefer a package manager that can install and update a separate Git release.

Method 1: Xcode Command Line Tools

Run:

xcode-select --install

Follow the macOS prompt, then verify:

git --version
which git

The Xcode Command Line Tools include more than Git. They also provide compilers and utilities commonly needed by development environments.

Method 2: Homebrew

If Homebrew is already installed, run:

brew install git

Then verify the executable path:

git --version
which git

If macOS still uses a different Git executable, inspect your shell’s PATH. On Apple Silicon and Intel systems, package-manager paths may differ.

To update a Homebrew-managed Git installation later:

brew update
brew upgrade git

Method 3: MacPorts

When your environment already uses MacPorts:

sudo port install git

Do not install multiple package managers solely to install Git. Use the package ecosystem already chosen for the machine.

Why macOS May Show More Than One Git

A macOS computer may have an Apple-provided Git and a package-manager Git. This is not automatically an error, but the shell uses the first matching executable in PATH.

Inspect the active command:

which -a git
git --version

If an IDE reports a different Git version from the terminal, check the IDE’s Git executable path in its settings.

Installing Git on Linux

On Linux, use the package manager provided by your distribution. This gives you predictable integration with system updates and dependencies.

Debian and Ubuntu

sudo apt update
sudo apt install git

Fedora

sudo dnf install git

Arch Linux

sudo pacman -S git

openSUSE

sudo zypper install git

Alpine Linux

sudo apk add git

Gentoo

sudo emerge --ask --verbose dev-vcs/git

FreeBSD

sudo pkg install git

After installation, verify:

git --version
which git

Distribution Package vs Latest Upstream Release

A distribution may provide a Git version older than the newest upstream release. That does not automatically make it unusable. Stable distributions often prioritize tested package combinations and long-term maintenance.

Before replacing a distribution package, ask whether you actually need a feature introduced in a newer release. Adding external repositories or compiling from source creates an additional maintenance responsibility.

Git on Windows vs Git Inside WSL

Windows Subsystem for Linux is a Linux environment running alongside Windows. Git installed in Windows and Git installed inside a WSL distribution are separate installations with separate configuration files.

Inside WSL, install Git using the distribution’s package manager:

sudo apt update
sudo apt install git

Then configure Git inside WSL, even if you already configured Git for Windows.

Keep the distinction clear:

Windows Git uses Windows paths and Windows-side configuration.
WSL Git uses Linux paths and Linux-side configuration.
An IDE may use either one depending on whether the project is opened locally or through a WSL integration.

For best performance and fewer permission problems, projects used mainly by Linux tools are often kept in the WSL filesystem, while Windows-native projects remain in the Windows filesystem.

Verifying the Installation

After installing Git, restart the terminal and run:

git --version

Then locate the executable:

# Windows Command Prompt
where git

# Windows PowerShell
Get-Command git

# macOS or Linux
which git

Also verify that Git can open its built-in help:

git help config

Or use the shorter command:

git config -h

If these commands work, the installation is available to the current terminal.

Understanding Git Configuration

Git behavior is controlled through configuration variables. These variables can exist at different scopes.

Scope	Typical Purpose	Common Location
System	Defaults for every user on the machine	Installation-level Git config
Global	Defaults for the current user	`~/.gitconfig` or user config directory
Local	Settings for one repository	`.git/config`
Worktree	Settings for one linked worktree when enabled	`.git/config.worktree`

More specific scopes override broader ones. A repository-local email can override the global email, while the global value remains active in other repositories.

This is useful when one computer is used for both personal and company work.

Modern and Classic git config Syntax

Current Git documentation provides explicit subcommands:

git config set --global user.name "Jane Developer"
git config get --global user.name
git config list --global

Many tutorials and existing scripts use the classic syntax:

git config --global user.name "Jane Developer"
git config --global --get user.name
git config --global --list

The classic form remains widely encountered. This guide uses it in many examples because it works across a broad range of Git versions, while also showing modern forms where useful.

Configure Your Commit Identity

Set the name and email Git will write into new commits:

git config --global user.name "Jane Developer"
git config --global user.email "jane@example.com"

Check the values:

git config --global --get user.name
git config --global --get user.email

Or with current explicit subcommands:

git config get --global user.name
git config get --global user.email

Your Git Name Is Not a Hosting Username

user.name normally represents the human-readable author name placed in commits. It does not need to match a GitHub, GitLab, or Bitbucket username.

user.email is also commit metadata. Authentication credentials are handled separately through HTTPS credential helpers or SSH keys.

Why the Email Address Matters

Hosting platforms may associate commits with your account when the commit email matches a verified address or a platform-provided privacy address.

Choose the address intentionally. A personal repository may use a personal email, while a company repository may require a work email.

Use a Different Identity for One Repository

Inside the repository, run the commands without --global:

git config user.name "Jane Developer"
git config user.email "jane@company.example"

Verify where the final value came from:

git config --show-origin --get user.email

Prevent Git from Guessing an Identity

Developers who regularly switch between multiple identities can require explicit configuration:

git config --global user.useConfigOnly true

With this setting, Git avoids silently guessing a name or email when the required identity is missing. This can prevent work commits from accidentally using a personal address, or the reverse.

Set the Default Initial Branch Name

Choose the name Git should use when initializing new repositories:

git config --global init.defaultBranch main

This affects future repositories created with git init. It does not rename branches in existing repositories.

Check the value:

git config --global --get init.defaultBranch

If an organization uses another convention, such as trunk, configure that name instead.

Configure Git’s Default Editor

Git opens an editor when it needs interactive text input. The editor command must wait until you finish editing; otherwise Git may continue before the file is saved.

Visual Studio Code

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

The --wait option keeps the Git process waiting until the editor tab is closed.

Vim

git config --global core.editor "vim"

Nano

git config --global core.editor "nano"

Windows Notepad

git config --global core.editor "notepad"

Test the Editor Configuration

git config --global --edit

The configured editor should open the global Git configuration file. Close it without making changes if you are only testing.

If Git appears frozen during a commit or merge, check whether an editor window or terminal-based editor is waiting for input.

Configure Line Endings Carefully

Text files normally use one of two line-ending styles:

LF: Standard on Linux and macOS.
CRLF: Common in Windows-native text files.

Uncontrolled line-ending conversions can make every line in a file appear changed, create noisy reviews, or break scripts that require LF.

Understanding core.autocrlf

Common values are:

true: Normalize text to LF in the repository and commonly use CRLF in the working tree.
input: Normalize CRLF to LF when adding content, but do not convert LF to CRLF during checkout.
false: Disable automatic conversion controlled by this setting.

A common Windows configuration is:

git config --global core.autocrlf true

A common macOS or Linux configuration is:

git config --global core.autocrlf input

These are not universal rules. A team’s repository policy should take priority.

Prefer .gitattributes for Team Projects

A committed .gitattributes file gives every contributor a shared policy.

Example:

* text=auto

*.sh text eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf

*.png binary
*.jpg binary
*.pdf binary

This approach is more reliable than assuming every contributor has identical global settings.

Enable Line-Ending Safety Warnings

You can ask Git to warn about potentially irreversible conversions:

git config --global core.safecrlf warn

Use true instead of warn only when you want Git to reject conversions that fail its safety check.

Do Not Normalize an Existing Repository Blindly

Adding a line-ending policy to an established project can produce a large normalization commit. Plan that change separately, start from a clean working tree, review the result carefully, and avoid mixing normalization with functional code changes.

Configure Color Output

Git already uses automatic terminal colors by default in modern versions. You can make the intention explicit:

git config --global color.ui auto

auto adds color when output goes to an interactive terminal but avoids forcing terminal control codes into redirected output.

Configure a Global Ignore File

A repository’s .gitignore should contain project-specific patterns that every contributor needs.

A global ignore file is appropriate for files created only by your personal operating system or editor.

Create a file:

# macOS or Linux
touch ~/.gitignore_global

# Git Bash on Windows
touch ~/.gitignore_global

Configure Git to use it:

git config --global core.excludesFile ~/.gitignore_global

Example personal patterns:

.DS_Store
Thumbs.db
.idea/workspace.xml
*.swp

Do not place required project rules only in a personal global file. Other developers and CI environments will not receive it.

Configure HTTPS Credentials Securely

Git can call a credential helper when an HTTPS remote requires authentication. The helper may cache credentials temporarily, store them in secure operating-system storage, or handle modern browser-based sign-in.

Inspect configured helpers:

git config --show-origin --get-all credential.helper

On Git for Windows, Git Credential Manager is commonly installed and configured automatically when selected in the installer.

Git Credential Manager is also available on macOS and Linux. When installed, it can integrate with supported hosting services and secure credential storage.

Avoid Plain-Text Credential Storage

The built-in store helper writes credentials to a file without encryption. Do not use it casually on a personal or shared computer:

# Avoid unless you fully understand the security tradeoff
git config --global credential.helper store

Prefer an operating-system keychain, Git Credential Manager, or SSH authentication.

Credentials Are Not user.name and user.email

These settings:

user.name
user.email

control commit authorship. They do not log you into a remote hosting service.

Authentication is handled by:

An HTTPS credential helper.
A personal access token handled by an approved client.
An SSH key and SSH agent.
An organization-specific authentication system.

Should You Configure SSH Now?

SSH is useful for remote repository authentication, but it is separate from installing Git itself.

A complete SSH setup includes:

Generating a key pair.
Protecting the private key.
Loading it into an SSH agent.
Adding the public key to the hosting platform.
Testing the connection.
Managing multiple accounts when necessary.

That process deserves its own article. For this installation guide, it is enough to understand that Git can use either HTTPS or SSH remote URLs.

Optional Quality-of-Life Settings

These settings are useful but not required for the first commit.

Automatically Set the Upstream on First Push

git config --global push.autoSetupRemote true

This can simplify the first push of a new branch in common central workflows. Teams with unusual remote conventions may prefer explicit commands.

Create Simple Aliases

git config --global alias.st status
git config --global alias.br branch
git config --global alias.co checkout
git config --global alias.last "log -1 HEAD"

Then:

git st
git br
git last

Do not create so many aliases that standard Git commands become unfamiliar. Documentation, error messages, and teammates usually use the original command names.

Do Not Choose a Global Pull Strategy Without Understanding It

Git can integrate fetched changes through merge, rebase, or fast-forward-only behavior. These choices affect project history.

Examples include:

git config --global pull.rebase false
git config --global pull.rebase true
git config --global pull.ff only

Do not copy one of these settings merely to silence a message. Learn the team’s workflow first, then choose the behavior deliberately.

Inspect the Final Configuration

List all effective settings and their source files:

git config --list --show-origin

With modern explicit syntax:

git config list --show-origin

Inspect one value:

git config --show-origin --get user.email

Inspect only global settings:

git config --global --list

Open the global file:

git config --global --edit

Git configuration files use a format similar to:

[user]
    name = Jane Developer
    email = jane@example.com

[init]
    defaultBranch = main

[core]
    editor = code --wait
    autocrlf = input

[color]
    ui = auto

Using git config commands is usually safer than manually editing the file because the command validates names and writes values with the correct syntax.

Recommended Beginner Configuration

Replace the example identity before running these commands.

git config --global user.name "Jane Developer"
git config --global user.email "jane@example.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"
git config --global color.ui auto
git config --global core.safecrlf warn

Then choose the line-ending setting that matches your environment and project policy.

Typical Windows starting point:

git config --global core.autocrlf true

Typical macOS or Linux starting point:

git config --global core.autocrlf input

Finally, inspect the result:

git config --list --show-origin

Create a Test Repository

A configuration is not truly verified until Git creates a commit.

macOS, Linux, or Git Bash

mkdir git-setup-test
cd git-setup-test

git init

echo "# Git Setup Test" > README.md

git add README.md
git commit -m "Create setup test repository"

git log --oneline --show-signature
git status

PowerShell

New-Item -ItemType Directory git-setup-test
Set-Location git-setup-test

git init

"# Git Setup Test" | Set-Content README.md

git add README.md
git commit -m "Create setup test repository"

git log --oneline
git status

The expected results are:

The repository initializes with the chosen default branch name.
The commit completes without asking for missing identity information.
The log shows your intended author name and commit.
git status reports a clean working tree.

Inspect the author details precisely:

git log -1 --format=fuller

Changing or Removing a Configuration Value

Set a new value by running the configuration command again:

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

Remove a global value:

git config --global --unset user.email

Modern syntax:

git config unset --global user.email

When a key has multiple values, inspect all of them first:

git config --global --get-all credential.helper

Then use an appropriate unset command carefully. Credential-helper configurations may intentionally contain multiple entries.

Updating Git

The update method should match the installation method.

Windows

Use the Git for Windows updater, install the latest maintained release over the existing installation, or update through winget:

winget upgrade --id Git.Git -e

Homebrew on macOS

brew update
brew upgrade git

Debian or Ubuntu

sudo apt update
sudo apt upgrade git

Fedora

sudo dnf upgrade git

After updating:

git --version

User-level configuration normally survives Git upgrades because it is stored separately from the application binaries.

Common Installation and Configuration Problems

“git is not recognized” on Windows

Likely causes include:

The terminal was open before Git was installed.
The installer did not add Git to the intended PATH.
An IDE has not refreshed its environment.
The installation failed or was removed.

First close and reopen the terminal. Then run:

where git

If no path appears, repair or reinstall Git and review the PATH option.

“command not found: git” on macOS or Linux

Verify the package installation and PATH:

which git
echo $PATH

On macOS, install the Xcode Command Line Tools or verify the package-manager path.

The terminal and IDE show different Git versions

The IDE may be configured with an explicit executable path. Compare:

git --version
which git

or on Windows:

git --version
where git

Then inspect the IDE’s Git settings.

Commits use the wrong email address

Check the effective value and its source:

git config --show-origin --get user.email

A repository-local configuration may be overriding the global setting.

Git opens an unfamiliar editor

Configure an editor you know:

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

If a Git operation is already waiting, finish or cancel the current editor session before trying again.

Every line appears changed

This usually indicates a line-ending or formatting conversion. Check:

git config --show-origin --get core.autocrlf
git diff --ignore-space-at-eol

Also inspect the repository’s .gitattributes. Do not commit a huge change until you understand whether it is functional or only normalization.

Git warns about an unsafe repository

Git may reject a repository owned by another operating-system user as a security precaution. Fix ownership or permissions when they are wrong.

Only add a repository to safe.directory when you understand why its ownership differs and trust the path. Avoid disabling the protection globally with a wildcard.

Authentication keeps asking for credentials

Inspect the remote URL and credential helper:

git remote -v
git config --show-origin --get-all credential.helper

Possible causes include an expired token, an incorrect remote protocol, a missing credential helper, a locked keychain, or an organization requiring a specific authentication method.

HTTPS certificate errors

Do not solve the problem by globally disabling SSL verification:

# Do not use this as a general fix
git config --global http.sslVerify false

Instead, install the organization’s trusted certificate chain correctly or follow the approved proxy and certificate configuration.

Duplicate configuration values appear

Run:

git config --list --show-origin

The same key may exist at system, global, and local scopes. Git applies precedence rules, so duplicates are not always an error. Remove only the unintended entry from the correct scope.

Git works in Windows but not WSL

Install Git inside the WSL distribution and configure it there. Windows and WSL do not automatically share the same Git executable or global configuration.

Configuration Mistakes to Avoid

Using a fake or unintended email address in commits.
Assuming user.name is a remote-platform login.
Configuring a text editor that you do not know how to close.
Copying a global rebase or pull policy without understanding the team workflow.
Disabling HTTPS certificate verification.
Storing access tokens with the unencrypted credential-store helper.
Applying line-ending normalization in a large repository without review.
Using safe.directory=* as a broad workaround.
Editing multiple config files without checking which scope wins.
Assuming the Git used by an IDE is the same executable used by the terminal.

Installation and Configuration Checklist

Run git --version successfully.
Confirm the active executable path.
Set the correct commit author name.
Set the correct commit email.
Configure main or the organization’s required initial branch.
Choose and test a default editor.
Review the line-ending policy.
Confirm the credential helper is secure.
Inspect configuration with --show-origin.
Create a test repository and a successful commit.
Verify the commit author with git log -1 --format=fuller.

Frequently Asked Questions

Do I Need GitHub to Install Git?

No. Git is an independent version control system. GitHub is one of several services that can host remote Git repositories.

Should I Install a Git GUI?

A graphical client is optional. Learning the command line first provides a transferable understanding that works across operating systems, servers, IDEs, and hosting platforms. A GUI can be added later without replacing Git itself.

Can I Use Git Bash and PowerShell on the Same Computer?

Yes. Both can call the same Git for Windows installation when PATH is configured correctly.

Should My Git Email Match My GitHub Email?

It should match an address recognized by the hosting account when you want commits associated with that account. You may also use a platform-provided privacy address.

Should Windows Developers Always Use core.autocrlf=true?

Not always. It is a common starting point, but a committed .gitattributes policy and the requirements of the project are more important than a universal rule.

Why Does Git Need an Editor?

Git uses an editor for commit messages, merge messages, interactive rebases, annotated tags, and configuration editing when text must be entered interactively.

Do Global Settings Affect Existing Repositories?

Global defaults apply unless a more specific local setting overrides them. Some settings, such as init.defaultBranch, affect only repositories initialized after the setting is configured.

Can I Have Different Git Identities for Work and Personal Projects?

Yes. Set a global default, then configure local user.name and user.email values inside repositories that need a different identity. Advanced users can also use conditional configuration includes.

Is Git Credential Manager the Same as Git?

No. It is a credential helper that Git can call for secure authentication workflows. Git itself manages repository history.

Conclusion

A reliable Git environment begins with three layers: a correctly installed executable, an intentional user configuration, and a tested repository workflow.

Installation gives the system access to Git. Configuration determines how Git identifies your commits, names new branches, opens interactive text, handles line endings, and obtains remote credentials. Testing confirms that these pieces work together.

Do not treat the setup commands as values to copy blindly. Understand their scope and purpose. In particular, commit identity, line endings, authentication, and pull behavior can affect both the developer and the entire team.

With Git now installed and configured, the next step is to create a repository, inspect its state, add files, and understand how the working directory, staging area, and first commit connect in a practical workflow.

Official References and Further Reading