これが私がサブモジュールを理解する方法です。特定の時点で状態全体を元に戻すことができるようにメインリポジトリに記録される状態(commit-id)を持つ独立したリポジトリ。
しかし、私がメインリポジトリにいる場合、過去のコミット(「デタッチされたHEAD」)またはブランチのチェックアウトは、対応するサブリポジトリの状態のチェックアウトにつながるべきではありませんか?
プロジェクトを元に戻しても、サブリポジトリの状態は変わりません。
どんな種類の助けにも感謝します!
これが私がサブモジュールを理解する方法です。特定の時点で状態全体を元に戻すことができるようにメインリポジトリに記録される状態(commit-id)を持つ独立したリポジトリ。
しかし、私がメインリポジトリにいる場合、過去のコミット(「デタッチされたHEAD」)またはブランチのチェックアウトは、対応するサブリポジトリの状態のチェックアウトにつながるべきではありませんか?
プロジェクトを元に戻しても、サブリポジトリの状態は変わりません。
どんな種類の助けにも感謝します!
論理的には、メインリポジトリで行うのと同時にサブモジュールでチェックアウトされたリビジョンを切り替えることgit checkout
は、多くの場合意味があります。ただし、それを望まない場合もあります。そのため(そしておそらく他の理由で)、git
開発者はそれをの自動部分にしないことを選択しましたgit checkout
。代わりに、2段階のプロセスがあり、実行git checkout <something>
してgit submodule update
から、すべてのサブモジュールを現在チェックアウトされているメインリビジョンに調整します。習慣を身につけるまでは少し面倒ですが、サブモジュールを毎回更新するというパフォーマンスの負担を追加することなく、レビューのためにさまざまなリビジョンをチェックアウトできます。これは、多くのサブモジュールを含む大規模なプロジェクトで重要になる可能性があります。