Git Setup for Windows: The Installer Options That Actually Matter

Git for Windows installs Git plus Git Bash, a terminal that behaves like a Unix shell, and Git Credential Manager, which handles HTTPS authentication to GitHub without typing a password on every push. The installer presents about a dozen screens; four settings on them actually change day-to-day behaviour: keeping Git on PATH so it works from any terminal, letting Git convert line endings (or not, for a team that has agreed on LF everywhere), the default branch name for new repositories, and Credential Manager for HTTPS logins. Everything else on the install screens is safe to leave on the default.

The Git for Windows installer asks more questions than the installers most developers are used to, and the temptation is to alt-tab through them without reading. Two of those screens, line endings and the default editor, have caused actual confusion later: a file that shows as entirely changed in a diff because of a line-ending flip, or a merge that opens Vim with no idea how to exit it. Getting them right once avoids both.

Download and install
The editor prompt
PATH: which command-line tools can see Git
Line endings: the setting that causes silent diffs
git config after install
Git Bash vs PowerShell
HTTPS with Credential Manager vs SSH
Verify with a first clone and push, and a note on WSL
How this fits the rest of the stack
FAQ

Download and install

Get the installer from git-scm.com, run it, and click through with the defaults except for the four screens below. It installs Git, Git Bash, and Git GUI in one pass, and it does not require a restart afterward for the command to become available in a new terminal window.

Windows 11 also ships a git command via winget install --id Git.Git, which is the same installer non-interactively and a faster path if a GUI wizard is not needed. Both routes end at the same version of Git; winget is worth using when setting up a new machine from a script, since the interactive installer has nothing to offer in that context.

A common early mistake is running the installer a second time later to “update” Git and ending up with two versions on PATH, an old one from a portable zip or an IDE’s bundled copy, and the new one from the installer. Running where git in Git Bash or Get-Command git in PowerShell lists every git.exe PowerShell can see, in the order it will pick one, which settles the question of which install is actually running.

The editor prompt

The installer asks which editor Git should open for commit messages and merge conflicts. The default is Vim, which is a reasonable choice for someone who already knows it and a genuine trap for someone who does not, because a git commit with no -m flag opens Vim and a surprising number of new Windows users have closed the terminal entirely rather than figure out how to exit it.

Picking VS Code (code --wait) or Notepad from the dropdown avoids that specific bad afternoon. It can be changed later with git config --global core.editor "code --wait", and the --wait flag matters: without it, Git considers the commit message written the instant the editor process launches, before anything has actually been typed.

The symptom of getting this wrong is unmistakable: a git commit command that appears to hang, with a screen full of ~ characters and no visible way to type. The fix in the moment is Esc then :wq followed by Enter to save and quit, or :cq to abort the commit entirely; the fix for next time is changing the configured editor so this never comes up again.

PATH: which command-line tools can see Git

The recommended option, “Git from the command line and also from 3rd-party software”, adds Git to the system PATH, which is what lets VS Code’s integrated terminal, PowerShell, and CMD all find git without extra configuration. The minimal option, Git Bash only, is not worth the friction of Git being invisible everywhere else.

What breaks with the minimal option: opening VS Code’s built-in terminal, or any script that shells out to git, and getting 'git' is not recognized as an internal or external command, even though Git Bash itself works fine in its own window. That message means Git is installed but not on the system PATH, which the recommended installer option exists specifically to prevent.

The third installer option, “Use Git and optional Unix tools from the Command Prompt”, goes further and puts Unix utilities like find and sort on PATH too, which shadows Windows’s own commands of the same name. That is rarely worth the risk for a general setup and is the one PATH option actually worth avoiding by default.

Line endings: the setting that causes silent diffs

Windows uses CRLF line endings, Unix-style systems use LF, and Git can convert between them on checkout and commit. The installer offers three choices, and the one that matches how the rest of a project’s contributors work is the correct one, not necessarily the default.

Checkout Windows-style, commit Unix-style (the default) converts LF to CRLF locally and back on commit. Safe for a solo Windows project with no .gitattributes.
Checkout as-is, commit Unix-style leaves files alone on checkout. Fine on a team that has already normalized endings with .gitattributes.
Checkout as-is, commit as-is does no conversion at all, which is correct only if every contributor’s editor is already configured to use LF.

A repository with a .gitattributes file setting * text=auto or explicit endings per file type overrides all three installer choices for that repo, which is the more reliable fix for a team, rather than relying on everyone’s installer setting matching.

git config after install

git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"

init.defaultBranch sets the name new local repositories start with; the installer’s default branch prompt sets the same value. main matches what GitHub creates by default, avoiding a rename step on every new repo, and mismatching them, master locally against main on GitHub, is what causes a first push to silently create a second, unrelated branch instead of updating the one already there.

Skipping user.name and user.email does not stop commits from working. It stops them from being attributed correctly. Git falls back to the machine’s account name and a guessed hostname-based email, which is fine for a throwaway local test and wrong for anything that will ever reach a shared repository, since every commit made before the config is set carries the wrong identity permanently.

Running git config --list --show-origin after these four lines confirms what was actually set and which file it came from, useful when a value seems to have not taken effect because a more specific config, a repository-level .git/config, is overriding the global one silently.

Git Bash vs PowerShell

Git Bash gives Unix commands (ls, grep, ssh-keygen) on Windows and is what most Git tutorials assume, so following along literally requires it. PowerShell is the native Windows shell, better integrated with the rest of the OS, and perfectly capable of running Git commands, which are the same binary either way.

A reasonable default: PowerShell for general work, Git Bash when following a tutorial that assumes bash syntax or when a Unix tool is needed that PowerShell does not have natively.

The practical difference shows up in scripting, not in plain Git commands. A shell script with a .sh extension, common in project READMEs, runs directly in Git Bash and needs WSL or a rewrite as a .ps1 to run natively in PowerShell. A git status or git commit behaves identically in either, since Git itself does not care which shell invoked it.

HTTPS with Credential Manager vs SSH

HTTPS with Git Credential Manager, installed alongside Git for Windows, opens a browser sign-in the first time a repository is cloned or pushed, then stores the token so future pushes do not prompt again. It is the lower-friction default and works through most corporate proxies without extra configuration.

SSH is the other option: generate a key pair with ssh-keygen -t ed25519, add the public key to GitHub’s SSH settings, and clone with the [email protected]: URL form instead of https://. SSH avoids browser-based re-authentication and is the more common choice for someone managing several accounts on the same machine.

A push that fails with Permission denied (publickey) after switching to an SSH remote almost always means the key was never added to the SSH agent for the current session; ssh-add ~/.ssh/id_ed25519 fixes that. A push that instead prompts for a username and password on an HTTPS remote, rather than opening a browser, usually means Credential Manager was not selected during install and Git is falling back to plain password authentication, which GitHub no longer accepts.

Verify with a first clone and push, and a note on WSL

git clone https://github.com/<you>/<repo>.git
cd <repo>
echo "test" >> README.md
git add README.md
git commit -m "Verify setup"
git push

A prompt for sign-in on the push that completes without a password typed manually confirms Credential Manager is wired up correctly. If the push instead fails immediately with an authentication error, the fastest check is git config --global credential.helper, which should print manager or manager-core; an empty result means the installer step was skipped and re-running the installer with that option selected fixes it without touching anything else.

WSL runs a separate Linux Git install with its own config and credentials; treat it as a distinct environment rather than assuming Windows Git settings carry over, and avoid editing the same repository from both a Windows path and its WSL mount, since line-ending behaviour differs between the two and can turn every file into a full diff the next time either side commits.

The general rule for deciding whether to reach for WSL at all: if the project’s own tooling, a Makefile, a shell-only build script, assumes a Linux environment, WSL removes a category of compatibility problems Git for Windows alone cannot. For plain Git usage on a Windows-native project, native Git for Windows is simpler and has one fewer environment to keep in sync.

How this fits the rest of the stack

None of this changes once the repository has somewhere to deploy to: a push to main on GitHub is what triggers a build on RunxBuild, with the same commit that just verified the local setup becoming a live deploy with logs. The RunxBuild hosting calculator prices the service and database plans once there is more than a README to push.

Useful related references:

FAQ

How do I install Git on Windows 11?

Download the installer from git-scm.com/download/win, or run winget install —id Git.Git from PowerShell for the same install non-interactively. Both install Git, Git Bash, and Git Credential Manager together.

What Git installer options actually matter on Windows?

Four: keeping Git on PATH so other terminals can find it, the line-ending conversion setting, the default branch name for new repositories, and Git Credential Manager for HTTPS authentication. The rest of the installer screens are safe on their defaults.

Should I use Git Bash or PowerShell?

PowerShell for general Windows work, since it is the native shell and runs the same Git binary. Git Bash when following a tutorial written for Unix commands, or when a specific Unix tool such as ssh-keygen or grep is needed in the same session as Git commands.

How do I connect Git on Windows to GitHub?

Either HTTPS with Git Credential Manager, which opens a browser sign-in on the first clone or push and then remembers it, or SSH with a key pair generated by ssh-keygen and added to GitHub’s SSH settings. HTTPS is the lower-friction default for most single-account setups.

Do I need WSL to use Git on Windows?

No. Native Git for Windows with Git Bash covers the vast majority of day-to-day use. WSL is worth adding when a project specifically needs a Linux environment for its build or tooling, and its Git install and credentials should be treated as separate from the Windows one.