1

Git で管理されている、プロジェクトの未完成の機能のトピック ブランチを作成する作業に取り掛かりました。それらはすべて、1 つのトピック ブランチが別のトピック ブランチに直接関係しないように、非常に自己完結型です。ただし、すべてのブランチにはシステムのコアであるマスター ブランチという共通点があり、トピック ブランチはマスター ブランチの機能を拡張するだけです。

私が正しく理解していれば、マスター ブランチでトピック ブランチに影響を与える何かを行った場合 (たとえば、コアと個々の機能の間の通信に使用される API を変更するなど)、その変更はトピック ブランチに反映されません。自動的に、ブランチがそれに応じて修正されるようにします。変更は手動でマージするか、他のブランチにチェリー ピックする必要があります。

サブモジュールを使用するとこれが達成されることを理解しています。ただし、サブモジュールを使用すると、主に機能が自立していないため、メイン プロジェクトと機能プロジェクトになる可能性があるプロジェクトとの間の分離が大きくなりすぎます。彼らはコアに依存しています。

したがって、私が探しているのは、特定のファイル/ディレクトリが特定のブランチに固有のものであり、それ以外はすべてメインブランチからのものであると言う何らかの方法です。Photoshop の用語で言えば、マスターを背景レイヤーにして、各トピック ブランチをその上に部分的に透明なイメージ レイヤーにし、独自のコンテンツを配置します。

4

2 に答える 2

1

「構成」または「構成の継承」という概念は、「柔軟な分岐と静的分岐」の質問で説明されているように、Git ではサポートされていません。必要なファイルの正確なセットを「作成」できるのは、マージのみです。

サブモジュール機能は、独自のライフ サイクルを持ち、独自のペースでタグ付けする必要がある一貫したファイル セットを識別するのに役立ちます。それはあなたの機能の場合ではありません。

あなたのアプローチは、すべてのシステムを開発、タグ付け、およびマージする「システムベース」のアプローチのままにする必要があります。master ブランチで何かが進化した場合は、feature ブランチでマージする必要があります。
機能に、master ブランチで変更された別のファイル セットが含まれている場合、そのマージは簡単です。そうでない場合は、mateusza の提案に従い、中間ブランチを使用して競合を解決し、そのようなマージの結果を評価しながら、機能ブランチをそのままにしておくことができます。

于 2009-05-31T21:07:49.000 に答える
0

ブランチ マスターと多数のブランチがあるとします: feature1、feature2、feature3...

$ git checkout feature1
$ git branch master-with-feature1
$ git checkout master-with-feature1
$ git merge master

masterまたはfeature1に変更を加えるたびに、 master-with-feature1 にチェックアウトしてそれらをマージできます。

于 2009-05-31T18:42:45.407 に答える