--depth 1で浅いクローンを作成してコミットを作成し、更新を再度プルしても安全ですか？

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

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

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

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

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

それで、浅いクローンを作成し、コミットを開発し、もう一度プルして、元の更新に追いつくのは安全ですか？

Git 1.9 / 2.0（2014年第1四半期）では、この制限が取り除かれていることに注意してください。
参照82fba2bコミットから、グエンタイ・ゴックDuyと（pclouds）：

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

ドキュメントは今読み：

--depth <depth>::

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

これは、0d7d285、f2c681c、およびc29a7b8のようなコミットから派生しています。これらは、浅いクローンでのクローン、送信パック/受信パックをサポートしています。
smart-httpが浅いフェッチ/クローンもサポートするようになりました。

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

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

2016年1月の更新：Git 2.8（Mach 2016）で、最小限の履歴を取得する方法が正式に文書化されました。
参照99487cfコミット、9cfde9eをコミット（2015年12月30日）に、9cfde9eをコミット（2015年12月30日）に、bac5874をコミット（2015年12月29日）を、そして1de2e44コミット（2015年12月28日）をすることによりスティーブン・P.スミス（ ``） 。
^{（合併によりJunio C浜野- gitster-でコミット7e3e80a、2016年1月20日）}

これは「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シャロークローンを更新する方法」を参照してください。

Richard Michaelによるコメント：

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

そして、オルレ・ハーステットはコメントに追加します：

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

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

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

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

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

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