301

の--depth 1オプションgit clone：

指定されたリビジョン数に切り捨てられた履歴を持つシャロークローンを作成します。浅いリポジトリにはいくつかの制限があります（クローンやフェッチ、プッシュやプッシュはできません）が、長い歴史を持つ大規模なプロジェクトの最近の履歴にのみ関心があり、修正をパッチとして送信します。

しかし、私は浅いクローンを作成し、いくつかの変更をコミットし、それらの変更を（ベアクローン）オリジンにプッシュしました。

それは私には理にかなっています-つまり、なぜですか？複製されたHEADがオリジンで識別可能であり、私のコミットがこれに加えられる場合、理由はないようです。しかし、マニュアルにはそうではないと書かれています。

私は浅いクローンのアイデアが好きです-たとえば、drupalコア：7から始めたときにdrupal 4で何が起こったのかを知る必要はありません-しかし、私は自分自身を足で撃ちたくありません。

それで、クローンを作成し、コミットを開発し、元からの更新に追いつくために再度プルするのは安全ですか？

4

2 に答える 2

324

Git 1.9 / 2.0（2014年第1四半期）でその制限が削除されたことに注意してください。NguyễnTháiNgọcDuy（）のcommit82fba2bを
参照してください。pclouds

gitがシャロークローンとの間のデータ転送をサポートするようになったため、これらの制限はもはや当てはまりません。

ドキュメントは今読んでいます：

--depth <depth>::

指定されたリビジョン数に切り捨てられた履歴を持つ「浅い」クローンを作成します。

これは、 0d7d285、f2c681c、c29a7b8のような、浅いクローンとの/からのクローン、send-pack/receive-packをサポートするコミットに由来します。smart-httpは、浅いフェッチ/クローンもサポートするようになりました。

詳細はすべて「shallow.c：」の新しいコミットを選択するための8つのステップにあります.git/shallow。

2015年6月の更新：Git 2.5では、単一のコミットをフェッチすることもできます。
（究極の浅いケース）

2016年1月の更新：Git 2.8（Mach 2016）は、最小限の履歴を取得する方法を公式に文書化しています。Stephen P. Smith（ ``）によるcommit 99487cf
、commit 9cfde9e（2015年12月30日）、commit 9cfde9e（2015年12月30日）、commit bac5874（2015年12月29日）、commit 1de2e44 （2015年12月28日）を参照してください。（ Junio C Hamanoによってマージされました---コミット7e3e80a、2016年1月20日）
gitster

これは「Documentation/user-manual.txt」

Aは、スイッチ<<def_shallow_clone,shallow clone>>を指定することによって作成されます。 深さは後でスイッチで変更するか、完全な履歴をで復元できます。git-clone --depth
git-fetch --depth--unshallow

<<def_shallow_clone,shallow clone>>マージベースが最近の履歴にある限り、内部でのマージは機能します。
そうしないと、無関係な履歴をマージするようなものになり、大きな競合が発生する可能性があります。
この制限により、このようなリポジトリはマージベースのワークフローでの使用に適さなくなる可能性があります。

2020年の更新：

  • git 2.11.1はgit fetch --shallow-exclude=、すべての履歴のフェッチを防ぐためのオプションを導入しました
  • git 2.11.1ではgit fetch --shallow-since=、古いコミットのフェッチを防ぐためのオプションが導入されました。

シャロークローンの更新プロセスの詳細については、「gitシャロークローンを更新する方法」を参照してください。

リチャードマイケルによってコメントされたように：

履歴を埋め戻すには：git pull --unshallow

そして、 OlleHärstedtはコメントに追加します：

履歴の一部を埋め戻すには： git fetch --depth=100。

于 2014-01-19T13:19:51.380 に答える
5

私の同様の質問why-cant-i-push-from-a-shallow-cloneに対する回答のいくつかと、gitリストの最近のスレッドへのリンクを参照してください。

最終的に、「深度」の測定値はリポジトリ間で一貫していません。これは、リポジトリが（a）ヘッド、（b）クローン/フェッチしたコミット、または（c）他の何かではなく、個々のヘッドから測定するためです。あなたが念頭に置いていた。

難しいのは、ユースケースを正しくすること（つまり、自己矛盾のないこと）です。これにより、分散され、したがって、おそらく発散するリポジトリが引き続きうまく機能します。

checkout --orphanこれは正しい「セットアップ」段階のように見えますが、「クローン」ステップに関する明確な（つまり、単純で理解しやすい1行のコマンド）ガイダンスがまだありません。initむしろ、レポジトリを設定し、remote追跡ブランチを設定し（1つのブランチのみが必要ですか？）、その1つのブランチを設定する必要があるように見えます。fetchこれは、長い間、ミスの可能性が高くなります。

編集：「クローン」ステップについては、この回答を参照してください

于 2011-08-04T23:26:38.903 に答える