我在Git Bash和Git GUI中都遇到了同样的问题。这两个程序以前都运行得很好，但后来它们突然慢了下来，我不知道为什么。

事实证明，是阿瓦斯特。Avast会导致各种程序(包括我编写的程序)发生一些奇怪的事情，所以我暂时禁用了它，当然，Bash现在的运行速度和在Linux上一样快。我只是将Git程序文件文件夹(C:\ program files \Git)添加到Avast排除列表中，现在它的运行速度和在Linux上一样快。

是的，我意识到杀毒软件不是最初帖子中的问题，但我只是把它放在这里，以防它对某人有用。

我的一个同事在Windows(7)上使用Git时遇到了麻烦，Git状态检查和添加都很快，但是Git提交却花了很长时间。

我们仍在试图找到这个问题的根本原因，但克隆存储库到一个新文件夹解决了他的问题。

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

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

通过更改以下Git配置，您还可能获得非常后续的性能提升:

git config --global status.submoduleSummary false

在windows 7 x64上运行简单的git status命令时，我的电脑花了30多秒才运行完。定义此选项后，命令立即生效。

激活Git自己的跟踪，如下面的页面所解释的那样，帮助我找到了问题的根源，这可能与您的安装不同: https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-slow

结合回答:

威尔伯特- PS1中应该包含哪些信息 Sinelaw 's - (<branch_name>) or (<sha>)

# https://unix.stackexchange.com/questions/140610/using-variables-to-store-terminal-color-codes-for-ps1/140618#140618
# https://unix.stackexchange.com/questions/124407/what-color-codes-can-i-use-in-my-ps1-prompt
# \033 is the same as \e
# 0;32 is the same as 32
CYAN="$(echo -e "\e[1;36m")"
GREEN="$(echo -e "\e[32m")"
YELLOW="$(echo -e "\e[33m")"
RESET="$(echo -e "\e[0m")"

# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/19500237#19500237
# https://stackoverflow.com/questions/4485059/git-bash-is-extremely-slow-in-windows-7-x64/13476961#13476961
# https://stackoverflow.com/questions/39518124/check-if-directory-is-git-repository-without-having-to-cd-into-it/39518382#39518382
fast_git_ps1 ()
{
    git -C . rev-parse 2>/dev/null && echo " ($((git symbolic-ref --short -q HEAD || git rev-parse -q --short HEAD) 2> /dev/null))"
}

# you need \] at the end for colors
# Don't set \[ at the beginning or ctrl+up for history will work strangely
PS1='${GREEN}\u@\h ${YELLOW}\w${CYAN}$(fast_git_ps1)${RESET}\] $ '

结果:

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

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

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

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