私は 2 つのソース コード管理システムについて学習していて、それらの分岐戦略が大きく異なることを発見しました。
その Perforce は元のファイルをすべて新しいブランチにコピーしますが、領域の拡大を防ぐためにいくつかのトリック (遅延コピー、「p4 -v」など) を適用しますが、最終的にはより多くの領域を消費し、より多くのメタ データを残します。代わりに、GIT では、分岐は基本的にポインターの移動です。Perforceが同じアプローチを採用できないのはなぜですか? それは、(Perforce のように) ファイルの違いではなく、(git のように) スナップショットを保存するという負担が伴うからですか?
また、GIT が差分ではなくファイルのスナップショットを保存するのはなぜですか? そうする必要はありますか？一般的に、GIT コード リポジトリは Perforce のリポジトリよりも大きくなるということですか? 同じものを両方のシステムに保存する場合は? GIT の場合、コミットに時間がかかりますか?
Git は実際にデルタも保存します。これらはパックファイルと呼ばれます。ファイルをわずかに 100 回変更した場合、100 個のわずかに異なるオブジェクトを保持することはできません。(詳細はこちら: http://git-scm.com/book/en/Git-Internals-Packfiles )
スナップショットは絶対的な真実です。そのため、git はそのように履歴を保存します。ファイルが特定の方法でどのように、なぜ変更されたかを想定しないという単純なアプローチを取ります。上記のツールで履歴を分析し、「このファイルはこの時点で名前が変更されました」などの情報を提供することがビジョンです。
それが履歴の一部である場合、小さな変更を伴う名前変更と削除および作成を構成するしきい値が変更された場合、すべてを書き直す必要があります。シンプルイズベスト。これが Linux ソース コードを追跡するために Linux で設計されたという事実は、そのプラットフォームの同様の哲学に従っています。
これは実際には複雑なトピックですが、分岐とファイル履歴の処理方法にはトレードオフがあります。Git ブランチはリポジトリ レベルですが、Perforce は非常にきめ細かく、単一のファイル、または通常は個別に開発される複数のファイル セットをブランチできます。
あなたが言及したように、Git ブランチは非常に高速で軽量ですが、Perforce ブランチを使用すると、何が起こるかをもう少し制御できます。