456

私は小さなプロジェクトの開発中にWindowsとUbuntuの両方でGitを使用しており、2つの間を頻繁に行き来しています。問題は、GitBashが一貫して遅くなることです。

cd遅いとは、実行に8〜25秒かかり、gitコマンドの実行に5〜20秒かかり、ls場合によっては最大30秒かかることを意味します。言うまでもなく、これは非生産的であることは言うまでもなく、楽しいことではありません。WindowsではGitの速度が遅いことは知っていますが、これはばかげています。

私にとって(一時的に)機能した1つの解決策は、ネットワーク接続を無効にし(この回答で提案されているように)、Git Bashを起動してから、再接続することでした。それを行った後も数日間は高速で動作し続けることがありますが、最終的には常にパフォーマンスが低下します。msysgitディスカッショングループ、Stack Overflow、msysgit問題リストなどを何週間もオンとオフでトロールしましたが、機能するソリューションを見つけることができませんでした。

これまでのところ、私は試しました:

  • ウイルススキャナーの除外リストにGitおよびプロジェクトフォルダーを追加する
  • ウイルススキャナーを完全に無効にする(Kaspersky IS 2011)
  • Outlookが実行されていないことを確認する(Outlook 2007)
  • 他のすべてのアプリケーションをシャットダウンする
  • 管理者としてGitBashを実行する
  • ネットワーク接続を無効にし、Git Bashを起動し、接続を無効のままにします
  • ネットワーク接続の無効化、Git Bashの起動、接続の再有効化(たまにしか機能しません)
  • ランニングgit gc
  • そして上記の組み合わせ

数人の人がBashの完了を無効にすることに成功したことを読みましたが、理想的にはそれをアクティブに保ちたいと思います。msysgitのバージョンは1.7.3.1-preview20101002で、OSはWindows7x64です。Linuxで同じことを実行すると、予想通り、非常に高速になります。Linuxだけを使用しますが、Windowsでも実行する必要があります(特定のアプリケーション、テストなど)。

誰かが同様の問題に遭遇しましたか?もしそうなら、根本的な問題は何でしたか、そして解決策は何でしたか(もしあれば)?

これはGitリポジトリだけにとどまりませんが、参考までに、私がGitを使用してきたリポジトリはかなり小さく、最大で4〜50ファイルです。

4

24 に答える 24

427

3つのコマンドを実行していくつかの構成オプションを設定することにより、WindowsでGitを大幅に高速化できます。

git config --global core.preloadindex true
git config --global core.fscache true
git config --global gc.auto 256

ノート:

  • core.preloadindexレイテンシーを隠すためにファイルシステム操作を並行して実行します(更新:Git 2.1ではデフォルトで有効になっています)

  • core.fscacheUACの問題を修正して、管理者としてGitを実行する必要がないようにします(更新:Git for Windows 2.8ではデフォルトで有効になっています)

  • gc.auto.git/内のファイルの数を最小限に抑えます

于 2014-06-04T19:30:22.193 に答える
109

BashプロンプトにGit情報が表示されていますか?もしそうなら、多分あなたはうっかりしてすべてのコマンドであまりにも多くの仕事をしているでしょう。この理論をテストするには、Bashで次の一時的な変更を試してください。

export PS1='$'
于 2010-12-19T22:10:10.453 に答える
93

私のWindowsホームディレクトリはネットワーク上にあり、GitBashコマンドが最初にそこを探していたのではないかと思いました。案の定、私が見たとき、それは最初に$PATHリストされていました。それは、存在していなくても、Windowsファイルサーバー上の共有です。 私はそれを最初に置くエクスポートコマンドを編集してコメントアウトしました:/h/bin/h/h/bin
/etc/profile$PATH

#export PATH="$HOME/bin:$PATH"

これにより、コマンドの実行が大幅に高速化されました。これは、GitBashがネットワーク全体で実行可能ファイルを検索しなくなったためと考えられます。私/etc/profileはでしたc:\Program Files (x86)\Git\etc\profile

于 2011-08-09T14:27:32.960 に答える
53

ネットワークドライブがパフォーマンスの問題であることがわかりました。HOME遅いネットワーク共有を指していた。私はオーバーライドできませんでしHOMEDRIVEたが、それは私が見たものからの問題ではありません。

デスクトップでコンピューターを右クリックして環境変数を設定します->プロパティ->システムの詳細設定->環境変数ユーザー変数に追加セクション

HOME=%USERPROFILE%
于 2015-01-07T22:34:10.983 に答える
26

クリス・ドランの答えの拡張として、私は次の代替PS1設定を使用しました。コードフラグメントを〜/ .profileに追加するだけです(Windows 7の場合:C:/ Users / USERNAME / .profile)。

fast_git_ps1 ()
{
    printf -- "$(git branch 2>/dev/null | sed -ne '/^\* / s/^\* \(.*\)/ [\1] / p')"
}

PS1='\[\033]0;$MSYSTEM:\w\007
\033[32m\]\u@\h \[\033[33m\w$(fast_git_ps1)\033[0m\]
$ '

これにより、色付きのシェルと現在のブランチ名の表示(Gitリポジトリにある場合)の利点が維持されますが、私のマシンでは、約0.75秒から0.1秒と大幅に高速になります。

これは、このブログ投稿に基づいています。

于 2012-11-20T15:53:45.590 に答える
23

あなたの問題はネットワークベースかもしれませんが、私はgit status2つの変更を行うことで、市内通話を10倍(7秒以上から700ミリ秒まで)高速化しました。これは、21,000個のファイルと過剰な数の大きなバイナリファイルを含む700MBのリポジトリにあります。

1つは、並列インデックスのプリロードを有効にすることです。コマンドプロンプトから:

git config core.preloadindex true
これtime git statusは7秒から2.5秒に変更されました。

アップデート!

以下は不要になりました。パッチはmysysgit1.9.4の時点でこれを修正しました
https://github.com/msysgit/git/commit/64d63240762df22e92b287b145d75a0d68a66988
ただし、次のように入力して修正を有効にする必要があります
git config core.fscache true

また、UACと「luafv」ドライバーを無効にしました(再起動が必要です)。これにより、Windows Vista、7、および8で、システムの場所に書き込もうとしているプログラムをリダイレクトし、代わりにそれらのアクセスをユーザーディレクトリにリダイレクトするドライバーが無効になります。

これがGitのパフォーマンスにどのように影響するかについての説明を見るには、 https ://code.google.com/p/msysgit/issues/detail?id=320をお読みください。

このドライバーを無効にするには、regeditで、「start」キーHKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafvを4に変更してドライバーを無効にします。次に、UACを最低の設定である「通知しない」にします。

このドライバを無効にすると警戒する必要がある場合は、システムパーティションとは別のドライブ(またはパーティション)で別の方法を実行しています。どうやら、ドライバはシステムパーティションのファイルアクセスでのみ実行されます。2台目のハードドライブがあり、Cドライブでこのレジストリを変更して実行すると、Dドライブで実行しない場合と同じ結果が得られます。

この変更にはtime git status、2.5秒から0.7秒かかります。

また、 https ://github.com/msysgit/git/pull/94およびhttps://github.com/git/git/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663bをフォローして、Windowsの速度の問題について進行中の追加作業を確認することもできます。 。

于 2014-03-05T20:47:50.137 に答える
20

Gitを完全にアンインストールし、再起動して(従来のWindowsの治療法)、Gitを再インストールすることが治療法だったようです。また、残っているすべてのbash構成ファイルを消去しました(手動で作成されました)。すべてが再び速い。

何らかの理由で再インストールが不可能(または望ましい)でない場合は、ChrisDolanの回答で参照されているPS1変数を変更してみてください。その結果、特定の操作が大幅に高速化されました。

于 2010-12-22T04:37:12.543 に答える
9

「管理者として実行」でcmd.exeを起動することにより、Windows7x64での遅いGitの問題を解決しました。

于 2011-10-28T01:04:42.057 に答える
8

また、次のGit構成を変更することで、パフォーマンスが大幅に向上する可能性があります。

git config --global status.submoduleSummary false

Window 7 x64で単純なgit statusコマンドを実行すると、コンピューターの実行に30秒以上かかりました。このオプションが定義された後、コマンドはすぐに実行されます。

次のページで説明されているようにGit自体のトレースをアクティブ化すると、問題の原因を見つけることができました。これは、インストールによって異なる場合があります 。https ://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is-so-スロー

于 2016-12-01T16:36:57.200 に答える
7

ここで推奨されているように、core.preloadindexをtrueに設定することで、まともな改善が見られました。

于 2013-08-17T10:49:04.240 に答える
6

クリス・ドランとウィルバートの答えに記されているように、PS1はあなたを遅くします

(Dolanが提案したように)完全に無効にしたり、Wilbertが提供するスクリプトを使用したりするのではなく、はるかに高速な「ダムPS1」を使用します。

それは使用します(git symbolic-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ていません。たとえば、.gitディレクトリなどにcdしたときにプロンプ​​トが変更されることはありませんが、通常の日常的な使用には十分かつ高速です。

これはGit1.7.9でテストされました(Cygwinですが、どのプラットフォームでも機能するはずです)。

于 2013-10-21T16:46:12.547 に答える
5

これらの他の回答に加えて、並列サブモジュールフェッチを使用して、複数のサブモジュールを持つプロジェクトを高速化しました(2016年初頭のGit 2.8以降)。

これは、、または使用したい/使用したい多くのコアを使用して実行git fetch --recurse-submodules -j8および設定できます。git config --global submodule.fetchJobs 8

于 2018-06-15T15:27:04.317 に答える
4

GitBashとGitGUIの両方で同じ問題が発生していました。どちらのプログラムも以前はうまく実行されていましたが、その後ランダムに速度が低下してクロールし、その理由がわかりませんでした。

結局のところ、それはアバストでした。アバストはさまざまなプログラム(私が書いたプログラムを含む)に奇妙なことを引き起こしたので、私はそれを少しの間無効にしました、そして確かに、BashはLinuxで実行するのと同じくらい速く実行されます。Gitプログラムファイルフォルダー(C:\Program Files\Git)をアバスト除外リストに追加したところ、Linuxと同じ速度で実行されるようになりました。

はい、元の投稿ではウイルス対策ソフトウェアが問題ではなかったことに気づきましたが、誰かに役立つ場合に備えて、ここにこれを配置します。

于 2016-04-05T04:49:23.633 に答える
4

デバイスマネージャでAMDRadeonGraphics(またはIntel Graphics)をオフにするだけで役に立ちました。

ここに画像の説明を入力してください

私はここで答えを見つけました: https ://superuser.com/questions/1160349/git-is-extremely-slow-on-windows# =

于 2018-05-12T11:03:40.573 に答える
3

私の場合、Git Bashショートカットはに設定されていましたStart in:%HOMEDRIVE%%HOMEPATH%(これは、Git Bashを右クリックしてプロパティを選択することで確認できます)。これがネットワークドライブでした。

解決策は、を指すようにすること%HOME%です。お持ちでない場合は、環境変数で設定できます。これで、GitBashは非常に高速になります。

于 2016-05-12T09:00:00.340 に答える
3

組み合わせた答え:

  1. Wilbert's -PS1に含める情報
  2. sinelaw's-(<branch_name>)または_(<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}\] $ '

結果:

frolowr @ RWAMW36650 / c / projects / elm-math-kids(マスター)$

于 2017-04-23T09:40:46.360 に答える
2

かなり長い間、制限付きユーザーアカウントとしてWindows7x64でGitforWindows(msysgit)を実行しているときに同じ問題が発生しました。

私がここや他の場所で読んだことから、共通のテーマは管理者権限やUACの欠如であるように思われます。私のシステムではUACがオフになっているので、プログラムファイルディレクトリに何かを書き込んだり削除したりしようとしているという説明が最も理にかなっています。

いずれにせよ、私はzipinstallerを使用してGit1.8のポータブルバージョンをインストールすることで問題を解決しました。zipinstallerを機能させるには、.7z配布ファイルを解凍してZIPファイルとして再パックする必要があることに注意してください。また、そのディレクトリをシステムパスに手動で追加する必要がありました。

パフォーマンスは今は大丈夫です。Program Files (x86)制限付きユーザーとしての権限がないディレクトリにインストールされていても、同じ問題は発生していないようです。

私はこれを、ポータブルバージョンがファイルの書き込み/削除の点でもう少し保守的であるという事実(おそらくそうです)、または1.7から1.8へのアップグレードのいずれかに起因します。どちらが理由であるかを特定しようとはしませんが、Bashを含め、今でははるかにうまく機能していると言えば十分です。

于 2012-12-19T04:24:44.563 に答える
2

私の場合、それは実際にはアバストアンチウイルスであり、Git Bashにつながり、PowerShellでさえ非常に遅くなりました。

最初にアバストを10分間無効にして、速度が向上するかどうかを確認しました。その後、アバストの例外として、読み取り、書き込み、実行のためにGitBashインストールディレクトリ全体を追加しました。私の場合、それはでしたC:\Program Files\Git\*

于 2016-07-21T23:09:39.990 に答える
1

cmdからGitを使用する場合は、GitBashから実行してみてください。cmdでは、git.exeは実際には、起動するたびに正しい環境をセットアップし、実際のgit.exeを起動するラッパーです。やりたいことをするのに必要な時間の最大2倍の時間がかかることがあります。また、Git Bashは、起動時にのみ環境をセットアップします。

于 2016-07-19T08:57:16.900 に答える
0

私の同僚は、Windows上のGit(7)で問題が発生しgit status checkoutadd高速でしたが、時間がgit commitかかりました。

私たちはまだこれの根本的な原因を見つけようとしていますが、リポジトリを新しいフォルダに複製すると彼の問題は修正されました。

于 2016-05-24T12:37:15.387 に答える
0

上記のどれも私を助けることができませんでした。私のシナリオでは、問題は次のように表示されていました。

  • llコマンドが遅かった(実行に約3秒かかった)
  • 後続のllコマンドは即座に実行されましたが、前のlsコマンドから45秒以内の場合に限ります

Process Monitorを使用したデバッグに関しては、すべてのコマンドの前にDNS要求があったことがわかりました。

したがって、ファイアウォール(私の場合はComodo)を無効にして、コマンドに実行させるとすぐに問題は発生しなくなります。また、ファイアウォールがオンに戻されたときに、元に戻らない。できるだけ早い機会に、この応答を更新して、DNS要求をブロックしているプロセスとターゲットが何であるかについての詳細を更新します。

BR、G

于 2018-02-18T02:42:41.953 に答える
0

多くの人が言っているように、これはstashWindowsのシェルスクリプトであるためですが、Git 2.18.0以降、Windowsインストーラーには、はるかに高速な(〜90%)組み込みバージョンのstashの実験的な機能のオプションがあります-https :/ /github.com/git-for-windows/build-extra/pull/203

于 2018-10-22T21:20:37.187 に答える
0

私も同様の状況にあり、問題はActiveDirectoryとVPNの背後にあることに関連していました。

そのように半年間働いた後、この金を見つけました:http: //bjg.io/guide/cygwin-ad/

基本的に必要なのは、セクションから(gitディレクトリにあります)で無効dbにすることだけなので、ファイルは次のようになります。/etc/nsswitch.confpasswdgroup

# Begin /etc/nsswitch.conf
passwd: files
group: files
db_enum: cache builtin
db_home: cygwin desc
db_shell: cygwin desc
db_gecos: cygwin desc
# End /etc/nsswitch.conf

次に、ローカルパスワードとグループ設定を1回更新します。

$ mkpasswd -l -c > /etc/passwd
$ mkgroup -l -c > /etc/group
于 2021-01-21T09:14:31.293 に答える
-1

git PS1の速度の低下にも問題がありましたが、長い間、データベースサイズの問題(大きなリポジトリ)だと思っていて、さまざまなgit gcトリックを試していました。あなたと同じように、他の理由も探していました。しかし、私の場合、問題は次の行でした。

function ps1_gitify
{
   status=$(git status 2>/dev/null )      # <--------------------
   if [[ $status =~ "fatal: Not a git repository" ]]
   then
       echo ""
   else
       echo "$(ps1_git_branch_name)  $(ps1_git_get_sha)"
  fi
}

すべてのgit statusコマンドラインステータスラインに対して実行するのは遅かった。痛い。手書きで書いたものです。私が試したときにそれが問題であることがわかりました

export PS1='$'

ここで1つの答えで述べたように。コマンドラインは非常に高速でした。

今私はこれを使用しています:

function we_are_in_git_work_tree
{
    git rev-parse --is-inside-work-tree &> /dev/null
}

function ps1_gitify
{
    if ! we_are_in_git_work_tree
    then
    ...

git current branchandcolorsを使用したStackOverflowpost PS1ラインから、正常に動作します。ここでも、高速なGitコマンドラインがあります。

于 2016-02-08T11:15:43.657 に答える