11

私は git サブツリー拡張 ( https://github.com/apenwarr/git-subtree ) を使用しています。「--squash」を使用して、メイン プロジェクトのログをきれいにします。手順は次のとおりです。

  1. ライブラリをメイン プロジェクトに追加する

    git subtree add -P sub/libdir --squash lib_remote master

  2. lib からアップデートを取得する

    git subtree pull -P sub/libdir --squash lib_remote マスター

  3. 変更を lib_remote にプッシュする

    git サブツリー プッシュ -P サブ/libdir --squash lib_remote マスター

それは私にとって非常にうまく機能します（メインプロジェクトとライブラリの両方で、歴史が理にかなっています）。問題は git subtree push の時間がどんどん長くなってしまうことです。

git-subtree を使用する私の目的は、git-subtree は履歴を保持していないため、サブツリーの変更をプッシュできないと尋ねた Screndib とほぼ同じ です。今後、これを修正/回避するにはどうすればよいですか?

--squash を使用する場合、 push を処理するたびに、git subtree は「サブツリーの追加」以降の履歴全体を検索する必要があると思います。

サブツリーのプッシュ時間を短縮するにはどうすればよいですか? または、履歴全体ではなく、最後のgitサブツリーのプッシュ（またはプル）以降の変更のみを処理して、より効果的に機能させますか？

4

2 に答える 2

5

あなたのコードの「lib_remote」は、現在のリポジトリのブランチではなく、リモートの lib リポジトリの URL であると思いますか? 現在のリポジトリのリモート リポジトリ URL とブランチの両方が機能しています。

git subtree addリモートライブラリをサブツリーとして追加するために使用していたのにgit subtree push、変更をプッシュするために使用していたようです。

git subtree splitプッシュ操作の前に、サブツリーの変更を現在のリポジトリの別のブランチに分割する操作を実行してから、分割されたブランチをリモート リポジトリにプッシュし、この分割されたブランチが存在したままにしておくことをお勧めしgit subtree splitます。繰り返しますが、これにより、最後に分割したポイントからサブツリーの履歴が作成され、はるかに高速になります。そうしないと、あなたのようにこの分割がなければ、git subtreee は追加した時点からサブツリーの履歴を構築する必要があります。サブツリーが成長をコミットしている限り、構築の時間はますます長くなります。

--squash追加中に使用しない場合は--rejoin、分割中に使用することを検討できます。これにより、はるかに高速になります。

したがって、手順は次のようになります。

  1. ライブラリをメインプロジェクトに追加

    git subtree add -P sub/libdir --squash lib_remote_url master

  2. lib からアップデートを取得する

    git サブツリー プル -P サブ/libdir --squash lib_remote_url マスター

  3. サブツリーの変更を別のブランチに分割します

    git サブツリー分割 -P サブ/libdir -b lib_remote_branch

  4. 変更を lib_remote にプッシュする

    git push lib_remote_url lib_remote_branch:master

lib_remote_branch は存在したままにし、次回のプッシュ時に手順 3 と手順 4 をやり直します。

于 2012-03-09T12:52:49.080 に答える