Hi,
wir verwenden Git und auch Submodule.
Wenn du Änderungen innerhalb der Submodule vornimmst, dann musst du zwei Commits machen, das ist korrekt. Und auch richtig so. Denn ein Submodul ist immer über einen bestimmten Commit in sein Eltern-Repository eingebunden. Beim Clone deines Projekts ist in Git also nicht nur gespeichert,
welches Submodul benötigt wird, sondern auch welcher Commit des Moduls.
Solltest du eine Änderung am Modul vornehmen wollen, so musst du mehrere Schritt machen. Zuerst machst du ein Checkout (Branchwechsel) Im Submodul. Submodule sind standardmäßig in keinem Branch sondern checken den Commit direkt aus. Dann machst du deine Änderung und commitest sie in das Submodul. Ein neuer Commit-Hash entsteht. Zuletzt gehtst du wieder in das Eltern-Repository (dein Hauptprojekt) und musst (kannst!) dort die neue Version des Submoduls bekannt machen. Du fügst also via
git add das Modul der Staging Area hinzu und commitest dann. Wir schreiben meist nur "neue Lib" als Commit-Message.
Da alle anderen Projektrepositories ja auch an einen Commit gebunden sind, erhalten diese die Ändeurngen nicht sofort. Du hast hier also die Möglichkeit, Änderungen erst zu testen. Wenn die Ändernungen getestet und stabil sind, gehst du bei allen anderen Repositories genauso vor. Checkout im Submodule, Add, Commit, Push.
Solche Änderungen sind bei uns nicht so häufig und der Aufwand zur Verwaltung ist auf jeden Fall gerechtfertigt. Wir haben nunmal solche Abhängigkeiten und diese verwalten sich einfach nicht von selbst. Änderungen die wir in den Hauptrepositories vornehmen sind von von Submodulen vollkommen unabhängig und benötigen kein weitere Beachtung dieser. Du editierst, addest, committest und pushst wie üblich.
Hoffe das hilft dir weiter?
