共通のライブラリをgitサブモジュールとして共有するgitプロジェクトがあります。プロジェクトに変更を加えるときは、常にgitブランチを作成して作業を行います。テストして別の目を与えた後、ブランチをマスターにマージして、いつでもデプロイできるようにします。
サブモジュールライブラリにも変更を加える必要がある場合があります。ベストプラクティスは、最初にメインプロジェクトを分岐してから、サブモジュールに移動して分岐することですか？次に、使用されている他のプロジェクトで変更されたサブモジュールブランチをテストする必要があることに気付きました。これを行う別の方法はありますか？
サブモジュールを分岐するかどうか、それが問題ですが、それは完全にあなた次第です。サブモジュールがライブラリであり、他のプロジェクトがそれを使用している場合は、下位互換性を維持する必要があります。修正することはできますが、APIには触れないでください。しかし、libの修正は、実際にはlibのmasterブランチに属しています。したがって、メインプロジェクトを分岐するときに、サブモジュールを自動的に分岐する理由はわかりません。
技術的に重要なことは、サブモジュールとメインプロジェクトの両方を変更してコミットする場合は、最初にサブモジュールをプッシュし、次にメインプロジェクトをプッシュすることです。再帰的なプッシュのようなものはありません。
gitサブモジュールはそれ自体がプロジェクトです。したがって、サブモジュールを分岐するためのポリシーは、すべての分岐の決定と同じ考慮事項によって定義されます。サブモジュールの同時開発はありますか？マスターの履歴を汚さずに変更を巻き戻したいですか？はい、テストも考慮事項になる場合がありますが、他のプロジェクトで適切に再利用できることがサブモジュールの目標である必要があります。
共有サブモジュールを使用するプロジェクトがいくつかあります。このサブモジュールは、マルチブランチのメインプロジェクトで作業しているときに拡張されます。サブモジュールを分岐する必要があることはめったにありません。しかし、もちろんあることもあります。