gitのサブモジュールの向き先URLを変更したい

状況・試したこと

gitのサーバを引っ越ししようとしています。
扱っているリポジトリにはサブモジュールが含まれており、親リポジトリ・サブモジュールとなる子リポジトリともにサーバAからサーバBに引っ越しする形となります。
リポジトリ単位で引っ越しするので、サブモジュールの向き先は親リポジトリのどのブランチからでもサーバBの子リポジトリを見れるようにする必要があります。

サーバBへのリポジトリ複製は済んでおり、親子ともにcloneはできる状態です。
また、親に含まれているサブモジュールの向き先をサーバBへ変更するため、masterブランチにて「.gitmodulesのURL値を変更してcommit/push」してあります。

[submodule "サブモジュール名"]
	path = サブモジュールのパス
	url = サーバB #←ここを変更しました
	branch = ブランチ名

更に「git submodule sync」コマンドを実行すると、どのブランチからでもサーバBを向いてくれるようになりました。

一通り、望む挙動をしてくれているようには見えます。

困っていること・質問

当然ながら、上記の方法だとmaster以外のブランチに含まれる「.gitmodules」のURL値が古いままです。
それでも挙動は問題ないように見えるのですが、気持ち悪いので（＋もしかすると弊害もあるかもしれないので）できれば全ブランチに反映させたいです。
こういう場合、地道に各ブランチにcommitしていくしかないのでしょうか？

<追記>
過去の状態をチェックアウトしたくなることもあり、そこからもサーバBを向いていることが望ましいので、git rebaseで全commitを修正することも検討中です。
「どのブランチの先頭をチェックアウトしても.gitmodules内のURL向き先がサーバBである状態」で妥協してもいいので、その場合は上記の「地道に各ブランチにcommit」になるのかな、と考えています。
</追記>

また、そもそもサブモジュールを持つリポジトリの引っ越しとして、方法が適切でない場合はご指摘いただけますとありがたいです。

（追記）結論

ベストアンサーとさせていただいた通り、cherry-pickを利用して各ブランチに反映することで解決といたしました。
（少人数PJでの運用なのですが：過去の状態を見たいことはやはりあるのでrebaseしたくはありましたが、過去の状態を見るといっても各自ローカルでの作業に収まりますし、その時は各自適切にやってくれ…という話に落ち着きました）
お二方とも、ありがとうございました。

hoshi-takanori

2020/02/14 06:19

「各ブランチにcommit」が「作業中の各ブランチの先頭で変更」という意味なら、その通りだと思います。もっとも、普通に各ブランチで変更するとマージの際に衝突する可能性があるので、master などの一箇所で修正したものを各ブランチにマージするのが一般的だと思いますが。なお、通常の git の作業フローでは、作業が終わったブランチは master などにマージしたら削除して構わないので、修正が必要になるブランチはそんなに多くないと思います。（が、もしかして過去の commit を全部修正したいという意味でしょうか？）

takushi168

2020/02/14 07:33

ありがとうございます！「どのブランチの先頭をチェックアウトしても.gitmodules内のURL向き先がサーバBである状態にしたい」という感じです。それを実現するためには「作業中の各ブランチの先頭で変更」しなければならない、ということであれば各ブランチを修正（それぞれ変更なりマージなり）していく、という形になるのですね。 …とはいえ本当は > 過去の commit を全部修正したいがベストです…。過去のコミットの状態をチェックアウトしたくなることもあり、できればそこからもサーバBを向いていて欲しいところですが、それらについては妥協してよいかなと思っています。運用上、必ずmasterにマージしているわけではないため、主だったブランチにはそれぞれ反映しなければならなさそうです。（ちょっと特殊な運用なのでしょうかね？あるWEBアプリを複数のサーバに置いて動かしているのですが、サーバごとにちょっとずつ仕様が異なるためにそれぞれにmaster的ブランチが存在し、それ自体を互いにマージすることはない…というイメージです）

hoshi-takanori

2020/02/14 07:40

「各ブランチにcommit」が「互いにマージする予定のない複数のmaster的ブランチ」のことであれば、各ブランチに独立してそれぞれcommitで良いと思います。あと、引越しならgit rebaseして全commit修正してもいいかも知れませんね。失敗してもやり直せばいいですから。

takushi168

2020/02/14 07:49

rebase！ありがとうございます、使ったことがなくすっかり忘れていました…。丸ごと引っ越しですしこちらのほうが適切…な気もします。併せて検討してみます！

行動規範の内容に同意します

回答1件

ベストアンサー

要望を真に実現するには指摘がすでにあるようにrebaseするよりほかありませんが、私としてはするべきでないと考えます。

過去のコミットの状態をチェックアウトしたくなることもあり

というのがそもそもおかしな話で、それならその地点に新たにbranchを作っておくべきです。

チェックアウトする可能性があるcommitはそれを指すbranchを用意するのがgitのあるべき利用法だと考えます。

そうすると話はよりシンプルになり、各branchに当該commitをcherry-pickすればいいことになります。

投稿2020/02/17 01:48

yumetodo

総合スコア5852

takushi168

2020/02/17 04:04

ありがとうございます。 master以外のbranchや過去のcommitをチェックアウトしようとするとその時点の.gitmoduleが古いためにサブモジュールの数だけ古いサーバ側の認証を求められてしまうのが鬱陶しく、それならあらかじめ全commitの.gitmoduleを更新できていれば楽なのにな…というワガママでした。 > 過去のコミットの状態をチェックアウト（というのは大抵「この時点ではどういう挙動をするんだっけ？」くらいの軽い気持ちでローカルで確認するために落としてくる用途だったりするのですが、それはともかくとして）その時点のコミットからブランチを分けてそれをチェックアウトする？のが適切、という感じでしょうか。となると、・引っ越し後、masterの.gitmodulesを新しいものに更新してcommit（コミットA）・利用する各branchにコミットAをcherry-pickする　※古いcommitなどを参照したい場合はそこからbranchを切って、これも同様にコミットAをcherry-pickするという形ですね。なんとかして手作業or適切なブランチを作って全ブランチにマージするのは大変そう…と考えていたので、cherry-pickという手段を知れてよかったです。ありがとうございます！