Introduction

If Git Bash forgets your aliases every time you close the terminal, the problem is almost never the alias syntax itself. The usual issue is that the alias was typed only for the current session or stored in a startup file that Git Bash is not actually loading.

Put aliases in a file that Bash reads on startup

Aliases only persist when they are defined in a shell startup file. A common setup is:

• '~/.bash_profile for login-shell startup'
• '~/.bashrc for interactive shell setup'
• '~/.bash_aliases for alias definitions'

A clean arrangement is to keep aliases in ~/.bash_aliases and source that file from ~/.bashrc:

1# ~/.bash_aliases
2alias gs='git status -sb'
3alias ga='git add'
4alias gc='git commit'
5alias ll='ls -alh'

1# ~/.bashrc
2if [ -f ~/.bash_aliases ]; then
3  . ~/.bash_aliases
4fi

Then make sure your login profile loads .bashrc:

1# ~/.bash_profile
2if [ -f ~/.bashrc ]; then
3  . ~/.bashrc
4fi

That chain covers the common Git Bash startup flow on Windows.

Reload and verify the configuration

After editing the files, reload them in the current terminal:

source ~/.bashrc
type gs
alias | grep '^alias gs='

If type gs reports that gs is an alias, the current shell sees it. The next step is opening a fresh Git Bash window to confirm the startup files are being read on launch.

Git aliases versus shell aliases

If the shortcut is meant only for Git, consider using Git’s built-in alias system instead of a Bash alias:

git config --global alias.st 'status -sb'
git config --global alias.last 'log -1 --stat'

Then use:

git st
git last

Git aliases are often more portable because they work even in terminals that are not Bash.

Common Windows-specific issues

Git Bash on Windows introduces a few extra problems:

• profile files may exist in the wrong home directory
• editors may save startup files with Windows line endings
• different shortcuts may launch Bash with slightly different startup behavior

Check the home directory Bash is actually using:

echo "$HOME"

And check file format if parsing looks broken:

file ~/.bashrc ~/.bash_profile ~/.bash_aliases

If the files contain problematic line endings or syntax errors, Bash may stop reading them early and your aliases never get defined.

Debugging startup behavior

When the issue is not obvious, trace shell startup:

bash -lxic 'type gs'

This prints which files were sourced and helps you catch:

• missing source lines
• syntax errors
• aliases overridden later by another file

That is usually faster than guessing which configuration file is responsible.

Common Pitfalls

One common mistake is defining the alias manually in the terminal and assuming it will still exist tomorrow. Session-only aliases disappear as soon as that shell exits.

Another issue is putting everything into .bash_profile and forgetting that .bashrc may be the better place for interactive shell setup. Sourcing .bashrc from .bash_profile avoids that split-brain setup.

People also edit the wrong file because they assume their Windows user directory and Bash home directory are identical. Always check $HOME.

Finally, keep shell aliases and Git aliases conceptually separate. If the shortcut is only for Git subcommands, Git’s own alias system may be the cleaner answer.

Summary

• Persistent aliases must live in a shell startup file, not only in the current session.
• A reliable Git Bash setup is .bash_profile sourcing .bashrc, and .bashrc sourcing .bash_aliases.
• Use source, type, and startup tracing to verify what Git Bash actually loads.
• Check $HOME and file line endings on Windows when startup behavior seems inconsistent.
• Prefer Git’s built-in aliases when the shortcut is specifically for Git commands.