Installing and Configuring Git: Complete Guide for Windows, macOS, and Linux
Hands-on tutorial for installing Git on Windows, macOS, and Linux with initial configuration steps, verification, and troubleshooting.
Introduction
Git is the de facto standard for version control, and getting it installed properly is the first step toward professional software development. The installation itself is fairly painless on most platforms, but there are a few choices that affect your day-to-day workflow — things like terminal integration, credential handling, and how Git handles line endings across operating systems.
This guide covers installing Git on Windows, macOS, and Linux, then walks through the essential configuration steps every developer should run before making their first commit. Whether you’re setting up a brand new machine or trying to fix a broken installation, we’ve got you covered.
By the end, you will have a fully functional Git installation with proper identity settings, sensible defaults, and a verified setup ready for development. For deeper configuration options, see Git Config and Global Settings.
When to Use / When Not to Use
Install Git when:
- Starting any software development project
- Setting up a new development machine
- Contributing to open source projects
- Managing configuration files, scripts, or documentation
- Preparing a CI/CD runner or build server
- Learning version control fundamentals
Skip or delay installation when:
- Your organization mandates a different VCS (SVN, Perforce) — install that instead
- You only need to download code without contributing — use
git clonevia a portable Git or GitHub CLI - You are on a restricted system where you cannot install software — use GitHub Codespaces or GitPod
Core Concepts
Git installation has three layers to it: the binary itself, shell integration, and configuration. The binary is just the git executable — a compiled program that runs all the Git commands. Shell integration makes your terminal Git-aware, adding things like tab completion and branch names in your prompt. Configuration is where you set your identity, default editor, line ending behavior, and how Git stores credentials.
graph TD
A[Install Git Binary] --> B[Verify Installation]
B --> C[Configure Identity]
C --> D[Set Defaults]
D --> E[Verify Configuration]
E --> F[Ready for Development]
subgraph "Installation Layers"
A
B
end
subgraph "Configuration"
C
D
E
end
Architecture or Flow Diagram
Git Installation Paths by Platform
graph LR
subgraph "Windows"
W1[Git for Windows Installer] --> W2[Git Bash + Git CMD]
W1 --> W3[WSL Git]
end
subgraph "macOS"
M1[Xcode Command Line Tools] --> M2[System Git]
M3[Homebrew] --> M4[Homebrew Git]
end
subgraph "Linux"
L1[apt/yum/pacman] --> L2[Package Manager Git]
L3[Build from Source] --> L4[Latest Git]
end
W2 --> V[git --version]
W3 --> V
M2 --> V
M4 --> V
L2 --> V
L4 --> V
Step-by-Step Guide / Deep Dive
Installing Git on Windows
Windows offers two primary approaches: the official Git for Windows installer, and Git within WSL (Windows Subsystem for Linux).
Option 1: Git for Windows (Recommended for most users)
-
Download the installer from git-scm.com/download/win
-
Run the installer. The default settings work well for most users, but pay attention to these key choices:
- Select Components: Check “Git Bash Here” and “Git GUI Here” for context menu integration
- Choosing the default editor: Select VS Code, Notepad++, or your preferred editor. Avoid Notepad — it does not handle Unix line endings well
- Adjusting your PATH environment: Choose “Git from the command line and also from 3rd-party software” to make
gitavailable in CMD, PowerShell, and VS Code terminal - Configuring the line ending conversions: Choose “Checkout Windows-style, commit Unix-style line endings” — this is the safest cross-platform option
- Choosing the terminal emulator: Select “Use Windows’ default console window” unless you specifically want MinTTY
- Default behavior for
git pull: Choose “Fast-forward or merge” for flexibility - Credential helper: Choose “Git Credential Manager” for secure password storage
-
Complete the installation and open Git Bash or PowerShell to verify:
git --version
Option 2: Git in WSL
If you use WSL for development, install Git inside your Linux distribution:
# For Ubuntu/Debian
sudo apt update
sudo apt install git
# For Fedora
sudo dnf install git
# For Arch Linux
sudo pacman -S git
# Verify
git --version
Note: WSL Git and Windows Git are separate installations. Files modified in WSL should be committed using WSL Git to avoid line ending issues.
Installing Git on macOS
Option 1: Xcode Command Line Tools (Simplest)
xcode-select --install
A dialog will prompt you to install the tools. This includes Git along with other development utilities. Verify with:
git --version
Option 2: Homebrew (Recommended for latest version)
Homebrew provides more up-to-date Git versions than Xcode’s bundled copy:
# Install Homebrew if you do not have it
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install Git
brew install git
# Verify
git --version
# Optionally, ensure Homebrew Git takes precedence over system Git
echo 'export PATH="/opt/homebrew/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
Installing Git on Linux
Ubuntu/Debian
sudo apt update
sudo apt install git
git --version
Fedora/RHEL/CentOS
sudo dnf install git
# Or for older systems:
# sudo yum install git
git --version
Arch Linux
sudo pacman -S git
git --version
Building from Source (Latest Version)
When your package manager’s Git is outdated:
# Install build dependencies
sudo apt install libz-dev libssl-dev libcurl4-gnutls-dev libexpat1-dev gettext cmake gcc
# Download the latest source
cd /tmp
curl -L https://github.com/git/git/archive/refs/heads/master.tar.gz -o git.tar.gz
tar -zxf git.tar.gz
cd git-master
# Build and install
make configure
./configure --prefix=/usr
make all
sudo make install
git --version
Initial Configuration
After installation, configure your identity and essential settings. These settings are stored in ~/.gitconfig (or %USERPROFILE%\.gitconfig on Windows).
# Set your identity (required for commits)
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
# Set your default editor
git config --global core.editor "code --wait"
# Alternatives:
# git config --global core.editor "vim"
# git config --global core.editor "nano"
# Set the default branch name
git config --global init.defaultBranch main
# Enable colored output
git config --global color.ui auto
# Set your preferred merge tool
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd "code --wait $MERGED"
# Verify all settings
git config --global --list
Verifying Your Installation
Run this checklist to confirm everything works:
# 1. Check Git version
git --version
# 2. Verify identity is set
git config --global user.name
git config --global user.email
# 3. Test a local repository
cd /tmp
mkdir git-test && cd git-test
git init
echo "test" > test.txt
git add test.txt
git commit -m "Test commit"
git log --oneline
# 4. Clean up
cd /
rm -rf /tmp/git-test
Production Failure Scenarios
| Scenario | Impact | Mitigation |
|---|---|---|
| Git not found in PATH after installation | Cannot run any Git commands | Restart terminal; verify PATH includes Git binary directory; reinstall with correct PATH option |
| Wrong Git version on macOS (Apple’s bundled old version) | Missing features, incompatibility with modern workflows | Install via Homebrew and ensure /opt/homebrew/bin precedes /usr/bin in PATH |
| Line ending mismatches between Windows and Linux developers | Spurious diffs, merge conflicts, CI failures | Set core.autocrlf appropriately; use .gitattributes with * text=auto |
| Credential helper not configured | Repeated password prompts, authentication failures | Install Git Credential Manager on Windows; use git config --global credential.helper store or keychain on macOS |
| SSH keys not configured | Cannot push/pull to SSH remotes | Generate SSH key with ssh-keygen, add public key to GitHub/GitLab, test with ssh -T git@github.com |
| Corrupted Git installation | Random errors, segfaults | Reinstall from official source; clear ~/.gitconfig and reinstall |
| PATH conflicts with multiple Git versions on CI runners | Unpredictable behavior, different Git versions executing | Pin Git version in CI config; use which git and git --version in pipeline startup; remove duplicate installations |
Trade-off Analysis
| Factor | Package Manager Install | Official Installer | Build from Source |
|---|---|---|---|
| Ease of setup | One command | GUI wizard | Multiple steps |
| Version freshness | Depends on repo | Current stable | Latest (bleeding edge) |
| Platform integration | Minimal | Full (context menus, credential manager) | None |
| Updates | Via package manager | Manual re-download | Manual rebuild |
| Customization | Limited | Installer options | Full control |
| Best for | Linux, macOS power users | Windows users, beginners | Developers needing latest features |
Implementation Snippets
Windows: Git Bash Profile Customization
# Add to ~/.bashrc in Git Bash
# Show Git branch in prompt
parse_git_branch() {
git branch 2>/dev/null | sed -n 's/^\* \(.*\)/ (\1)/p'
}
export PS1='\[\033[32m\]\u@\h\[\033[00m\]:\[\033[36m\]\w\[\033[33m\]$(parse_git_branch)\[\033[00m\]\$ '
# Useful aliases
alias gs='git status'
alias gl='git log --oneline --graph --all'
alias gd='git diff'
alias gc='git commit -m'
alias gp='git push'
alias gpl='git pull'
alias gco='git checkout'
alias gb='git branch'
macOS: Zsh Git Completion
# Add to ~/.zshrc
# Enable tab completion for Git
autoload -Uz compinit && compinit
# Show Git branch in prompt (using vcs_info)
autoload -Uz vcs_info
precmd_vcs_info() { vcs_info }
precmd_functions+=( precmd_vcs_info )
setopt prompt_subst
RPROMPT=\$vcs_info_msg_0_
zstyle ':vcs_info:git:*' formats ' %b'
Linux: Bash Git Completion
# Ubuntu/Debian
sudo apt install bash-completion
source /etc/bash_completion
# Fedora
sudo dnf install bash-completion
# Download completion script manually
curl -L https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash
source ~/.git-completion.bash
Cross-Platform: Essential Global Config
# Identity
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
# Default branch
git config --global init.defaultBranch main
# Editor
git config --global core.editor "code --wait"
# Line endings (Windows)
git config --global core.autocrlf true
# Line endings (macOS/Linux)
git config --global core.autocrlf input
# Universal line ending handling (recommended)
git config --global core.autocrlf false
# Then use .gitattributes with: * text=auto
# Credential caching
git config --global credential.helper cache --timeout=3600
# Push default
git config --global push.default simple
# Color output
git config --global color.ui auto
# Autocorrect typos
git config --global help.autocorrect 10
Observability Checklist
- Logs: Run
git config --list --show-originto see where each setting comes from - Metrics: Track
git --versionacross your team to ensure everyone uses a compatible version - Traces: Use
GIT_TRACE=1 git <command>to debug installation or configuration issues - Alerts: Monitor for deprecation warnings in Git output (e.g.,
core.autocrlfwarnings) - Audit: Periodically review
~/.gitconfigfor stale or conflicting settings - Health: Run
git config --global --listafter any OS update to verify settings persist - Verification: Verify installer integrity with GPG signature checks — download the signing key from git-scm.com and run
gpg --verifyon the downloaded installer - Version pinning: In CI/CD pipelines, pin the Git version explicitly (e.g.,
git version 2.45.0) rather than relying on the runner’s default, which may change unexpectedly and break builds
Security & Compliance Considerations
- Credential storage: Never use
credential.helper storeon shared machines — it saves passwords in plaintext. Usecache(memory-only, times out) or platform keychains (macOS Keychain, Windows Credential Manager) - SSH keys: Generate keys with
ssh-keygen -t ed25519 -C "your.email@example.com"— Ed25519 is more secure and faster than RSA - GPG signing: Configure commit signing with
git config --global commit.gpgSign trueafter setting up GPG keys - HTTPS vs SSH: Prefer SSH for Git operations — it uses key-based authentication rather than passwords
- Proxy configuration: If behind a corporate proxy, configure it with
git config --global http.proxy http://proxy.company.com:8080
Common Pitfalls / Anti-Patterns
- Installing multiple Git versions: Having Git from Xcode, Homebrew, and MacPorts simultaneously causes confusion. Use
which gitto identify which one runs, and remove duplicates - Skipping identity configuration: Git will use your hostname as the author name, creating embarrassing commit history. Always set
user.nameanduser.emailfirst - Wrong line ending settings on Windows: Setting
core.autocrlf falseon Windows without a.gitattributesfile causes cross-platform conflicts. Usetruefor Windows or rely on.gitattributes - Using an incompatible editor: Setting
core.editorto a GUI editor without the--waitflag causes Git to think the commit message is empty. Always use--waitor-w - Not updating Git: Old Git versions lack critical features and security fixes. Update at least annually
- Ignoring WSL vs Windows Git separation: Editing files in WSL and committing with Windows Git (or vice versa) causes line ending chaos. Use the Git that matches your editing environment
Quick Recap Checklist
Minimum Viable Configuration for a New Developer Machine
- Install Git via the recommended method for your platform
- Verify installation with
git --version - Set
user.nameanduser.emailglobally - Configure your preferred default editor with
--waitflag - Set
init.defaultBranchtomain - Configure line ending handling (
core.autocrlfor.gitattributes) - Set up credential helper for your platform
- Enable colored output with
color.ui auto - Install shell completion and prompt integration
- Test with a local repository to confirm everything works
Interview Questions
core.autocrlf true converts line endings both ways: CRLF to LF on commit, and LF to CRLF on checkout. This is for Windows developers who need CRLF in their working files. core.autocrlf input converts only on commit (CRLF to LF) but does not convert on checkout. This is for macOS/Linux developers who natively use LF and should never receive CRLF files.
Every Git commit embeds the author's name and email directly into the commit object. This information becomes permanent parts of the repository history — they are used for attribution, git blame, and identifying contributors. Without these settings, Git refuses to create commits to prevent anonymous or incorrect attribution. The email does not need to match any remote account, but it should be consistent for accurate history.
push.default simple configures git push to only push the current branch to a remote branch with the same name, and only if the upstream is already set. This prevents accidentally pushing to the wrong branch or pushing all local branches at once. Before Git 2.0, the default was matching, which pushed all branches with matching names — a dangerous behavior that caused unintended pushes.
First, generate an SSH key: ssh-keygen -t ed25519 -C "your@email.com". Add the public key (~/.ssh/id_ed25519.pub) to your GitHub account settings. Then either clone with the SSH URL (git clone git@github.com:user/repo.git) or convert an existing HTTPS remote: git remote set-url origin git@github.com:user/repo.git. Verify with ssh -T git@github.com.
Files with Unix line endings (LF) stay as-is, and files with Windows line endings (CRLF) also stay as-is. This creates cross-platform conflicts when developers on different OSes work on the same files — every contributor sees spurious diffs showing the entire file changed. On Windows, you should either set core.autocrlf true or use a .gitattributes file with * text=auto to normalize line endings automatically.
credential.helper store saves credentials in plaintext in a file on disk (typically ~/.git-credentials), making them readable by anyone with file access. Git Credential Manager (GCM) stores tokens in the OS keychain (Windows Credential Manager, macOS Keychain, or libsecret on Linux), which encrypts them at rest. GCM also supports multi-factor authentication and token refresh flows for GitHub, Azure DevOps, and Bitbucket.
On macOS, multiple Git installations can coexist: Apple's bundled Git in /usr/bin and Homebrew's Git in /opt/homebrew/bin. If your shell profile (~/.zshrc) adds Homebrew's /opt/homebrew/bin to PATH after the initial terminal session reads it, the first session may use Apple's Git while later sessions use Homebrew's. A restart ensures the full PATH is applied. Use which git and git --version to diagnose.
The --wait flag tells the editor to block until the commit message file is closed. Without it, Git launches the editor asynchronously and assumes the commit succeeded immediately — finding an empty commit message or no commit at all. For VS Code, code --wait blocks the terminal; for vim or nano, the terminal naturally blocks since they run in the foreground. GUI editors without --wait will cause Git to think the editor closed before you finished typing.
Package manager installs are fast (one command), platform-integrated, and managed by the system's package manager for updates. Building from source gives you the latest bleeding-edge version, full customization of compile-time options, and the ability to install on systems without a package manager. Drawbacks include longer installation time, manually managing updates, and no automatic integration with platform features like Git GUI tools or context menu handlers on Windows.
First, restart your terminal or Git Bash to pick up the new PATH. If that fails: (1) Check that the Git installation directory is in PATH — typically C:\Program Files\Git\cmd or C:\Program Files\Git\bin. (2) Verify the installer option "Git from the command line and also from 3rd-party software" was selected (not "Use Git Bash only"). (3) Open a new CMD or PowerShell window and test git --version. (4) As a fallback, manually add the path to System PATH in Environment Variables settings.
Ed25519 keys are more secure (256-bit security vs 2048-bit RSA), faster to generate and authenticate with, and produce shorter keys (256 chars vs 544 chars for the public key). RSA keys at 2048 bits are considered minimum secure but Ed25519 provides equivalent security with better performance. Git operations with Ed25519 keys complete noticeably faster on large repositories with frequent SSH authentication.
init.defaultBranch sets the default branch name that Git uses when you run git init without specifying a branch name. The modern convention is main, which has largely replaced the historical default of master. Setting this globally with git config --global init.defaultBranch main ensures all new repositories you create follow the current standard, avoiding the need to rename the default branch later.
GIT_TRACE=1 enables debug tracing for Git operations, printing detailed information about what Git is doing internally — file lookups, config parsing, network operations, and sub-process spawning. You would use it to diagnose installation issues (why Git binary is not found), configuration problems (which config file is being read), or performance issues (slow clone operations). Example: GIT_TRACE=1 git clone https://github.com/user/repo.git.
When Windows developers commit files with CRLF line endings and Linux CI runners check out files with LF line endings (or vice versa), every line in the file appears changed to Git, causing spurious diffs. This can break CI pipelines that depend on file checksums, trigger unnecessary build steps, corrupt binary files mistakenly processed as text, or cause shell scripts to fail with "bad interpreter" errors when the shebang line has invisible CR characters.
credential.helper store saves your Git password or access token in plaintext in a file (typically ~/.git-credentials). Anyone with read access to that file — any user or process on the shared machine — can extract your credentials and authenticate as you to all your Git remotes. On shared computers, use credential.helper cache (stores in memory, times out) or the platform's native keychain (Windows Credential Manager, macOS Keychain, libsecret on Linux).
git config --list shows all configuration values and their final resolved values, but does not show where each setting is defined. --show-origin adds the file path or command-line flag that set each value — for example, /usr/local/etc/gitconfig, ~/.gitconfig, ~/.config/git/config, or --global (command line). This is critical for debugging conflicting settings, identifying stale config from previous installations, or understanding why a setting behaves unexpectedly.
Different Git versions behave differently — some commands, config options, and behaviors change between versions. which git may return one version in your terminal and a different version in a script or CI pipeline, causing inconsistent behavior. Updates to one installation may not reflect in others. Path conflicts can cause the wrong Git to execute. Always use which git and git --version to verify which installation you are using, and remove duplicates to avoid confusion.
Generate a GPG key pair if you do not have one: gpg --full-generate-key (choose RSA 4096). Then tell Git your signing key: git config --global user.signingkey YOUR_KEY_ID. Enable commit signing: git config --global commit.gpgSign true. You can also sign tags: git config --global tag.gpgSign true. GPG signing proves that commits and tags actually came from you, not from someone impersonating your identity — important for open source contribution and code audit trails.
WSL Git and Windows Git are completely separate installations with different filesystem views and line ending behaviors. If you edit files in Windows (mounted at /mnt/c/ in WSL) and commit with Windows Git, the line ending conversion may be inconsistent with commits made in WSL with WSL Git. Files should be edited and committed using the same Git installation that matches your editing environment. Mixing them causes line ending chaos, spurious diffs, and potentially corrupted repositories.
CI/CD runners (GitHub Actions, GitLab CI, etc.) come with a pre-installed Git version that can change when the runner image is updated. If a new Git version changes behavior — deprecating a flag, altering output format, or fixing a bug that scripts depend on — your pipelines break without warning. Pinning to an explicit version (e.g., git version 2.45.0) ensures reproducible builds. Use git --version and which git at the start of each pipeline job to verify the expected version is active.
Further Reading
- Git Downloads — Official downloads for all platforms
- Git for Windows — Windows-specific Git distribution
- Homebrew — macOS package manager
- Pro Git — Getting Started — Detailed installation guide
- GitHub — Connecting to GitHub with SSH — SSH setup guide
- Git Credential Manager — Secure credential storage
Conclusion
A well-configured Git installation is invisible; you never think about it because everything just works. Take the time to get it right, and the rest of your Git journey will be smoother from the very first commit.
Category
Related Posts
Initializing Git Repositories: git init, Clone, and Bare Repositories
Tutorial on git init, cloning remote repositories, bare repositories, and understanding repository structure for new and existing projects.
Daily Git Workflow: From Morning Pull to Evening Push
Hands-on tutorial for a productive daily Git workflow from morning pull to evening push, covering branching, committing, reviewing, and pushing best practices.
Automated Release Pipeline: From Git Commit to Production Deployment
Build a complete automated release pipeline with Git, CI/CD, semantic versioning, changelog generation, and zero-touch deployment. Hands-on tutorial for production-ready releases.