考え方をgitに変更する方法を理解するのに苦労しており、次の問題に遭遇しました。共有エンジンと、そのエンジンを使用する複数のプロジェクトがある状況があります。内部開発チームとセカンド パーティ チームは、共有エンジンを使用するプロジェクトに取り組んでおり、共有エンジンがタグ付けされる出荷のわずか数週間前まで、開発中に共有エンジンの HEAD を可能な限り使用したいと考えている場合があります。そして分岐し、プロジェクトはその分岐を使用します。プロジェクト チームは、通常、一度に 1 つのプロジェクトだけに取り組みますが、デバッグ中に共有エンジンに変更を加えたり、機能を追加したりする場合があります。それらの変更をコミットすると、ビルド システムが実行され、コミットによって発生した可能性のある問題が検出されます。
私は（私が思うに）この同じモデルを新しいプロジェクト/新しい会社で使いたいと思っています。svn では、構造は次のようなものでした: shared_engine
project_in_dev-+
+- svn:external shared_engine:head
project_about_to_ship-+
+-svn:external shared_engine_rev1_branch
これは非常にうまくいきました：
- プロジェクト開発者は、1 つのコマンドを実行して、必要なすべての依存関係をチェックアウトできます。
- プロジェクト開発者はエンジン作業を行い、共有エンジンに簡単にコミットできます
- プロジェクトが使用していた共有エンジンを外部とリビジョンで簡単に改訂または変更できました
- エンジンの更新は、毎日の「ルート プロジェクトからの更新」で簡単に入手できました。
OK、今は git に移行しました。サブモジュールは外部コードを処理する新しい方法のようですが、いくつかの機能が失われているようです。
- プロジェクトのすべての依存関係を実際に取得するのは、複数のステップのプロセスです。プロジェクト開発者は git clone を実行してから、git submodule init/git submodule update --recursive を実行する必要があります
- ルート プロジェクトとサブモジュールを更新するのは複数のステップ プロセスであるため、サブモジュールへの変更と一致する変更が別の開発者によってルート プロジェクトに加えられた場合、一致するコードがすぐに取得されず、非常に混乱する可能性があります。
- サブモジュールは特定のコミットにロックされており、サブモジュールに変更を加えると、共有エンジンのヘッドで動作させるのに問題が発生します
- プロジェクト開発者がチェックアウトした共有エンジンのリビジョンを制御することはできません。何を更新するかを指示する必要はありません。
だから私の質問は次のとおりです：
- 何よりもまず、サブモジュールに関する上記の仮定は正しいですか? 私が読んだものに基づいているようですが、まだgitを理解しているので、100％確実ではありません
- 私の仮定が正しければ、正しいプロセスで問題に取り組んでいますか? git を使用する場合、考え方を再調整する必要がありますか? 言い換えれば、私がやろうとしていることを実行する別の方法があり、プロセスについて別の方法で考える必要がありますか?
- 私が最初の 2 つを吹き飛ばしておらず、サブモジュールが私が望むことをしないと仮定すると、どうなるでしょうか? サブツリーのマージについて読みましたが、共有コードに加えられた変更をリポジトリに戻すことができないように見えるため、それらも正確には正しくないようです。
あなたの助けと忍耐に感謝します。それが明らかでない場合、私は git に非常に慣れていません。私はそれが好きで、受け入れたいと思っています。学びたい！また、私は一日中 rtfm'ing を行っており、さまざまなブログの投稿、stackoverflow の質問などを見ていますが、まだ理解できません。これについて質問できる同僚はいません。シアトル地域に git グルがいる可能性のあるユーザー グループはありますか? :)