What You'll Set Up

Git is the version-control system behind almost every modern software project, and installing it on Windows 11 gives you two things in one package: the Git command-line tools and Git Bash, a Unix-like terminal where you can run familiar commands like ls, cat, and ssh-keygen. This guide walks you from a fresh machine to pushing your first commit in about 20 minutes. It's aimed at developers, students, and anyone who needs to clone a repo, contribute to a project, or deploy code from Windows.

Prerequisites

  • A PC running Windows 11 (64-bit — virtually every machine sold since 2020)
  • An administrator account on the machine (needed to install software for all users)
  • An active internet connection to download the installer
  • About 500 MB of free disk space

Step 1: Download the Official Git Installer

Go to the official Git for Windows site at git-scm.com and click the big Download for Windows button. This always fetches the current stable release (2.4x as of 2026). Do not grab Git from random tutorial download links or outdated bundles — installers from unofficial mirrors can be tampered with.

You can also download it from the terminal with winget, Windows' built-in package manager:

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

This installs the exact same official package, silently. Either method works; pick the one you like. If you use the graphical installer, continue to Step 2. If you used winget, skip to Step 3.

Step 2: Run the Installer with the Right Options

Double-click the downloaded .exe and approve the UAC prompt. The installer walks through a dozen screens — most defaults are fine, but a few choices matter. Here's what to pick on the important screens:

  1. Select Components: keep everything checked, especially Git Bash Here, Git GUI Here, and Associate .git* configuration files with the default text editor. These add the right-click context-menu shortcuts you'll use constantly.
  2. Choosing the default editor used by Git: leave it on Use Vim (the default), or pick Use Visual Studio Code as Git's default editor if you have VS Code — it makes resolving merge conflicts far less painful.
  3. Adjusting the name of the initial branch in new repositories: choose Override the default branch name for new repositories and set it to main. GitHub, GitLab, and Bitbucket all use main now, and matching them avoids the old master/main mismatch.
  4. Adjusting your PATH environment: keep Git from the command line and also from 3rd-party software selected. This is the screen that decides whether git works in Command Prompt and PowerShell — the recommended option keeps it simple.
  5. Choosing HTTPS transport backend: leave Use the OpenSSL library selected unless you work in a corporate environment with Windows certificate stores (then pick the Windows Secure Channel option).
  6. Configuring the line ending conversions: choose Checkout as-is, commit as-is. The older Windows-style conversion (CRLF on checkout) causes noisy diffs when your teammates work on Linux or macOS. The as-is option avoids it.
  7. Configuring the terminal emulator: keep Use MinTTY. It's faster, resizable, and handles Unicode better than the legacy Windows console window.
  8. Configuring the credential helper: keep Git Credential Manager checked. It securely stores your GitHub/GitLab tokens in the Windows Credential Manager so you're not asked to log in on every push.

Click Install and let it finish. The whole process takes under two minutes.

Step 3: Verify the Installation

Open Git Bash from the Start menu (or right-click your Desktop and choose Open Git Bash Here), then run:

git --version

You should see something like git version 2.47.1.windows.1. Now confirm the tools are also reachable from PowerShell — this is what IDEs like VS Code rely on:

git --version

Run that in a fresh PowerShell or Command Prompt window. If both print a version number, Git is correctly on your PATH. Also confirm Git LFS (Large File Storage) is present — it ships bundled with Git for Windows:

git lfs version

Step 4: Configure Your Identity

Every commit you create is stamped with a name and email. Set them once, globally, with:

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

These values are stored in C:\Users\YourName\.gitconfig. Use the name you want on your public commits — for GitHub, the email must match one of the addresses on your GitHub account, or your commits won't be linked to your profile. Add a few quality-of-life defaults at the same time:

git config --global init.defaultBranch main
git config --global credential.helper manager
git config --global core.editor "code --wait"
git config --global pull.rebase false

What these do: init.defaultBranch makes every new local repo start on main (matching Step 2's installer choice); credential.helper tells Git to use the Git Credential Manager you installed; core.editor opens VS Code whenever Git needs you to write a commit message or resolve a conflict (replace with notepad if you don't have VS Code); pull.rebase false keeps git pull behaving like a plain merge instead of silently rewriting history.

Step 5: Set Up SSH Authentication (Recommended)

HTTPS + credential manager works fine, but SSH keys are more convenient once set up: no browser login popups, and they work from any terminal, including VS Code's integrated terminal. In Git Bash, run:

ssh-keygen -t ed25519 -C "you@example.com"

Press Enter to accept the default file location (~/.ssh/id_ed25519), and set a passphrase when asked — it protects the key if your laptop is stolen. Start the SSH agent and add the key:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Display the public key and copy it:

cat ~/.ssh/id_ed25519.pub

Paste the entire line into GitHub → Settings → SSH and GPG keys → New SSH key (or the equivalent on GitLab/Bitbucket). Then test the connection:

ssh -T git@github.com

A reply like "Hi username! You've successfully authenticated" means SSH is working.

Step 6: Clone a Repository and Make Your First Commit

Time to prove everything works end to end. Create a test repository on GitHub (any name, no README), then clone it into your Documents folder:

cd ~/Documents
git clone git@github.com:yourusername/test-repo.git
cd test-repo

Add a file, stage it, commit, and push:

echo "# My first Git repo" > README.md
git add README.md
git commit -m "Add README"
git push -u origin main

Refresh the GitHub page for your repo — the README should be there. You've just done the full loop: clone, edit, stage, commit, push.

Verify It Worked

Run this quick checklist to confirm a complete, healthy setup:

  1. git --version works in both Git Bash and PowerShell.
  2. git config --list --global shows your user.name, user.email, and init.defaultBranch=main.
  3. git config credential.helper prints manager — this is what saves you from re-entering passwords.
  4. SSH users: ssh -T git@github.com authenticates successfully.
  5. You can clone, commit, and push a test repository without errors.

If you cloned over HTTPS, also check that your first push didn't ask for a password twice — the credential helper should have remembered the token.

Common Issues and Fixes

1. "'git' is not recognized as an internal or external command"

This means the installer didn't add Git to your PATH (the Step 2 option), or the change hasn't reached the open terminal. Close and reopen the terminal window first. If it still fails, reinstall and make sure "Git from the command line and also from 3rd-party software" is selected. As a last resort, add C:\Program Files\Git\bin and C:\Program Files\Git\cmd to your PATH manually via System Properties → Environment Variables.

2. Whole files show as changed after cloning a Linux repo

Classic CRLF/LF line-ending noise. You probably chose "Checkout Windows-style, commit Unix-style line endings" during installation, and now every file looks modified. Fix it without re-installing:

git config --global core.autocrlf false
git rm --cached -r .
git reset --hard

This tells Git to leave line endings alone, then re-checks out the files cleanly. On a shared project, ask your team what they use and match it.

3. Git keeps asking for credentials on every push

First check which helper is active: git config credential.helper. If it's empty, set it with git config --global credential.helper manager. If the helper is set but logins still repeat, your saved token probably expired — open Credential Manager in the Windows Control Panel, delete the git:https://github.com entry, and push again so you're re-prompted to sign in fresh. Never paste a GitHub password when prompted — GitHub requires a personal access token (or the OAuth flow the credential manager starts) since 2021.

4. "SSL certificate problem: unable to get local issuer certificate"

Common behind corporate proxies or outdated CA bundles. First update Git to the latest release (winget upgrade Git.Git or re-download the installer), since newer releases ship fresh certificates. If the problem persists in a corporate environment, switch the HTTPS backend to Windows' own certificate store:

git config --global http.sslBackend schannel

Only use http.sslVerify false as a temporary debug measure — never as a permanent fix, because it disables the security that HTTPS provides.

5. Git Bash prompt doesn't show the current branch

The default Git Bash prompt (user@machine MINGW64 ~$) shows the directory but not the branch unless the git-prompt helper is active. If you customized your .bashrc, make sure it sources the prompt script Git for Windows ships:

source /etc/git-prompt.sh 2>/dev/null || true

Better still: on a fresh machine, don't replace ~/.bashrc at all — Git for Windows generates a working one on first launch, with branch info and color support out of the box.

Conclusion

You now have Git fully working on Windows 11: the CLI available in every terminal, Git Bash for Unix-style workflows, your identity configured, credentials remembered, and (optionally) SSH authentication for push-button pushes. From here the natural next steps are learning branching with git switch -c and rebasing with git rebase -i — but those are comfort topics for another day.

Need help with server setup or developer tooling? XpertBees helps teams set up dev environments, CI/CD pipelines, and cloud infrastructure — reach out through our contact page and we'll take it from there.