Ich habe Bibliotheken A, B, C und D.Teilen Git Submodule
die Abhängigkeiten aussehen so:
A
|
/\
B C
\ /
D
wir jedoch die B- und C-git repos haben mit D als ein einrichten Submodul. wir würden gerne B und C als Submodule in A einrichten, aber wir möchten auch, dass sie beide auf eine einzelne Submodulinstanz von D zeigen.
Kennt jemand den richtigen Weg, dies zu tun?
Wenn Sie B und C als Submodule zu A hinzufügen, werden ihre .git-Dateien in A unter .git/modules/B und .git/modules/C gespeichert. Jedes von ihnen (sobald Sie git submodule init; git submodule update in jedem getan haben) wird seine eigenen .git/modules/D haben, so dass die Repo-Dateien nicht geteilt werden. Jeder hat seine eigene ausgecheckte Kopie der Dateien.
Sie könnten diese Probleme mit Symlinks umgehen. Zum Beispiel könnten Sie D als Submodul nur zu B hinzufügen und dann Bs D in C verknüpfen. Jetzt können Sie entweder mit B/D oder C/D arbeiten, und der andere bleibt synchron. Es gibt jedoch 2 Probleme damit. Das erste ist, dass Sie nicht verschiedene Punkte in jedem auschecken können - sie müssen synchron bleiben, weil sie das Gleiche sind. Dies ist jedoch geringfügig und kann sogar Ihren Wünschen entsprechen. Die zweite ist schlimmer; Wenn du D nur in B verfolgst und C es nur über einen Symlink zu Bs "trackst" (Symlinks sind von git, btw verstanden), dann hat C keine Möglichkeit, seine eigene Abhängigkeit von D. zu regeln.
Es ist normal, eine Änderung an einem Submodul vorzunehmen und dann diese Änderung in der abhängigen, Repo zu überprüfen, aber jetzt müssen Sie daran denken, in die andere Repo in der Raute springen und stellen Sie sicher es funktioniert auch (automatisiert Tests - vor allem wenn sie durch einen Git Haken geführt werden - können hier sehr hilfreich sein. Wenn Sie einen Commit in B/D rückgängig machen, z. B. einen älteren auschecken oder in B/D verzweigen, müssen Sie immer zu C/D wechseln und sicherstellen, dass die Dinge dort immer noch funktionieren. Dieser Aufbau kann ein bisschen Mikromanagement-Schmerz werden, anfällig für gebrochene Commits, wobei B gegen den aktuellen D arbeitet, aber C nicht, oder umgekehrt.