web-dev-qa-db-ja.com

サブモジュールフォークの優れたワークフローは何ですか

Githubに次のリポジトリ構造があるとします。

company:project.git
  \- company:submodule.git

私の会社の開発者は会社のプロジェクトをフォークし、彼のワークスペースを次のようにしています。

developer:project.git
  \- company:submodule.git

サブモジュールライブラリを変更せず、プロジェクトでのみ機能するため、これは開発者の90％にとっては問題ありません。ここで、サブモジュールの改善が必要な新機能があるとします。これを担当する開発者は、自分のワークスペースを次のように変換します。

developer:project.git
   \- developer:submodule.git

サブモジュールを別のサブモジュールに置き換える必要があるため、そこに到達するのは簡単ではありません（gitにとって、サブモジュールの元のフォークとフォークは2つの異なるものです）。

この開発者がライブラリでもう少し長く作業する場合、彼はこの構造をマスターブランチにコミットするため、githubのフォークは常にフォークされたサブモジュールを使用します。

開発の準備ができたら、プルリクエストを作成します。問題は、プルリクエストをマージすると、メインリポジトリが次のようになることです。

company:project.git
   \- developer:submodule.git

これは問題があります。会社の支店を追跡するすべての開発者は、最終的に開発者のサブモジュールになってしまうからです。

この問題を回避するには、開発者がプルリクエストを行う前に、マスターブランチをcompany：submodule.gitに戻す必要があります。これは非常に厄介です。特にローカルでは常にdeveloper：submoduleを使用する必要があるためです。ギット。

いくつかのワークフローを試しましたが、まだ適切なワークフローがないのは上記の問題だけです。

gitgithubgit-submodules
41
Ivo Jansch

開発者が特定のバージョンのサブモジュールでコミットを作成するとき、それはスーパーモジュールがその正確なバージョンのサブモジュールで動作するという強力なステートメントです。彼のコードが実際に会社のバージョンのサブモジュールで機能する場合、開発者が次のことを行うのが正しいと思います。

  1. スーパーモジュールを分岐する
  2. サブモジュールで会社のバージョンをチェックアウトする
  3. 開発者がアップストリームバージョンから変更した場合は、スーパーモジュールの.gitmodulesを更新します
  4. その変更をステージングしてコミットする
  5. すべてをテストする
  6. プルリクエストを発行します

その後、スーパーモジュールで通常の開発ブランチに戻ることができます。

あなたの質問について私が理解していないことの1つは、次のとおりです。

サブモジュールを別のサブモジュールに置き換える必要があるため、そこに到達するのは簡単ではありません（gitにとって、サブモジュールの元のフォークとフォークは2つの異なるものです）。

それどころか、サブモジュールは、スーパーモジュールが指すコミットが含まれている限り、任意のgitリポジトリにすることができます。 2つの異なるリモートリポジトリがある場合、彼はサブモジュールにリモートを追加するだけです。 （開発者は、リポジトリを他の人と共有する場合は、.gitmodulesも変更する必要があります。）

以下のコメントに応えて、サブモジュールをあるバージョンから別のバージョンへと切り替える方法を検討する価値があるかもしれません。開発者がスーパーモジュールとサブモジュールに独自のリポジトリを使用しているが、それらは両方とも会社のバージョンから複製されており（つまり、ほとんどの履歴が同じである）、サブモジュールはパスlibにあると仮定します。 。開発者は、代わりに会社のバージョンを指すようにサブモジュールを切り替えたいと考えています。彼らは次のことができます：

  1. .gitmodulesのサブモジュールのurlパラメーターを編集して、会社のリポジトリーを指すようにします。
  2. cd lib
  3. git remote add company developer@company:/srv/git/lib.git
  4. git fetch company
  5. git checkout -b upstream-master company/master
  6. cd ..
  7. git add .gitmodules lib
  8. git commit -m "Switch the lib submodule to point back to the company's version"

リモートとブランチを設定したら、手順3〜5をgit checkout <whatever>に変更できます。

5
Mark Longair

もう1つの簡単な解決策は、.gitmodulesを無視し、追跡から削除するようにgitに指示することです。上記のように、.gitmodulesはサブモジュールの初期化にのみ使用されるため、サブモジュールをチェックアウトするときに一度だけ必要です。

3
Ernests Karlsons

彼がそれを開発するために、開発者はサブモジュール自体を変更する必要はありません-彼らは別のリモートを追加してそれにプッシュすることができます。

例：

developer:project.git
  \- company:submodule.git
        Origins: company/submodule.git
                 developer/submodule.git

ワークフロー：

cd path/to/submodule
git remote add developer git@gitserver/developer/submodule.git

//プロジェクトをハックする

cd path/to/submodule
git Push developer branchname

これは完全ではなく、開発者/サブモジュールが会社/サブモジュールに入る前に、開発者/プロジェクトのプルリクエストが会社/プロジェクトに入ると問題が発生する可能性があります。

私の簡単な考え。

2
Graham Christensen

ここで、サブモジュールの改善が必要な新機能があるとします。

サブモジュールで貢献が行われ、通常どおり、サブモジュールgitリポジトリでのコミットのみがプルリクエストされます。

サブモジュールフォークをプッシュするには、

  • プロジェクトの.gitmodules構成は、クローンフォークで変更できます（ただし、ユーザー側に保持されます）
  • または、サブモジュールフォークをリモートとして追加できます
0
jctout