似乎完全卸载Git，重新启动(经典的Windows解决方案)，然后重新安装Git是解决方案。我还清除了所有剩下的bash配置文件(它们是手动创建的)。一切又快起来了。

如果出于某种原因，重新安装是不可能的(或不可取的)，那么我肯定会尝试改变Chris Dolan回答中提到的PS1变量;它导致了某些操作的显著加速。

正如许多人所说，这是因为stash在Windows上是一个shell脚本，但从Git 2.18.0开始，Windows安装程序就提供了一个实验性的特性，即更快(~90%)的内置版本stash - https://github.com/git-for-windows/build-extra/pull/203。

正如Chris Dolan和Wilbert的回答所指出的，PS1会减慢你的速度。

我没有完全禁用(正如Dolan建议的那样)，也没有使用Wilbert提供的脚本，而是使用了速度更快的“哑PS1”。

它使用(git symbol -ref -q HEAD || git rev-parse——short HEAD) 2> /dev/null:

PS1='\033[33m\]\w \n\[\033[32m\]$((git symbolic-ref -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null) \[\033[00m\]# '

在我的Cygwin上，这比Wilbert的“fast_Git_PS1”回答要快——200毫秒对400毫秒，所以它可以减少你的提示迟钝。

它不像__git_ps1那么复杂——例如，当你cd到.git目录时，它不会改变提示符，等等，但对于日常使用来说，它足够好和快速。

这是在Git 1.7.9 (Cygwin，但它应该可以在任何平台上工作)上测试的。

在我的例子中，Git Bash快捷方式被设置为开始:%HOMEDRIVE%%HOMEPATH%(您可以通过右键单击Git Bash并选择属性来检查)。这是网络驱动器。

解决方案是让它指向%HOME%。如果您没有，您可以在环境变量中设置它，现在Git Bash应该是闪电般的快。

Bash提示符中是否显示Git信息?如果是这样，也许您无意中在每个命令上都做了太多的工作。为了验证这一理论，请尝试在Bash中进行以下临时更改:

export PS1='$'

以上这些都不能帮助我。在我的场景中，问题是这样表现的:

任何ls -l命令都很慢(大约需要3秒才能执行) 任何后续的ls -l命令都会立即执行，但前提是在前一个ls命令的45秒内。

在使用Process Monitor进行调试时，发现在每个命令之前都有一个DNS请求。

因此，只要我禁用防火墙(在我的情况下是Comodo)并让命令执行，问题就消失了。当防火墙重新打开时，它不会返回。有了最早的机会，我将更新这个响应，提供有关哪个进程正在阻塞DNS请求以及目标是什么的更多详细信息。