Bash Terminal on Windows: Git Bash, WSL, and Which One to Use

Git Bash is a small Windows program emulating a Unix shell. WSL is a real Linux kernel. They both give you a dollar prompt, and past that they have almost nothing in common.

Both are called “bash on Windows” and the confusion is entirely reasonable. It stops being academic the first time a script works in one and fails in the other, or a path like /c/Users/you works here and /mnt/c/Users/you works there.

Here is what each one is, and a straight recommendation.

Table of contents

• What Git Bash actually is
• What WSL actually is
• The filesystem rule that decides your experience
• Which one to pick
• Windows Terminal, and knowing where you are
• Matching the deployment target
• How this fits the rest of the stack
• FAQ

What Git Bash actually is

Git Bash ships with Git for Windows. It bundles MSYS2 — a compatibility layer providing bash plus a small set of GNU utilities compiled as native Windows executables.

It is genuinely lightweight. It starts instantly, uses no meaningful memory when idle, and runs Windows programs directly because everything in it is a Windows program. You already have it if you installed Git.

The limits follow from that. You get roughly a hundred commands — ls, grep, sed, awk, curl, ssh, find. Anything beyond that is not installable, because there is no package manager. No apt, no docker, no systemd, no compiling native Linux binaries.

Paths use a translated form: C:\Users\you becomes /c/Users/you. Git Bash converts arguments that look like paths when calling Windows executables, which is helpful right up until it mangles something that was not a path — a common source of confusion when passing arguments like /tmp/x to a native tool.

What WSL actually is

WSL 2 runs a real Linux kernel in a lightweight virtual machine with tight Windows integration. Not emulation — an actual Ubuntu or Debian userspace on an actual Linux kernel.

That means the full distribution: apt install anything, Docker, systemd, native Linux builds, everything a Linux server has. Your development environment can genuinely match production.

wsl --install                  # installs WSL with Ubuntu
wsl --list --online            # other distributions
wsl --install -d Debian

The costs are real but modest: a virtual machine with its own memory allocation, a second filesystem, and a startup delay on first launch. On any current development machine this is not a meaningful burden.

Windows drives are mounted under /mnt/c, and WSL’s own filesystem is reachable from Windows via \\wsl$. That interoperability is where the one genuinely important performance rule lives.

The filesystem rule that decides your experience

Keep your projects inside the WSL filesystem — /home/you/projects — not on /mnt/c.

Cross-filesystem access in WSL 2 goes over a network protocol, and it is slow in a way that dominates everything else. A git status on a large repository can take several seconds on /mnt/c and be instant in /home. npm install shows the difference even more dramatically.

Almost every “WSL 2 is slow” complaint is this and nothing else. It is a one-line fix — move the project — and it changes the experience completely.

Edit those files from Windows with VS Code’s WSL extension, which runs its server inside WSL and gives you native performance with a Windows editor. Windows tools can reach the files through \\wsl$\Ubuntu\home\you when needed, but that path has the same cross-boundary cost, so use it for occasional access rather than as your working directory.

Which one to pick

Use WSL if you deploy to Linux, use Docker, need a package manager, build anything with native dependencies, or want your environment to resemble production. That is most professional development on Windows, and WSL is the default recommendation.

Use Git Bash if you want a Unix-ish shell for Git operations and simple scripts, you are working primarily with Windows tooling, or you are on a locked-down machine where enabling virtualisation is not permitted. It is a legitimate choice for a narrow job.

Use PowerShell if you are automating Windows itself. It is genuinely good at that, and running Windows administration through a bash emulation layer is working against the grain.

Plenty of people have all three, and that is fine. What causes trouble is not knowing which one a given terminal window is, which the next section addresses.

Windows Terminal, and knowing where you are

Windows Terminal hosts all of these as tabs and is worth installing regardless of which shell you use. Give each profile a distinct colour scheme — it takes two minutes and eliminates a whole category of confusion.

Some settings worth knowing about:

• wsl.exe from PowerShell drops you into your default distribution. wsl -d Debian picks another.
• explorer.exe . from inside WSL opens the current directory in Windows Explorer.
• code . from inside WSL opens VS Code connected through the WSL extension, not a Windows-side editor pointed at a network path.
• A .wslconfig file in your Windows user directory caps WSL’s memory and CPU, which matters because it will otherwise claim a large share by default.

And a genuine cross-platform trap: line endings. Windows tools write CRLF, Linux expects LF, and a shell script with CRLF endings fails with a baffling bad interpreter: /bin/bash^M. Set git config --global core.autocrlf input on the WSL side and add a .gitattributes to the repository so it is settled for everyone rather than per machine.

Matching the deployment target

The strongest argument for WSL is that it removes the class of bug where something works locally and fails in deployment because the environments genuinely differ — case-sensitive filenames, path separators, line endings, or a native dependency that builds differently.

Running Docker in WSL takes that further: build the same image locally that runs in production, so a build failure happens on your machine rather than in a pipeline.

On RunxBuild, services build from a repository into a container and run on Linux, so a WSL environment matching that removes most of the gap. The build log shows the build as it runs, which is the other half — when something does differ, you can see exactly where it diverged rather than guessing.

How this fits the rest of the stack

Git Bash is a compatibility shell that starts instantly and cannot install anything; WSL is a real Linux you can treat as a server. For anything deploying to Linux, use WSL, keep your projects in /home rather than /mnt/c, and set your line endings once. Matching your local environment to the deployment target removes a whole class of surprise — the RunxBuild hosting calculator covers what running that target actually costs.

Useful related references:

• Bash Append to File: >>, tee -a, and Heredoc
• How to Run .sh File in Linux: bash, chmod, and shebang
• Bash For Loop 1 to 10: Four Ways, and When Each One Breaks
• Services on RunxBuild

FAQ

What is the difference between Git Bash and WSL?

Git Bash is a Unix-like shell with about a hundred GNU utilities compiled as native Windows programs, with no package manager. WSL 2 runs a real Linux kernel in a lightweight VM with a full distribution, so you can apt install, run Docker and build native Linux binaries.

Which is better, Git Bash or WSL?

WSL for anything that deploys to Linux, uses Docker, or needs packages beyond the basics — which is most professional development. Git Bash is reasonable for Git operations and simple scripts, or on a machine where virtualisation cannot be enabled.

Why is WSL 2 so slow?

Almost always because the project lives on /mnt/c. Cross-filesystem access from WSL to Windows goes over a network protocol and is dramatically slower. Move projects into the WSL filesystem under /home and the difference is immediate.

Can I run Docker in Git Bash?

Not natively. Git Bash has no container runtime and no package manager to install one. It can invoke Docker Desktop’s Windows client, but the containers run in Docker Desktop’s own backend rather than in Git Bash.

Why does my shell script fail with bad interpreter ^M?

The file has Windows CRLF line endings and Linux expects LF, so the shebang line reads as /bin/bash\r. Set git config --global core.autocrlf input and add a .gitattributes file to the repository so the setting applies for everyone.