1

私たちのチームには、会社のファイアウォールの背後にある既存のリモート リポジトリ R1 があり、ディレクトリ構造は次のとおりです。

A\      <<------------- root of the repository R1, where "make project" is done;
  .git\
  B\
  C\
    CC1\
    CC2\
        CCC1\
        CCC2\       <<------------ share with vendor for code collaboration;
        CCC3\       <<------------ share with vendor for code collaboration;
        CCC4\       <<------------ share with vendor for code collaboration;
        CCC5\
    CC3\
  D\
  E\

ソースの上記の 3 つのサブディレクトリ、CCC2、CCC3、および CCC4 を含むプロジェクトで協力するために、ファイアウォールの外側にあるベンダーとのプロジェクトがあります。ベンダーと私は、コードの共有とコードの更新に git を使用したいと考えています。そして、これら 3 つのサブディレクトリでコードのプライベート リモート リポジトリをホストするために Bitbucket を使用することに同意しました。

git を使用したさまざまなアプローチを読んで、ネストされた git、git サブモジュール、および git サブツリーに出くわしました。しかし、私が使用しているのはどちらでもなく、手動のマージを含む大雑把な方法です。つまり、ソース ツリーを使用して Bitbucket にリモート リポジトリ R2 を作成しました。

ZZZ\         <<------------ root of the repository R2;
    .git\
    CCC2\
    CCC3\
    CCC4\

そして、2 つのローカル リポジトリがあり、1 つは R1 を追跡し、もう 1 つは R2 を追跡します。次に、ワークフローは、最初に git pull を実行し、次に 2 つのローカル リポジトリ間で手動/手動マージを実行し、必要な git push を R1 と R2 に実行して、互いのレポの変更を他方に表示することです。はい、粗雑です。

私が持っている質問は、より良い、より簡単なアプローチはありますか? チームは、サブモジュール機能を使用するために必要なものに関するすべての調査に基づいて、git サブモジュールに依存しないことに同意しました。また、ネストされた git の使用は好ましくありません。そのため、git サブツリーを調査する必要があります。サブツリーでの現在の試行は期待どおりに機能していないため、まだ学習中です。

また、R1 のアウトラインを作成するスパース チェックアウトについても調べましたが、CCC2、CCC3、および CCC4 のみがチェックアウトされています。それはうまくいくようです。しかし、それを Bitbucket リポジトリ R2 にプッシュすると、R2 には R1 からのすべてのソースが読み込まれます。それで、何かが正しく行われませんでした。

理想的には、R1 と R2 のリモート リポジトリ間で多かれ少なかれ透過的なプル/プッシュが必要です。つまり、R1 には「vendor-work」と呼ばれるブランチがあり、ベンダー コードの変更を R2 からそのブランチにプル (マージ) し、テストし、必要に応じてプロジェクトのメイン/マスター ブランチにマージするために使用されます。 . 同じように、R2 には「company-work」と呼ばれるブランチがあり、ベンダーの作業ブランチへのプルを受け入れる前に、ベンダーが確認したいプル リクエストがあります。リポジトリ R2 の履歴を R1 にマージする必要があるかどうかについてはまだ考えていませんが、現在の考えでは、おそらく 2 つのリポジトリ履歴を 1 つにマージして、それらを分離したままにしたくないでしょう。

どうもありがとう。

4

1 に答える 1