68

gitを使用してオペレーティング システムを配布し、最新の状態に保ちます。大きすぎる (>2GB) ため、完全なリポジトリを配布することはできません。そのため、浅いクローン (~300M) を使用しています。ただし、最近、浅いクローンからフェッチする場合、2GB を超えるリポジトリ全体を非効率的にフェッチするようになりました。これは、展開の許容できない帯域幅の浪費です。

git のドキュメントには、浅いリポジトリからフェッチすることはできないと書かれていますが、厳密にはそうではありません。git clone --depth 1変更されたものだけをフェッチできるようにするための回避策はありますか? または、配布サイズをできるだけ小さく保ちながら、git が更新を行うために必要なすべてのビットを保持するための他の戦略はありますか?

からのクローン作成を試みて--depth 20、より効率的にアップグレードされるかどうかを確認しましたが、うまくいきませんでした。http://git-scm.com/docs/git-bundleも調べましたが、巨大なバンドルが作成されているようです。

4

5 に答える 5

51

--depthはgit fetchオプションです。git cloneフェッチを行うドキュメントが実際には強調表示されていないことがわかります。

フェッチすると、2 つのリポジトリは、リモートのヘッドから開始して、フェッチされた参照の履歴で最新の共有コミットを逆方向に検索し、不足しているすべてのオブジェクトを埋めて、その間の新しいコミットのみを完了することにより、誰が何を持っているかについて情報を交換します。最新の共有コミットと新しくフェッチされたもの。

フェッチはブランチのヒントを取得する--depth=1だけで、以前の履歴は取得しません。これらの履歴をさらにフェッチすると、上記の手順ですべての新しいものがフェッチされますが、以前にフェッチされたコミットが新しくフェッチされた履歴にない場合、 fetch でフェッチを制限しない限り、フェッチはすべてを取得し--depthます。

あなたのクライアントは、あるレポから depth=1 フェッチを行い、URL を別のレポに切り替えました。この新しいレポの参照にある少なくとも 1 つの長い祖先パスは、現在レポにあるものとコミットを共有していないようです。それは調査する価値があるかもしれませんが、いずれにせよ、特別な理由がない限り、クライアントはすべての fetch を実行できます--depth=1。

于 2013-10-16T03:49:30.907 に答える
38

行ったg clone github.com:torvalds/linuxばかりで、時間がかかりすぎたので、スキップしましたCTRL+C。

その後g clone github.com:torvalds/linux --depth 1、非常に高速にクローンを作成しました。そして、私は にコミットを 1 つだけ持っていgit logます。

だからclone --depth 1うまくいくはずです。既存のリポジトリを更新する必要がある場合は、git fetch origin remoteBranch:localBranch --depth 1. それも機能し、コミットを 1 つだけフェッチします。

要約:

初期クローン:

git clone git_url --depth 1

コードの更新

git fetch origin remoteBranch:localBranch --depth 1
于 2013-10-22T21:07:22.610 に答える
11

特定のブランチを選択できる場合は、さらに高速になります。Spark master ブランチと latest タグを使用した例を次に示します。

初期クローン

git clone git@github.com:apache/spark.git --branch master --single-branch --depth 1

特定のタグへの更新

git fetch --depth 1 origin tags/v1.6.0

この方法でタグ/ブランチを切り替えると非常に高速になります。

于 2016-01-07T14:35:42.257 に答える