1

git バンドル ファイルを分割する方法はありますか? たとえば、repo.bundle1 と repo.bundle2 には、それぞれレポの半分が含まれています。ポータブル バンドルのサイズが大きすぎて転送できません。

転送に許可される最大サイズを変更できないと仮定すると、他にどのようにこれにアプローチできますか。

4

2 に答える 2

1

バンドルは増分にすることができます。

ぶら下がっているコミットを持つことはできないため、既存のブランチを段階的にバンドルしたい場合は、ちょっとしたゲームをプレイする必要があります。

バンドルを適用すると、そのルートコミットの親がラッチできるように、「順番に」適用する必要があります。(浅いリポジトリでこれを回避する方法があるかもしれませんが、最終的にリポジトリ全体を再構築しようとしている場合は、それについて心配する必要はありません。)

もちろん、単一のコミットが大きすぎる場合 (たとえば、非常に大きなファイルをコミットした場合)、それは問題になります。

あなたが持っていると言う

       x -- x -- x <--(branch1)
      /
A -- B -- C -- D -- E -- F -- G -- H -- I -- J <--(master)
                \      /
                 o -- o <--(branch2)

そして、これを 3 つ以下のコミットのバンドルに分割したいとします。それでは、ルートから始めましょう。ブランチを徐々に移動するmasterので、現在の位置を追跡しましょう。

git checkout master
git tag real_master

次に、 の SHA ID を調べます(または、この場合の など、Cを参照する他の名前を見つけます)。Cmaster~7

git reset --hard master~7

ハードリセットを使用していることに注意してください。それはおそらく必要ではありませんが、クリーンな作業ツリーを持つレポからこれを行うことができると仮定しています。

最初のバンドルを作成する準備ができました

git bundle create 0.bundle master

このバンドルにBは のルートである が含まれているためbranch1、今すぐバンドルできbranch1ます。

git bundle create 1.bundle master..branch1

これは、

git bundle create 1.bundle ^master branch1

いずれにせよ、受信リポジトリには から到達可能な ocmmits が既にあると想定しているmasterため、コミットのみxがこのバンドルに配置されます。

D, E,Fが次の論理的なステップのように思えるかもしれません。のコミットに依存Fします。したがって、次の論理的なことは、 と一緒にバンドルすることです。私たちはまだ持っているので、私たちは言うことができますobrnach2branch2DmasterC

git bundle create 2.bundle master..branch2

、、およびをバンドルできるように、に移動masterする必要があります。私たちがオンであることを確認してくださいGEFGmaster

git reset --hard real_master~3
git bundle create 3.bundle ^branch2 ^master~3 master

ここで、古いメインライン履歴と履歴の両方に( でのマージを介して)branch2からアクセスできることに注意してください。ただし、両方とも既にバンドルされているため、両方を除外します。masterF

ついに、

git reset --hard real_master
git tag -d real_master
git bundle create 4.bundle master~3..master

実際には、おそらくバンドルごとに 3 つ以上のコミットを使用するでしょう。単独では大きすぎる側枝がある場合はmaster、この例でセグメント化に使用したのと同じ手法を使用して分割できます。

これで、これらを個別に転送し、それらからフェッチ (またはプル) して、反対側でレポを再構築できます。

アップデート

2 つの追加メモ:

まず、 と を使用するという ElpieKay の提案と比較するddとcat、上記のアプローチには長所と短所があります。

これは git 自体にのみ依存します (ただし、dd/catアプローチに必要なユーティリティは通常、git に同梱されています)。

個々のバンドル ファイルはそれぞれ単独で有用ですが、ファイルをセグメント化するdd場合は、使用可能なバンドルを確実に作成するためにすべてのパーツを再構築する必要があります。これは、バンドルを保存して、後で作成する追加のバンドルと組み合わせることができることも意味します (さらに変更が発生した場合)。ただし、その時点で別の新しいリモート リポジトリを最初から作成する必要がある場合にのみ問題になります。

実際には、双方がコミットの共通のベースラインをすでに持っている段階的な変更を行ったり来たりすることが、バンドルの基本的な使用例です。ddそのため、最初に/catアプローチを使用してリモート リポジトリを作成し、その後の更新の共有に増分バンドルを使用することを決定する場合があります。

dd/catアプローチの最大の利点は、上記のアプローチではコミットをどのように分割するかを考える必要があるのに対し、非常に単純でスクリプト化可能 (つまり、ツールが手元にあると仮定すると単純) であることです。また、このddアプローチは、1 つのコミットであることが判明した場合、1 つの不快なほど大きなコミットを分割する可能性があります。

また、最初に言い忘れていましたが、バンドルに含める複数のブランチをリストすることができます。たとえば、しきい値がバンドルあたり 8 件のコミットに近い場合、次のことができます。

1)masterに移動E

2) bundlemasterおよびbranch1as 0.bundle

3)master戻るJ

4) バンドルmasterをmaster~51.bundle として除外

そして行われます。

于 2017-11-08T14:19:02.020 に答える