Introduction

Git Bash normally starts in your home directory, which is fine for casual use but inefficient if you work in the same project tree every day. On Windows, there are two practical ways to change that starting location: modify the shortcut that launches Git Bash, or add a cd command in your shell startup file. The better option depends on whether you want one specific shortcut to start elsewhere or you want every interactive shell to jump to a chosen directory.

Method 1: Change the Shortcut Start Directory

If you launch Git Bash from the Start menu, desktop shortcut, or taskbar pin, the cleanest solution is to edit the shortcut properties.

1. find the Git Bash shortcut
2. right-click and open Properties
3. open the Shortcut tab
4. change the Start in field
5. save the change and reopen Git Bash

For example, set Start in to:

C:\Users\mark\Projects

This method is simple and low risk. It changes only that shortcut, so it is a good choice if you want one shortcut for a project directory and another for your default home directory.

There is one important limitation: the shortcut controls only launches that actually use that shortcut. If you open Git Bash from another launcher, from Windows Terminal, or from Explorer integration, this setting may not apply.

Method 2: Change Directory in .bash_profile or .bashrc

If you want every interactive Git Bash session to start in a particular location, add a guarded cd command to your shell startup file.

A practical version looks like this:

1# ~/.bash_profile
2project_root="/c/Users/mark/Projects"
3
4if [[ $- == *i* ]] && [[ -d "$project_root" ]]; then
5  cd "$project_root"
6fi

A few details matter here:

• use Git Bash path style such as /c/Users/mark/Projects
• check that the shell is interactive so scripts are not affected
• check that the directory exists before changing into it

On most Git for Windows installations, .bash_profile is a better place for this than .bashrc when the goal is startup navigation. If you already source .bashrc from .bash_profile, either file can work, but keep the behavior predictable.

Choose the Right Method

Use the shortcut method when:

• you care about one launch path only
• you do not want shell startup files to change behavior globally
• you need different shortcuts for different projects

Use the shell-file method when:

• you want every Git Bash window to start in one location
• you often start Git Bash from multiple launchers
• you want the behavior versioned in your dotfiles

In practice, the shortcut method is easier for most users, while the shell-file method is more portable for people who already maintain shell configuration carefully.

Handle Windows Terminal Separately

If you launch Git Bash inside Windows Terminal, its starting directory is usually controlled by the Windows Terminal profile rather than the old Start-menu shortcut. In that case, update the profile's startingDirectory setting.

A profile entry can look like this:

1{
2  "name": "Git Bash",
3  "commandline": "C:\\Program Files\\Git\\bin\\bash.exe -i -l",
4  "startingDirectory": "C:\\Users\\mark\\Projects"
5}

This is often the real answer when someone says the shortcut change "did nothing". They were not using that shortcut anymore.

Avoid Startup Side Effects

Be careful with unconditional cd commands in shell startup files. They can interfere with scripts, shell integrations, or terminals that are intentionally opened in a specific folder.

A more selective version is sometimes better:

1# ~/.bash_profile
2preferred_dir="/c/Users/mark/Projects"
3
4if [[ $- == *i* ]] && [[ "$PWD" == "$HOME" ]] && [[ -d "$preferred_dir" ]]; then
5  cd "$preferred_dir"
6fi

This version changes directories only if the shell would otherwise start in the home directory. That preserves directory choices made by other launchers.

Common Pitfalls

The most common mistake is using Windows path syntax such as C:\Projects inside .bash_profile. Git Bash expects POSIX-style paths like /c/Projects in shell commands.

Another mistake is editing .bashrc or .bash_profile without checking whether the terminal session is interactive. An unconditional cd can break automation and confuse scripts.

People also often change the shortcut and then continue launching Git Bash from Windows Terminal or Explorer. In that case the shortcut setting has no effect.

Finally, if the target directory does not exist, Git Bash will show an error or remain in the original location. Guard the cd with a directory existence check.

Summary

• The simplest fix is changing the Git Bash shortcut Start in directory
• Use .bash_profile or .bashrc when you want all interactive shells to start elsewhere
• In shell files, use paths like /c/Users/name/Projects, not C:\Users\name\Projects
• Guard cd logic so non-interactive shells are not affected
• If you use Windows Terminal, update its startingDirectory setting separately
• Pick the method that matches how you actually launch Git Bash