Bash for Git: Install, Open, and Use Git Bash (2026)

Search for bash for git and Google hands back two different answers stitched together as one: a terminal program you install on Windows, and a set of typed commands that actually move code around. Most guides pick one and half-cover the other. This one covers both, in the order you'll need them — install and open Git Bash, the terminal that ships with Git for Windows, then the bash and git commands that do real work once it's open. If you're already on macOS or Linux, skip to whether Git Bash even applies to you — short version, it doesn't, because you already have both tools natively. Once a terminal is open, the first git command most people reach for is a clone of a specific branch, and that's roughly where the command reference below picks up.

Quick Answer: Bash for Git in One Line

Install Git for Windows — it bundles Git Bash automatically, there's no separate download. Then open it by searching "Git Bash" in the Start menu, or by right-clicking inside any folder in File Explorer and choosing Git Bash Here. Whichever way you open it, you land in the same MINGW64 prompt, running both Unix-style bash commands and git commands side by side. That's bash for git in one sentence: a Unix-like shell wrapped around your normal Git workflow, and this guide covers how to use Git Bash end to end — installing it, opening it reliably even on a fresh Windows 11 box, and the actual commands people type in it every day.

# The six commands most Git Bash sessions open with
pwd                       # print working directory
ls -la                    # list files, including hidden ones
cd projects/repo          # change directory
git status                # what changed since the last commit
git add .                 # stage everything that changed
git commit -m "message"   # commit what's staged

The git commands that make or break a Git Bash session are the same eight or nine verbs covered in the essential git commands section below — clone, status, add, commit, push, pull, branch, log, diff. None of them are specific to Git Bash; they're ordinary git subcommands that happen to run inside a bash shell instead of PowerShell or CMD. The git commit -m line above is the one that writes history, and its git commit flags and syntax behave identically in every shell.

What Is Git Bash?

Git Bash is the terminal application that ships inside the Git for Windows installer. It pairs the MinTTY terminal emulator with a Unix-style shell (GNU Bash) running on top of an MSYS2/MinGW-w64 compatibility layer — a translation layer that lets Unix system calls and path conventions work on a Windows kernel. That combination is the entire git bash cli experience: a real bash prompt, a curated set of GNU command-line tools, and git itself, all launched from one icon, with no separate Linux installation required.

You can tell you're in it by the prompt itself. Every Git Bash window reports its environment name directly in the prompt — MINGW64 for the standard 64-bit build — which is also the tag that shows up if you ever see it referenced in a stack trace or a build log:

pavel@DESKTOP-7F2QK1L MINGW64 ~/projects/repo (main)
$

Functionally, this is what most people mean when they search for bash for git even when they never type "Git Bash" as a product name — they mean "the terminal Windows uses to run Unix-style commands against a Git repository." Nothing about it is a Git feature; it's a terminal, and git happens to be one of the programs installed inside it.

What Git Bash Includes

Four pieces make up the package, and knowing where each boundary sits explains most of the surprises later in this guide:

• MinTTY — the terminal emulator window itself, distinct from the shell running inside it. MinTTY renders text, handles copy/paste and font settings, and is why Git Bash looks and resizes differently than the classic Windows console.
• Bash — the actual shell that interprets commands, handles piping, redirection, and scripting (if, for, functions, .bashrc).
• A curated set of GNU coreutils — ls, grep, sed, awk, find, curl, tar, ssh, and similar tools compiled for Windows via MSYS2/MinGW. It's a fixed list chosen for Git's needs, not an extensible package manager — there's no apt or pacman baked in to add more.
• Git — the actual version control tool, plus companion utilities like gitk (a commit graph viewer) and Git GUI, installed alongside the shell.

What it deliberately doesn't include is a package manager or a full Linux distribution. If a script needs a GNU tool that isn't on that curated list — jq, a newer rsync, a compiler — Git Bash won't have it, and installing it means either finding a standalone Windows build or switching to WSL, covered in the comparison section below.

Installing Git Bash on Windows

Git Bash isn't distributed on its own — you get it by installing Git for Windows, currently at version 2.55.0(3), released July 14, 2026. Download the installer from git-scm.com/download/win, run it, and accept the defaults unless you have a specific reason not to — the default component selection already includes Git Bash, Git GUI, and the Windows Explorer integration that adds "Git Bash Here" to the right-click menu. The Git for Windows project site is the upstream source for that installer and publishes the release notes for each version, if you want to confirm what a specific build changed before upgrading.

Two install-time prompts are worth deciding deliberately instead of clicking through: the default editor for commit messages (Vim if you don't change it — pick Notepad or VS Code if Vim isn't familiar), and the line-ending conversion setting, which sets core.autocrlf and is covered in full in the path translation section below. Everything else in the wizard is safe to leave at its default.

Confirm the install worked by checking the version string, which also confirms git itself is on your PATH:

$ git --version
git version 2.55.0.windows.3

$ bash --version
GNU bash, version 5.2.x-release (x86_64-pc-msys)

Once Git for Windows is installed, setting your Git username and email is usually the next step before your first commit — git refuses to attach an identity to a commit it doesn't have, and the error message for that is easy to mistake for a broken install rather than an unset config value.

How to Open Git Bash

The short version of how to open Git Bash: search for it, or right-click for it. Three methods cover essentially every situation:

• Start menu search — press the Windows key, type Git Bash, press Enter. Opens in your home directory (~).
• Right-click in File Explorer — inside any folder, right-click empty space and choose Git Bash Here. This is the fastest way to open Git Bash terminal windows already scoped to the folder you're looking at, instead of cd-ing there manually afterward.
• Desktop or Start Menu shortcut — the installer adds a "Git Bash" shortcut you can pin to the taskbar for one-click access.

All three open the identical MINGW64 environment — there's no functional difference between them, only convenience. Which folder the window starts in matters more than it looks, though: git clone creates the new repository inside whatever directory the prompt is sitting in, so where a cloned repository lands follows directly from how you opened the shell. The one that trips people up is the right-click method, because Windows 11 changed how it's surfaced by default, which the next section covers directly.

Fixing "Git Bash Here" on Windows 11

Windows 11 ships a simplified right-click context menu that only shows a handful of common actions. Git Bash Here isn't one of them — it's hidden behind Show more options at the bottom of that shortened menu, which is one extra click every single time unless you know the shortcut around it.

Hold Shift while right-clicking and Windows 11 shows the full classic context menu immediately, "Git Bash Here" included, no extra click needed. This is the fastest way to open Git Bash terminal windows on Windows 11 without touching any settings:

# In File Explorer, on any folder:
Shift + Right-click  ==>  full classic context menu appears
                      ==>  "Git Bash Here" is right there, no "Show more options" detour

If reaching for Shift every time is more friction than you want permanently, a registry tweak restores the classic full context menu everywhere, not just for Git Bash — it's a well-documented Windows 11 setting, not anything Git-specific:

reg add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /f /ve

:: Then restart Explorer for it to take effect
taskkill /f /im explorer.exe
start explorer.exe

Run it from an elevated Command Prompt or PowerShell window, not from Git Bash itself — it's a Windows registry edit, unrelated to git or bash. Reversing it is one command: reg delete "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}" /f, followed by another Explorer restart.

Adding Git Bash to Windows Terminal

Windows Terminal is a tabbed host, not a shell of its own — it runs whatever shell profile you point it at, and Git Bash is a perfectly normal profile to add alongside PowerShell and Command Prompt tabs. Profile keys and their accepted values are documented in Microsoft's Windows Terminal documentation. Open Windows Terminal's settings (Ctrl+,), click Open JSON file, and add an entry to the profiles.list array:

{
  "guid": "{2b872d97-3f2c-4ed4-9c3d-b1a1c9c7b5aa}",
  "name": "Git Bash",
  "commandline": "%PROGRAMFILES%\\Git\\bin\\bash.exe -li",
  "icon": "%PROGRAMFILES%\\Git\\mingw64\\share\\git\\git-for-windows.ico",
  "startingDirectory": "%USERPROFILE%"
}

Save the file and "Git Bash" appears in the profile dropdown next to your other shells. The -li flags matter: -l starts a login shell so .bash_profile and /etc/profile run (setting up PATH and HOME correctly), and -i marks it interactive so aliases and your prompt customization load. Skip either flag and you'll get a working shell that's missing pieces of your normal environment.

Using Git Bash Inside VS Code

VS Code's integrated terminal defaults to PowerShell on Windows, but it accepts Git Bash as a profile the same way Windows Terminal does. Open Settings (JSON) via Ctrl+Shift+P → "Preferences: Open User Settings (JSON)" and add:

{
  "terminal.integrated.profiles.windows": {
    "Git Bash": {
      "path": "C:\\Program Files\\Git\\bin\\bash.exe"
    }
  },
  "terminal.integrated.defaultProfile.windows": "Git Bash"
}

The path value has to match wherever Git for Windows actually installed bash.exe — C:\Program Files\Git\bin\bash.exe for a machine-wide install, or a path under your user profile for a per-user install. Setting defaultProfile.windows makes it the terminal that opens automatically with Ctrl+`; leave that line out and Git Bash still shows up in the terminal dropdown as a selectable option without becoming the default. With the shell docked in the editor, VS Code's own diff view is right there too — comparing two files in VS Code covers the GUI half of that workflow.

Does Git Bash Exist on macOS or Linux?

No — and not because it hasn't been ported, but because it solves a problem those systems don't have. Git Bash exists specifically to give Windows a Unix-style shell and GNU tools, since cmd.exe and PowerShell don't speak either natively. macOS and Linux are Unix-family operating systems already: bash (or zsh, macOS's default shell since Catalina in 2019) and git are just there, or one command away.

On macOS, open Terminal (Spotlight → "Terminal") and check what's already there:

$ bash --version
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin23)

$ git --version
xcode-select: note: no developer tools installed, requesting install

macOS has shipped the same GNU Bash 3.2.57 for well over a decade — Apple stopped updating bash after Free Software Foundation moved it to the GPLv3 license, which Apple's legal terms don't accept, and never replaced it with a newer build. It still works fine for everyday scripting; if you specifically want a modern bash (5.x, matching what Git Bash on Windows ships), install one via Homebrew: brew install bash. If git --version prompts for developer tools, xcode-select --install installs a working git without pulling in all of Xcode.

On Linux, git and bash are ordinary distro packages, already present on most desktop installations and one line away everywhere else — sudo apt install git on Debian/Ubuntu, sudo dnf install git on Fedora, sudo pacman -S git on Arch. There's no separate "Git Bash for Linux" to search for, because the thing Git Bash provides on Windows is native there by default. The same goes for the comparison utilities that sit next to git — diff, cmp, comm, and vimdiff are all standard there, with no emulation layer in between.

Basic Bash Commands You Need for Git

Knowing how to use Git Bash splits into two layers you build on top of each other: bash commands for moving around your filesystem, and git commands for moving code between commits. The bash layer is a short list — most sessions only ever touch these:

pwd                    # print current directory
ls                     # list files
ls -la                 # list files, including hidden dotfiles, in long format
cd path/to/folder      # change directory
cd ..                  # move up one directory
cd ~                   # jump to home directory
mkdir new-folder       # create a directory
touch file.txt         # create an empty file (or update its timestamp)
rm file.txt            # delete a file
rm -rf folder/         # delete a folder and everything in it -- no undo
cat file.txt           # print a file's contents to the terminal
cp source.txt dest.txt # copy a file
mv old-name.txt new-name.txt  # rename or move a file
clear                  # clear the terminal screen
history                # list recently run commands

rm -rf deserves its own line of caution: bash gives no confirmation prompt and no recycle bin. If you delete tracked files by mistake instead of untracked ones, discarding local changes only helps for files git already knows about — untracked files removed with rm are gone the moment the command runs.

Beyond that short list, Git Bash carries the same GNU utilities Linux users expect — grep, sed, awk, and diff among them — so the diff command in Unix behaves the same from a Windows prompt as it does from a Linux one.

Essential Git Commands in Git Bash

However the search is phrased — git bash commands, git commands for git bash, or just "what do I type" — it usually collapses to the same short list. These are the ones that show up in nearly every session:

git init                          # turn the current folder into a git repository
git clone <url>                   # copy a remote repository locally
git status                        # show what changed since the last commit
git add <file>                    # stage a file for the next commit
git add .                         # stage everything that changed
git commit -m "message"           # commit staged changes with a message
git branch                        # list local branches
git checkout -b feature/new-thing # create and switch to a new branch
git push origin main              # send commits to the remote
git pull                          # fetch and merge from the remote
git log --oneline                 # compact commit history
git diff                          # show unstaged changes, line by line

That's how to use Git Bash for the overwhelming majority of sessions: bash commands to navigate, git commands to record and sync changes. A few commands come up often enough to be worth knowing by name rather than looking up each time — listing every branch and checking which one you're on before you commit somewhere you didn't mean to, and stashing changes when you need to switch branches without committing half-finished work. If a file gets staged by mistake with git add ., unstaging it is a single command and doesn't touch the edits themselves. And git checkout -b in that list creates a new local branch — picking up one a teammate already pushed is checking out a remote branch, a related but separate command.

Git Bash vs CMD vs PowerShell vs WSL vs Windows Terminal

These five names get used interchangeably in casual conversation, but they're not the same kind of thing — some are shells, one is a full operating environment, and one isn't a shell at all. What every Git Bash workflow assumes is that git and Unix-style commands are both available in the same prompt, which is exactly the guarantee CMD and PowerShell don't give you out of the box.

The practical read: Windows Terminal isn't a git bash cli by itself — it's a host that can run one, alongside anything else you add as a profile. WSL is the heaviest option and the only one running a genuine Linux kernel underneath, which matters if you need Linux-only tooling or Docker's native performance; Git Bash is lighter, launches instantly, and covers the git-plus-Unix-commands case without installing a second operating environment. PowerShell isn't diff-less either — its Compare-Object cmdlet covers similar ground in object form, walked through in the PowerShell diff guide.

Path Translation Gotchas in Git Bash

The MSYS2 layer under Git Bash translates paths between Windows and Unix conventions automatically, and that automation is exactly where a handful of well-known gotchas come from.

Drive letters become mount points. C:\Users\pavel\projects shows up inside Git Bash as /c/Users/pavel/projects — the drive letter becomes a lowercase top-level directory. Most git and bash commands accept either form, but tools that expect a literal Windows path string can choke on the POSIX-style one, and vice versa.

$ pwd
/c/Users/pavel/projects/repo

$ cd ~
$ pwd
/c/Users/pavel

~ doesn't always mean what you assume. Git Bash resolves ~ to $HOME, and Git for Windows sets HOME to %USERPROFILE% automatically — but only if nothing already defined a HOME environment variable on the system. If another tool ever set a Windows-level HOME variable (an old Cygwin install, a portable MSYS setup, a manually added system environment variable), Git Bash inherits that value instead, and ~ silently points somewhere other than your actual user profile. Check what it resolved to with echo $HOME before assuming.

Backslashes are an escape character in bash, not just a path separator. A Windows path pasted directly into a double-quoted string — "C:\Users\name\new-project" — has \n in the middle of it, which bash reads as an escape sequence, not a literal backslash. Use forward slashes (C:/Users/name/new-project) or single quotes to paste Windows paths safely.

Some interactive programs need winpty. MinTTY doesn't provide the native Windows console handle that certain interactive CLIs expect, so running them directly inside Git Bash can hang or render garbled. Newer Git for Windows releases auto-wrap common offenders (Node's REPL, Python's REPL) with winpty automatically, but other interactive tools — some SSH prompts, some Docker exec -it sessions — may still need it prefixed manually:

winpty node
winpty docker exec -it my-container bash

Line endings: core.autocrlf. Windows editors default to CRLF line endings; most repositories store LF. Left unconfigured, every file you touch on Windows can show as fully changed in git diff even when you only edited one line:

git config --global core.autocrlf true    # Windows: LF => CRLF on checkout, CRLF => LF on commit
git config --global core.autocrlf input   # macOS/Linux: strip CRLF on commit, no conversion on checkout

If autocrlf churn already got staged before you set this, unstaging those files without losing your actual edits is one command, not a re-clone. The same CRLF-versus-LF split is why two otherwise identical files can read as entirely different when comparing two files in Windows outside git as well.

Customizing Git Bash

Git Bash reads the same startup files a normal bash install does. ~/.bashrc is where aliases, functions, and prompt customization live, sourced from whatever ~ resolves to (see the gotcha above if that's not where you expect):

# ~/.bashrc
alias gs='git status'
alias gc='git commit -m'
alias gp='git push'
alias gl='git log --oneline --graph --decorate'

# Simple colored prompt: cyan working directory, plain $ prompt
PS1='\[\033[36m\]\w\[\033[m\] $ '

Git itself supports aliases independently of bash aliases, which has the advantage of working the same way in any shell, not just Git Bash:

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.st status
git config --global alias.last "log -1 HEAD"

MinTTY's own appearance — font, color scheme, transparency, window size — is controlled separately through ~/.minttyrc or the terminal's right-click Options menu, not through .bashrc. Font and color changes there apply immediately to new windows without restarting anything. Small as these tweaks are, they're what turn a stock git bash cli into one that's actually pleasant to live in for a full workday.

Comparing File Versions Pulled via Git Bash

git diff is fine for a quick scan in the terminal, but a long or heavily reformatted change is genuinely hard to read as scrolling plus/minus lines. A common Git Bash move for anything more involved is dumping a specific version of a file to disk, then reading the difference in an actual side-by-side view:

# Dump last commit's version of a file to disk without touching your working copy
git show HEAD~1:src/app.js > old-app.js

# src/app.js (working copy) and old-app.js (previous commit) are now
# two plain files, ready to open in a real diff viewer

That's a workflow Diff Checker is actually built for. It's a Chrome extension running on the Monaco editor — the same engine behind VS Code — with two editable panes and a live diff that updates as you type or paste, no "Compare" button required. Its Open Files picker takes up to two files directly (the two you just produced with git show above), and from there you get Split or Unified view, "Show Diff Only" to collapse unchanged context, Smart Diff or whitespace-insensitive comparison modes, and syntax highlighting across 17 languages, shell and bash included.

Worth being precise about what this is not: Diff Checker doesn't integrate with git in any way, doesn't parse patch or unified-diff output, and won't do a three-way merge or resolve conflicts — it's a general-purpose file comparison tool, not a git client. It complements diffing two files and reviewing what a fetch actually brought in from the terminal — the terminal decides what changed, Diff Checker makes reading that change less painful than eyeballing a wall of +/- lines. Everything runs locally in the browser; nothing you paste or open is uploaded anywhere.

Frequently Asked Questions