Install Git on Windows and a terminal you never asked for shows up in the Start menu. That’s Git Bash, a Bash shell bundled with Git for Windows, so Git and a set of Unix tools run in one window.
People mostly use it to follow Linux and macOS tutorials as written, run Bash scripts, and manage repositories with the same commands they would type on a server.
The Git for Windows technical overview describes the project as essentially a subset of MSYS2. The shell emulates POSIX behavior and does not run a Linux kernel.
What Is Git Bash?

Git for Windows includes it, so installing Git installs Git Bash too. It’s a terminal, not a graphical app. You type commands, and the version control system behind them records every change to your files.
Plenty of developers sit in the overlap between Bash and Windows. Windows is the primary operating system for 49.5% of professional developers, while 48.7% of all respondents report extensive Bash/Shell work and 23.2% report PowerShell (Stack Overflow Developer Survey 2025).
Git Bash covers that overlap, and it runs without virtualization.
How Git Bash Differs From Git and GitHub
Git is the version control system that records changes in a repository. GitHub hosts remote repositories. Git Bash is only the Windows terminal where you run Git commands, including the ones that talk to GitHub.
Git for Windows also ships Git GUI, a graphical alternative that covers most of the same commands (gitforwindows.org). Git Bash itself has no graphical interface.
For a fuller side-by-side, see this breakdown of how Git and GitHub differ.
What Does Git Bash Include?
The package bundles a Bash shell, the Git command-line programs, a set of Unix utilities and the MinTTY terminal window.
The shell is GNU Bash, with built-ins such as cd, echo and export. Utilities cover ls, cp, mv, cat and grep, plus ssh, ssh-keygen, curl and the vim editor. MinTTY is the window Git Bash opens in.
Git Credential Manager ships in the same package and stores logins for GitHub, Azure Repos and other hosts (gitforwindows.org).
As of Git for Windows v2.56.0 (28 September 2026), the package also carries Git LFS 3.8.0, cURL 8.22.0 and OpenSSL 3.5.8, according to the release notes.
Bash syntax is standard, so any cheat sheet for Bash syntax applies in Git Bash as well.
MinTTY, the Default Terminal Window
MinTTY is the terminal emulator MSYS2 uses, and the installer offers it as the default for Git Bash. It opens a standalone window, separate from Command Prompt and PowerShell.
The installer also offers the Windows default console window as an alternative. Some native console programs misbehave inside MinTTY, and the Git for Windows FAQ lists the problem under “Some native console programs don’t work when run from Git Bash”.
So it comes down to a trade. MinTTY handles Unix-style terminal behavior better, and the Windows console handles native Windows programs better.
How Does Git Bash Run Unix Commands on Windows?

The MSYS2 runtime does the work. It’s an emulation layer that maps POSIX behavior onto Windows, and no Linux kernel sits underneath.
Git for Windows is essentially a subset of MSYS2 with a defined set of installed packages, according to its technical overview. The files that emulate the Unix environment, such as grep, find and cat, come from MSYS and MinGW packages.
That design keeps Git Bash light. It also caps what Git Bash can do, because every Unix call still passes through Windows.
One recent platform change matters here. The v2.56.0 release (28 September 2026) dropped Windows 8.1 support, following MSYS2. Internal paths moved with it. /mingw64/bin/git.exe no longer exists, /ucrt64/bin/git.exe takes its role, and /cmd/git.exe is the path guaranteed to stay stable (Git for Windows release notes).
Scripts that hardcode the old /mingw64 path break after the update.
How Windows Paths Map to POSIX Paths
Git Bash writes each drive letter as a top-level folder, so C:\Users\name becomes /c/Users/name. Arguments passed to native Windows programs get converted automatically when they look like Unix paths.
| Form | Input | Result |
|---|---|---|
| Drive path | cygpath -u C:\\foo | /c/foo |
| Path argument | –dir=/foo | –dir=C:/msys64/foo |
| Path list | –dir=/foo:/bla | –dir=C:\msys64\foo;C:\msys64\bla |
Those values come from the MSYS2 documentation, which uses the default MSYS2 root of C:/msys64. In Git Bash the root is the Git install folder, so the prefix differs.
The converter also hits arguments that only look like paths, and it finds path lists where none exist. Setting MSYS2\_ARG\_CONV\_EXCL to an argument prefix (or to \*) skips the conversion.
MSYS2_ARG_CONV_EXCL='--dir=' python3 -c "import sys; print(sys.argv)" --dir=/foo
['-c', '--dir=/foo']The reverse direction needs no conversion. A command like ls C:/ works because the runtime forwards the path to the Windows API as is.
How to Install Git Bash on Windows

There’s no separate installer. Run the Git for Windows installer and Git Bash lands alongside Git.
As of v2.56.0 (28 September 2026), the release offers a 64-bit installer, an ARM64 installer, and PortableGit archives for machines where a full install is not allowed (Git for Windows release notes).
- Download the installer from git-scm.com or gitforwindows.org, choosing the 64-bit or ARM64 build that matches your processor.
- Run the .exe and approve the administrator prompt.
- Keep the default components, which include Git Bash, Windows Explorer integration and Git GUI.
- Pick a default editor. Vim is preselected, and VS Code works if it is already installed.
- Set the PATH option to “Git from the command line and also from 3rd-party software”.
- Accept the default line ending conversion, then confirm MinTTY as the terminal emulator.
- Finish the wizard, open Git Bash from the Start menu, and run git –version to confirm.
Setup on macOS and Linux follows a different route, covered in this guide to installing Git on other platforms.
Which Installer Options Matter
| Option | Choice | Effect |
|---|---|---|
| Default editor | Vim, or VS Code if you use it | Opens for commit messages |
| PATH environment | Git from the command line and also from 3rd-party software | Runs git from Command Prompt and PowerShell, without adding Unix tools |
| Line endings | Checkout Windows-style, commit Unix-style | Keeps LF in the repository and CRLF on disk |
| Credential helper | Git Credential Manager | Stores logins for GitHub and Azure Repos |
There’s one known bug worth a look. The v2.55.0(5) installer disabled the “Use external OpenSSH” option for some users and overwrote their saved choice with the bundled OpenSSH. Anyone who relies on an external OpenSSH and updated to that build should rerun the latest installer with “Only show new options” unchecked (Git for Windows release notes, v2.56.0).
The v2.56.0 installer fixes the cause, since it is now a true 64-bit build.
How to Open Git Bash
You can open it from the Start menu, from the right-click menu in File Explorer, from a Windows Terminal profile, or from the VS Code integrated terminal.
Start Menu and Right-Click Menu
The Start menu entry opens a fresh MinTTY window. Right-clicking a folder in File Explorer and choosing Open Git Bash Here opens the same window inside that folder (Git for Windows shell integration).
The right-click route is the quickest way to land inside a repository. If the menu entry is missing, rerun the installer and reselect the Windows Explorer integration component.
Windows Terminal
Windows Terminal runs Git Bash as a profile in its dropdown, next to PowerShell and Command Prompt. If the dropdown has no Git Bash entry, add a profile to settings.json.
In that profile, name is the label shown in the dropdown and commandline is the executable to run. startingDirectory sets the folder the session opens in, and it falls back to %USERPROFILE% when unset.
{
"name": "Git Bash",
"commandline": "C:\\Program Files\\Git\\bin\\bash.exe --login -i",
"startingDirectory": "%USERPROFILE%"
}Backslashes in JSON paths need doubling, per the Windows Terminal documentation. Bash may ignore the profile name as its tab title, so set tabTitle when the label matters.
This profile starts bash.exe directly, so the session runs in Windows Terminal instead of a MinTTY window.
VS Code Integrated Terminal
VS Code detects a Git Bash install on its own, and the Terminal: Select Default Profile command makes it the default.
{
"terminal.integrated.profiles.windows": {
"Git Bash": { "source": "Git Bash" }
},
"terminal.integrated.defaultProfile.windows": "Git Bash"
}The steps for opening the integrated terminal in VS Code are the same for any shell.
There’s a catch, though. When VS Code starts bash.exe (the shell) instead of git-bash.exe (the terminal), command history does not carry across sessions.
The VS Code terminal profiles documentation (updated 30 September 2026) fixes it with one line in ~/.bashrc or ~/.bash\_profile:
export PROMPT_COMMAND='history -a'How to Configure Git Bash and Run Your First Commands

Sort out your identity and your line ending policy before the first commit, and set up some way to authenticate with your remote.
Set Your Name and Email
git config set --global user.name "Your Name"
git config set --global user.email "you@example.com"The git-config manual for 2.56.0 (released 28 September 2026) lists the bare git config <name> <value> form as a deprecated mode and points to git config set. Most tutorials still show the older form.
Without –global, git config writes to the repository’s .git/config, so the identity covers that one repository. With –global it writes to ~/.gitconfig and applies to every repository under your Windows user.
Line Endings and autocrlf
The installer’s line ending screen writes a single value, core.autocrlf, and you can change it at any time.
| Installer option | core.autocrlf |
|---|---|
| Checkout Windows-style, commit Unix-style | true |
| Checkout as-is, commit Unix-style | input |
| Checkout as-is, commit as-is | false |
Pick input when the repository is shared with Linux or macOS developers and your editor handles LF. Pick true when Windows tools on your machine need CRLF in the working tree.
Generate an SSH Key and Load It
ssh-keygen -t ed25519 -C "you@example.com"
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519Git Bash proposes /c/Users/YOU/.ssh/id\_ed25519 as the save location, according to GitHub Docs. Systems without Ed25519 support use ssh-keygen -t rsa -b 4096 instead, because GitHub dropped DSA keys on March 15, 2022.
Upload the public key afterwards, as shown in this guide to adding an SSH key to GitHub.
The agent can also clash with Windows. GitHub Docs describe a case where a passphrase saved in the Windows ssh-agent through PowerShell still gets requested on every push.
The cause is that Git for Windows calls its bundled ssh.exe, which cannot reach the Windows agent service. Pointing Git at the system binary fixes it, and so does reinstalling with the external OpenSSH option from the installer section.
git config set --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"Everyday Commands That Work Unchanged

The Git commands you already know run as is.
- git init
- git clone
- git status
- git add
- git commit -m “message”
- git push and git pull
The bundled utilities run as they do on Linux: ls, cd, pwd, cat and grep. A longer reference lives in this list of Git commands.
Git Bash vs Command Prompt, PowerShell, WSL and Cygwin

Git Bash fits Git and light shell work. PowerShell is the better call for automating Windows, and WSL 2 for code that has to run on Linux.
| Option | What it is | Best for |
|---|---|---|
| Git Bash | Bash on the MSYS2 runtime | Git commands, Bash scripts on Windows files |
| Command Prompt | Native Windows command interpreter | Legacy batch files |
| PowerShell | Object-based shell and scripting language on .NET | Windows administration, automation |
| WSL 2 | Linux distribution on a real kernel | Linux-targeted development |
| Cygwin | POSIX environment with its own runtime | Porting Unix software unchanged |
MSYS2 describes its runtime, msys-2.0.dll, as the Cygwin library modified to work with native Windows programs. Git Bash therefore sits closer to Cygwin than to WSL, which Microsoft documents as a real Linux kernel.
The goals differ, though. Cygwin aims to build and run Unix software with few changes and ships its own package manager, setup.exe. MSYS2 aims at building native Windows software and uses pacman.
PowerShell works differently from any Bash-based option. Microsoft Learn (updated 12 August 2026) notes that it accepts and returns .NET objects instead of text, so scripts skip the text parsing that Bash pipes require.
WSL 2 runs a Linux kernel inside a managed virtual machine and supports full system call compatibility. It requires Windows 11 or Windows 10 version 1903 (build 18362) or later.
On the plus side, Git Bash installs with Git, so there’s no separate setup and no virtual machine to manage. You also get Bash syntax on Windows files directly.
The downsides are real:
- No Linux kernel, so Linux-only tools fail
- No package manager in the standard install
- Path and symlink behavior follows Windows rules
- Native Windows programs need extra care inside MinTTY
Which One to Pick
- For Git operations and quick scripts, Git Bash.
- For Windows administration, PowerShell.
- For code that ships to Linux servers, WSL 2, with project files kept on the Linux file system.
- On a locked-down machine without virtualization, Git Bash, or PortableGit when installs are blocked.
- For porting Unix software unchanged, Cygwin.
Microsoft’s WSL documentation names one case for WSL 1 over WSL 2: project files that must stay on the Windows file system, where cross-OS file access runs faster.
If the work is mostly Git commands on Windows files, WSL 2 adds a second file system and gives nothing back.
Where Git Bash Falls Short
Symbolic links, long paths, native console programs and Linux-only tooling are the weak spots, and the first three have documented workarounds.
| Limit | Cause | Workaround |
|---|---|---|
| Symbolic links | ln -s creates copies | core.symlinks=true, or mklink |
| Long paths | 260-character Windows limit | core.longpaths set to true |
| Native console programs | MinTTY is not seen as a console | winpty, or bash without MinTTY |
| Linux-only tools | No Linux kernel | Move the work to WSL 2 |
Real Windows symlinks need the Create symbolic links privilege, which Administrators hold behind UAC. Since Windows 10 version 1703, Developer Mode lifts the UAC requirement, and links work only on NTFS and ReFS, not FAT or exFAT (Git for Windows documentation).
Directory junctions, created with mklink /j, work for non-administrators by default and serve as the usual substitute.
Native console programs are the messier case. MinTTY does not present itself as a console to applications built outside MSYS2 and Cygwin. Non-ASCII output can corrupt because MSYS2 uses UTF-8 while Windows falls back to legacy DOS codepages, and interactive or full-screen applications fail outright.
The Git for Windows FAQ lists 3 workarounds: run the program through winpty, start bash without MinTTY, or use ConEmu.
Windows caps file paths at 260 characters by default, and Git for Windows errors on anything longer. Setting core.longpaths to true lets certain Git operations handle those files.
Large repositories and heavy file I/O draw the most complaints, yet Git for Windows publishes no benchmark of its own, so the evidence stays anecdotal. Measure your own repository before switching shells.
Package management is the other gap. According to the FAQ, pacman is available only to advanced users working with the Git for Windows SDK, which targets contributors, so a standard Git Bash install cannot add Linux software.
- No MSI exists, only the exe installer and a portable package, so Group Policy rollouts need SCCM or a script
- Builds older than v2.55.0(4) miss security fixes, and
git update-git-for-windowschecks for updates
Two sources disagree on one point. The Git for Windows FAQ still lists Windows 8.1 as the oldest supported x64 release, but the v2.56.0 release notes, dated 28 September 2026, say 8.1 support was dropped following MSYS2.
Treat the release notes as current and skip Windows 8.1 for new installs.
One row in the table rarely justifies a move. Two or more rows describing your project usually do.
Git Bash FAQ
Is Git Bash free?
Yes. Git is covered by the GNU General Public License version 2, and the Git for Windows package bundles components such as Bash, curl and MSYS2 under open source licenses.
Can Git Bash be used on Mac or Linux?

No, Git Bash is part of Git for Windows and exists for Windows only. macOS and Linux ship their own terminals, where installing Git gives the same commands with no emulation layer.
How do you update Git Bash?
Run git update-git-for-windows, which checks for a newer release and offers to install it.
Downloading and running the new installer works too. Customizations kept in the standard configuration folders carry over (Git for Windows FAQ).
How do you uninstall Git Bash?
Remove Git for Windows under Apps in Windows Settings. Git Bash is part of that package, so it cannot be removed on its own.
Your repositories are ordinary folders and stay untouched.
Is there a portable version of Git Bash?
Yes. PortableGit ships as a self-extracting .7z.exe for 64-bit and ARM64 Windows.
Extract it to any folder and start git-bash.exe from there, which suits machines where installers are blocked.
How do you create an alias in Git Bash?
Add a line such as alias gs='git status' to ~/.bashrc, then run source ~/.bashrc to load it.
For a Git-level shortcut, use git config set –global alias.st status instead.
Why does Command Prompt say git is not recognized after installing Git Bash?

The installer’s PATH option was set to use Git from Git Bash only. Rerun the installer, choose Git from the command line and also from 3rd-party software, and open a new terminal window.
How do you copy and paste in Git Bash?
Press Ctrl+Insert to copy and Shift+Insert to paste inside the MinTTY window.
MinTTY also handles multi-line pastes normally, which the default Windows console host does not (Git for Windows FAQ).
When to Move Beyond Git Bash

Move work out of Git Bash when scripts or tools depend on Linux system calls, not when Git commands slow down. Git for Windows patches Git itself, so the limit shows up in everything around it.
Change the setup in this order:
- Keep Git Bash for Git commands
- Move Linux-bound scripts to WSL 2
- Leave Windows administration to PowerShell
That sequence follows where failures appear first. Scripts break before Git does, and Windows administration never depended on Bash.
The cost is a second environment. WSL 2 distributions keep their own home directory, so each shell holds its own ~/.gitconfig and SSH keys.
This position was verified against Git for Windows v2.56.0 on 2 October 2026. A release that moves Git for Windows onto a new MSYS2 base would change it.
For the commands beyond setup, continue with learning how to use Git day to day.
- Google Play Account Suspended: What to Do - October 5, 2026
- How to Plan a Successful Data Migration Without Disrupting Business Operations - October 5, 2026
- How to Turn On Dark Mode in Notepad++ (Built-In, No Plugin) - October 3, 2026



