回答:
git ls-remoteコマンドはその目的のために作られていると思います。
--exit-code引数を使用する場合、への出力の送信をスキップできますnull。エラーの場合にのみ何かを返します。
また、-h引数を使用して、ヘッド参照のみを表示できます。
git ls-remote --exit-code -h "$REPO_URL"
              -h素晴らしいアイデアです。ただし、--exit-codeここでは正しい選択ではありません。マニュアルページには、リモートリポジトリに一致する参照が見つからない場合、ステータス「2」で終了します。これは、でgit ls-remote --exit-code "$REPO_URL"初期化されたばかりの空のレポでは失敗することを意味しgit initます。
                    次のようなものを使用して出力を絞り込むことができます git ls-remote "$REPO_URL" HEAD
TL; DR:
git ls-remote 方法です、ここに迅速なアクセスのためのシェル対応関数があります:
  ## Returns errlvl 0 if $1 is a reachable git remote url 
  git-remote-url-reachable() {
      git ls-remote "$1" CHECK_GIT_REMOTE_URL_REACHABILITY >/dev/null 2>&1
  }
使用法:
if git-remote-url-reachable "$url"; then
   ## code
fi
何してるの?
これは、以前に述べられたすべてのコメント/ソリューションの便利なマッシュアップであり、いくつかの小さな調整、バッシュコピーペーストの準備ができた関数、使用法のコードサンプルが非常に明確になっています。次のことに注意してください。
チェックされた参照はおそらく存在しないため、出力が制限されます。これは、git 
一致しないrefでエラーレベル0で終了するためです。ここでの唯一の違いは、ネットワークに転送する出力が要求する場合と比べてわずかに少ないことですHEAD(refを要求しないか、ヘッドのみに制限するよりもはるかに少ない)。また、これはキャストする出力も少なくなります/dev/null(ただし、とにかく最後の1つは取るに足らない時間です)
refをチェックすると、存在を調査していることが明確になります。これは、調査しているサーバーの管理者に礼儀正しくなりたい場合に役立ち、何かを監視している場合にこれらのプローブを受信する理由を理解する機会を与えます。
/dev/null)「余分な作業」のオーバーヘッドは、かなり小さいはずです。