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.

published: reading time: 21 min read author: Geek Workbench updated: March 31, 2026

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 clone via 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).

  1. Download the installer from git-scm.com/download/win

  2. 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 git available 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
  3. 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

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

ScenarioImpactMitigation
Git not found in PATH after installationCannot run any Git commandsRestart 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 workflowsInstall via Homebrew and ensure /opt/homebrew/bin precedes /usr/bin in PATH
Line ending mismatches between Windows and Linux developersSpurious diffs, merge conflicts, CI failuresSet core.autocrlf appropriately; use .gitattributes with * text=auto
Credential helper not configuredRepeated password prompts, authentication failuresInstall Git Credential Manager on Windows; use git config --global credential.helper store or keychain on macOS
SSH keys not configuredCannot push/pull to SSH remotesGenerate SSH key with ssh-keygen, add public key to GitHub/GitLab, test with ssh -T git@github.com
Corrupted Git installationRandom errors, segfaultsReinstall from official source; clear ~/.gitconfig and reinstall
PATH conflicts with multiple Git versions on CI runnersUnpredictable behavior, different Git versions executingPin Git version in CI config; use which git and git --version in pipeline startup; remove duplicate installations

Trade-off Analysis

FactorPackage Manager InstallOfficial InstallerBuild from Source
Ease of setupOne commandGUI wizardMultiple steps
Version freshnessDepends on repoCurrent stableLatest (bleeding edge)
Platform integrationMinimalFull (context menus, credential manager)None
UpdatesVia package managerManual re-downloadManual rebuild
CustomizationLimitedInstaller optionsFull control
Best forLinux, macOS power usersWindows users, beginnersDevelopers 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-origin to see where each setting comes from
  • Metrics: Track git --version across 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.autocrlf warnings)
  • Audit: Periodically review ~/.gitconfig for stale or conflicting settings
  • Health: Run git config --global --list after 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 --verify on 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 store on shared machines — it saves passwords in plaintext. Use cache (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 true after 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 git to 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.name and user.email first
  • Wrong line ending settings on Windows: Setting core.autocrlf false on Windows without a .gitattributes file causes cross-platform conflicts. Use true for Windows or rely on .gitattributes
  • Using an incompatible editor: Setting core.editor to a GUI editor without the --wait flag causes Git to think the commit message is empty. Always use --wait or -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.name and user.email globally
  • Configure your preferred default editor with --wait flag
  • Set init.defaultBranch to main
  • Configure line ending handling (core.autocrlf or .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

1. What is the difference between `core.autocrlf true` and `core.autocrlf input`?

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.

2. Why does Git require both `user.name` and `user.email` for commits?

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.

3. What does `push.default simple` do and why is it the recommended setting?

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.

4. How do you configure Git to use SSH instead of HTTPS for GitHub?

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.

5. What happens if you set `core.autocrlf false` on Windows without a `.gitattributes` file?

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.

6. How does Git Credential Manager differ from `credential.helper store` in terms of security?

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.

7. Why might `git --version` return different results before and after restarting your terminal on macOS?

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.

8. What is the purpose of the `--wait` flag when setting `core.editor`?

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.

9. What is the difference between building Git from source versus using a package manager install?

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.

10. How do you troubleshoot "git command not found" after installing Git 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.

11. Why should you use Ed25519 SSH keys over RSA for Git authentication?

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.

12. What is the purpose of `init.defaultBranch` and what value should you use?

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.

13. What does `GIT_TRACE=1` do and when would you use it?

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.

14. How do line ending mismatches between Windows and Linux developers cause CI failures?

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.

15. What is the security risk of using `credential.helper store` on a shared computer?

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).

16. What does `git config --list --show-origin` reveal that `git config --list` does not?

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.

17. Why is it dangerous to have multiple Git installations on the same machine (e.g., Xcode Git, Homebrew Git, MacPorts Git on macOS)?

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.

18. How do you configure a GPG signing key for Git commits and why is it important?

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.

19. What is the difference between WSL Git and Windows Git when working on the same codebase?

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.

20. Why should Git versions be pinned in CI/CD pipelines rather than using the runner's default Git?

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

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.

#git #init #clone

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.

#git #workflow #daily

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.

#git #version-control #ci-cd