小さなプロジェクトの開発中、私はWindowsとUbuntuの両方でGitを使用してきました。問題は、Git Bashが常に遅くなることです。
遅いと言うと、cd
の実行には8〜25秒、git
コマンドの実行には5〜20秒かかり、ls
には最大30秒かかることがあります。言うまでもありませんが、これは楽しくはありません、非生産的なことは言うまでもありません。私はGitがWindows上で遅いことを知っていますが、これはばかげています。
私のために - 一時的に - うまくいった1つの解決策は私のネットワーク接続を無効にすることでした( この答えで提案されているように )その後、再接続してください。それを実行した後、何日も速く実行され続けることがありますが、パフォーマンスは常に最終的に低下します。私はmsysgitディスカッショングループ、Stack Overflow、msysgit issueリストなどを何週間もオンとオフにトロールしましたが、うまくいく解決策を見つけることはできませんでした。
これまでのところ、私は試してみました:
git gc
を実行する私は何人かの人々がBashの完成を無効にすることに成功したと読んだが、理想的にはそれをアクティブにしておきたい。 msysgitのバージョンは1.7.3.1-preview20101002で、OSはWindows 7 x64です。 Linuxで同じことを実行するのは、予想通り、超高速です。私は専らLinuxを使いますが、私もWindowsでものを実行する必要があります(特定のアプリケーション、テストなど)。
誰かが同様の問題に遭遇しましたか?もしそうなら、根本的な問題は何でしたか?
これはGitリポジトリだけではありませんが、参考までにGitを使用していたリポジトリは非常に小さく、最大4〜50ファイルです。
Gitを完全にアンインストールし、(古典的なWindowsの治療)再起動し、そしてGitを再インストールすることが治療だったようです。私はまた、残っていた(それらは手動で作成された)すべてのbash設定ファイルを一掃しました。すべてがまた速いです。
何らかの理由で再インストールができない(または望ましくない)場合は、 Chris Dolan's answer で参照されているPS1変数を確実に変更してみてください。その結果、特定の業務で大幅なスピードアップが実現しました。
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.fscache
はUACの問題を修正しているため、Gitを管理者として実行する必要はありません(更新:Git for Windows 2.8ではデフォルトで有効になっています)。
gc.auto
は、.git /内のファイル数を最小限に抑えます。
BashプロンプトにGit情報が表示されていますか?もしそうなら、たぶんあなたは誤ってすべてのコマンドに対してやり過ぎるやり方をしているのでしょう。この理論を試すために、Bashで次の一時的な変更を試してください。
export PS1='$'
私のWindowsホームディレクトリはネットワーク上にあり、Git Bashコマンドが最初にそこを見ていたのではないかと疑いました。 $PATH
を見ると、/h/bin
が最初にリストされています。ここで、/h
は、Windowsファイルサーバー上の共有です。ただし、/h/bin
は存在しません。
私は/etc/profile
を編集し、それを最初に$PATH
に入れるexportコマンドをコメントアウトしました。
#export PATH="$HOME/bin:$PATH"
これにより、Git Bashがネットワーク上で実行ファイルを探す必要がなくなったため、コマンドの実行速度が大幅に向上しました。私の/etc/profile
はc:\Program Files (x86)\Git\etc\profile
でした。
ネットワークドライブがパフォーマンスの問題であることがわかりました。 HOME
は遅いネットワーク共有を指していました。 HOMEDRIVE
をオーバーライドすることはできませんでしたが、それは私が見たことによる問題ではありません。
デスクトップ上のコンピュータを右クリックして環境変数を設定します - >プロパティ - >システムの詳細設定 - >環境変数ユーザー変数セクションに追加
HOME=%USERPROFILE%
あなたの問題はネットワークベースであるかもしれませんが、私は個人的に私のローカルのgit status
呼び出しを10倍(700秒まで7秒以上)スピードアップしました。これは、21,000のファイルと大量の大きなバイナリファイルを含む700 MBのリポジトリです。
1つは並列インデックスのプリロードを有効にすることです。コマンドプロンプトから:
git config core.preloadindex true
これによりtime git status
は7秒から2.5秒に変更されました。
更新!
以下はもう必要ありません。パッチはmysysgit 1.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でHKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/luafv
の "start"キーを4に変更してドライバを無効にします。次に、UACを最も低い設定の「通知しない」に設定します。
このドライバを無効にすることであなたが用心深くなった場合(そうでなければならない場合)、代替手段はあなたのシステムパーティションとは異なるドライブ(またはパーティション)で実行されています。どうやらドライバは、システムパーティション上のファイルアクセスでのみ実行されます。私は2台目のハードドライブを持っています、そして私がDドライブにそれなしでそうするのと同じように私のCドライブにこのレジストリ修正を加えて実行したとき同じ結果が見られます。
この変更は2.5秒から0.7秒にtime git status
かかります。
https://github.com/msysgit/git/pull/94 と https://github.com/git/git]に従うことをお勧めします。/commit/d637d1b9a8fb765a8542e69bd2e04b3e229f663b では、Windowsで速度の問題に対して現在どのような作業が行われているのかを確認できます。
Chris Dolanの答えを拡張して、私は次の代わりの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秒と非常に高速です。
これは このブログ記事 に基づいています。
私は "Run as administrator"を使ってcmd.exeを起動することによってWindows 7 x64での私の遅いGit問題を解決しました。
ここで推奨されているように、core.preloadindexを trueに設定することで、かなりの改善が見られました 。
Git BashとGit GUIの両方で同じ問題を抱えていました。どちらのプログラムもうまく動作するように使用されていましたが、その後はランダムにクロールが遅くなり、その理由はわかりませんでした。
結局のところ、それはAvastでした。 Avastは様々なプログラム(私が書いたプログラムを含む)に奇妙なことを起こしたので、しばらくの間それを無効にしました、そして確かに、Bashは今やLinux上で動作するのと同じくらい速く動きます。 Gitプログラムファイルフォルダ(C:\Program Files\Git
)をAvastの除外リストに追加したところ、Linuxと同じ速度で実行されます。
もちろん、ウイルス対策ソフトウェアは最初の投稿では問題になっていなかったことを理解していますが、これが誰かに役立つ場合のためにここに掲載します。
Chris DolanとWilbertの答えで述べたように、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" answer - 200ミリ秒対400ミリ秒より速いので、プロンプトの多少の遅れを少なくします。
それは__git_ps1
ほど洗練されていません - 例えば、あなたが.gitディレクトリにcdした時などにプロンプトを変えることはありません、しかし通常の日常の使用のためにそれは十分で速く速いです。
これはGit 1.7.9でテストされました(Cygwin、しかしどのプラットフォームでも動作するはずです)。
また、次のGit設定を変更することで、パフォーマンスを大幅に向上させることができます。
git config --global status.submoduleSummary false
Windows 7 x64で単純なgit status
コマンドを実行すると、コンピューターの実行に30秒以上かかりました。このオプションが定義された後、コマンドは即時に実行されます。
次のページで説明されているようにGit自身のトレースをアクティブにすると、問題の原因を突き止めることができました。これはインストールによって異なる可能性があります。 https://github.com/msysgit/msysgit/wiki/Diagnosing-why-Git-is -とても遅いです
これらの他の答えに加えて、私は並列サブモジュールフェッチを使って複数のサブモジュールを持つプロジェクトをスピードアップしました(2016年初めのGit 2.8以降)。
これはgit fetch --recurse-submodules -j8
を使ってgit config --global submodule.fetchJobs 8
を使って設定することができますが、あなたが使用したい/使用したいコアがたくさんあります。
CmdからGitを使用する場合は、Git Bashから実行してみてください。 cmdでは、git.exeは実際には起動するたびに正しい環境を設定するラッパーで、実際のgit.exeを起動するだけです。それはちょうどあなたが望むことをするのに必要とされる時間の最大2倍の時間がかかることがあります。そしてGit Bashは起動時にのみ環境を設定します。
私の場合、それは実際にはGit BashやPowerShellでさえも遅くなっているAvastアンチウイルスでした。
私は最初にAvastを10分間無効にして速度が向上したかどうかを確認しました。その後、Git Bashのインストールディレクトリ全体をAvastの例外として、読み込み、書き込み、実行用に追加しました。私の場合はC:\Program Files\Git\*
でした。
私はWindows 7 x64上でGit for Windows(msysgit)を制限付きユーザーアカウントとして実行しているのと同じ問題をかなり以前から経験しています。
私がここで読んだことと他の場所から、共通のテーマは管理者特権やUACの欠如であるようです。 UACは私のシステムではオフになっているので、program filesディレクトリに何かを書いたり削除したりしようとしているという説明が私には最も理にかなっています。
いずれにせよ、私はGit 1.8のポータブル版をzipinstallerを使ってインストールすることで問題を解決しました。 zipinstallerが機能するためには、.7z配布ファイルを解凍してZipファイルとして再パックする必要がありました。また、そのディレクトリをシステムパスに手動で追加する必要がありました。
性能は今大丈夫です。それがProgram Files (x86)
ディレクトリにインストールされていても、それは私が制限されたユーザとしてのパーミッションを持っていません、それは同じ問題に苦しむようには見えません。
これは、ポータブル版がファイルの書き込み/削除を行う場所でもう少し保守的であるという事実、または1.7から1.8へのアップグレードのどちらかが原因と考えられます。どちらがその理由であるかを突き止めようとはしません。Bashを含めて、今ではそれがはるかにうまく機能すると言えば十分です。
複合回答:
# 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}\] $ '
結果:
デバイスマネージャでAMD Radeonグラフィックス(またはインテルグラフィックス)をオフにするだけで私は役に立ちました。
私はここで答えを見つけました: https://superuser.com/questions/1160349/git-is-extremely-slow-on-windows#=
上記のどれも私を助けることができませんでした。私のシナリオでは、問題は次のようになっていました。
ll
コマンドが遅い(実行に約3秒かかりました)ll
コマンドは即時に実行されました。ただし、直前のlsコマンドから45秒以内の場合に限ります。それが Process Monitor でデバッグするようになったとき、すべてのコマンドの前にDNS要求があることがわかりました。
ファイアウォールを無効にしたら(私の場合はComodo)、コマンドを実行して問題がなくなりました。そして、ファイアウォールが再びオンになっても元に戻りません。最も早い機会に、どのプロセスがブロックしているDNS要求を実行していて、何がターゲットだったのかについての詳細で、この応答を更新します。
BR、G
私の場合、Git BashのショートカットはStart in:%HOMEDRIVE%%HOMEPATH%
に設定されています(これを確認するには、Git Bashを右クリックしてプロパティを選択します)。これはネットワークドライブでした。
解決策は%HOME%
を指すようにすることです。お持ちでない場合は、環境変数で設定することができます。これでGit Bashは非常に高速になります。
私の同僚はGit on Windowsで問題を抱えていました(7)git status
checkout
とadd
は速いですが、git commit
は年をとります。
私たちはまだこの根本的な原因を突き止めようとしていますが、リポジトリを新しいフォルダにクローンすることで彼の問題は解決しました。
多くの人が言ったように、これはstash
がWindows上のシェルスクリプトであることに起因しますが、Git 2.18.0以降、Windowsインストーラーにはより高速な(〜90%)stashの実験的機能のオプションがあります - https://github.com/git-for-windows/build-extra/pull/203 。
私は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='$'
ここで一つの答えで述べたように。コマンドラインは非常に高速でした。
今私はこれを使っています:
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
...
スタックオーバーフローの投稿からPS1行にgitの現在のブランチと色があり、それはうまく動作します。また速いGitコマンドラインを持ってください。