私は、私たちの製品のソースコードをさまざまなGitリポジトリにまとめています。 （そして、私はGitを初めて使っています）。それらの中には、サブモジュールを介して同じサーバー上の他のリポジトリを使用するものもあります。私はそれを理解したようGitサブモジュールが別のサーバーに移動する場合はどうすればいいですか？
は、Gitの中にサブモジュールは、特定のポインタが別のリポジトリにコミットされ、によって定義されます：リモートサブモジュールの
- URL（例えばgitの：//foo.com/git /lib.git）
- （にサブモジュールのリポジトリを複製するサブディレクトリには、例えば/ fooのを含める）
- IDをコミットし、我々は
を参照している問題は、URLがバインであるということですgサブモジュールが追加されたときにコミットの一部としてリポジトリに格納されます。 URLが変わるとどうなりますか？親リポジトリには何百ものコミットがあります。すべてがサブモジュールで古いURLを参照しています。
例えば、リポジトリSuperとSubをgit：// PrivateCompanyServer/repositories/*に格納するとします。 Superはgitmodulesファイル（git：//PrivateCompanyServer/repositories/Sub.git）を介してSubを参照します。いくつかの開発者は何百にも及ぶコミットを行います。スーパーのコミットのたびにそのURLを持つgitmodulesのスナップショットがあります。いくつかの製品リリースにはタグが付けられ、すべての種類のブランチにはgitmodulesのURLがあります。ここで、PrivateCompanyServerがクラッシュし、コードを別のサーバーに移動したとします。または、PrivateCompanyServerのディレクトリ構造を再編成します。または何でも。これで、もう存在しない古いURLのSubリポジトリを参照して、Superに何百ものコミットがあります。明らかに、gitmodulesファイルは開発ブランチの頭で修正することができ、そこで移動することができます。しかし、メンテナンスのために元に戻す必要があるすべての種類の古いコミットがあり、それらはすべて、もはや動作しなくなる古いURLを参照します。それをどう扱うか？
明らかにこれはリポジトリ内のすべてのgitmodulesファイルに新しいURLがあるようにrebase/"rewriting history"で解決できますが、これはオプションではないと思います。 Superをサブモジュールとローカルの開発者リポジトリとして使用する「Super-Super」プロジェクトを含む、Superを参照するすべてのものはすべて破損しますか？
これを処理するにはどうすればよいですか？ リポジトリのコレクションを非公開会社のサーバーに保存する場合 - サブモジュールを介して他のリポジトリを参照するもの - サーバーが名前を変更したときに何をしますか？ - gitmodulesファイルの古いURLを無効にしますか？
私が考えることができる唯一の回避策は、訂正されたgitmodulesを保持するために、履歴内のすべてのコミット方法から「たくさんの枝」を作ることです。そのように見えるのは混乱を招き、扱いにくいでしょう。より良い方法が必要であるように思える - 確かに私は何かを欠いている？
Googleでgit submodule syncを検索すると、この便利な質問が追加情報を追加して見つかりました。http：// stackoverflow。com/questions/913701/change-remote-repository-for-a-git-submodule .....正しいパスを私に指摘してくれてありがとう！ –