Wie stellt git Submodule

Question

Das Szenario

Wir haben ein großes Projekt mit vielen Teilprojekten in Unterverzeichnissen und Abhängigkeiten. Wir planen, einen Teil des Projekts auszulagern.

Unsere Projektstruktur ist wie dieser (Text sind Unterordner Namen):

MAIN 
|_Custom 
| |_Source 
| | |_CustA (Contains multiple projects each in own directory) 
| | |_CustB (Contains multiple projects each in own directory) 
| | 
| |_Dll 
| | |_Debug 
| | |_Release 
| | 
| |_Lib 
|  |_Debug 
|  |_Release 
| 
|_Dll 
| |_Debug 
| |_Release 
| 
|_Lib 
| |_Debug 
| |_Release 
| 
|_Plugins 
| |_Dll 
| | |_Debug 
| | |_Release 
| | 
| |_Source 
|  |_PluginA 
|  |_PluginB 
| 
|_Source 
    |_Module1 
    | |_M1A 
    | |_M1B 
    | 
    |_Module2 
     |_M2A 

Wie ich bereits erwähnt, die ‚Benutzerdefiniert‘ Teil ist das, was wir auslagern möchten. Diese benutzerdefinierten Projekte hängen von den dll- und lib-Dateien in den Ordnern Main/Custom/Dll, Main/Custom/Lib, Main/Dll, Main/Lib und Main/Plugins/Dll ab. Das Problem hierbei ist, dass unabhängig vom Root-Laufwerk die Ordner Main/Dll-Lib und Main/Plugins/Dll dieselbe Hierarchie und Position innerhalb des Hauptordners beibehalten müssen.

Angenommen, CustA hat ein Projekt, das von einer DLL aus dem Main abhängt. Alle Projekte unter CustA müssen die Ausgabepfade zwingend so setzen, dass die exe und dll Dateien zu Main/Custom/Dll und lib Outputs zu Main/Custom/Lib gehen. Diese exe (angenommen, es befindet sich in Release) muss unbedingt nach der referenzierten Hauptdll suchen, die den relativen Pfad "...... \ Dll \ Release" verwendet, der auf den Main/Dll/Release-Ordner und ähnlich für jede Hauptdatei verweist -plugin dlls. Es kann die DLL oder die lib nicht von irgendeinem anderen willkürlich eingestellten Pfad referenzieren.

Die Anforderung:

Als Haupt von unseren eigenen Leuten geklont werden soll, müssen sie alle Quell- und DLLs und Dateien unter Haupt bekommen. Für Custom müssen jedoch die Ordner Main/Custom/Source, Main/Custom/Dll und Main/Custom/Lib erstellt werden (sie können eine leere Datei enthalten, falls git keine leeren Ordner zulässt.), Aber die spezifischen benutzerdefinierten Module (wie CustA und seine Unterverzeichnisse und seine Ausgabe exe, dll & lib-Dateien) dürfen nicht geklont werden. Die benutzerdefinierten Module (CustA, CustB, CustC ...) müssen bei Bedarf einzeln im Ordner "Main/Custom/Source" gezogen/geklont werden, um ihren Quellcode zu erhalten, und um ihre exe-dll-lib-Dateien zu erhalten .

Auf der anderen Seite, wenn Outsourcing, muss es leicht sein, an ihrem Ende auch einzurichten. Hier sollten sie in der Lage sein, den Main so zu klonen, dass sie die Ordner Main/Dll, Main/Lib und Main/Plugins/Dll und ihren Inhalt exe-dll-lib und andere Ausgabedateien erhalten, aber nicht die Quelle Code innerhalb von Main/Source und Main/Plugins/Source. Da der Outsourcer pro Custom-Modul ausgeführt wird, vorausgesetzt, dass diesem Entwickler CustA zugewiesen wurde, muss er leicht den Quellcode für alle Projekte unter CustA abrufen können, aber nicht in der Lage sein, Clone/Pull Custom/Quelle/CustB.

Was habe ich schon versucht:

Die ganze Haupt und alles in ihm derzeit zu einem SVN-Repository auf unserem eigenen Server-Rechner gesichert. Aber wir wollen nach git migrieren, und verwenden Nulabs-Rückstand für Projektverfolgung und -verwaltung.

Ich habe etwas recherchiert und eine Kopie unserer Projektstruktur mit Dummy-Dateien erstellt und war in der Lage, ein Test-Repo mit allen (ich meine ALL) die Dateien und Unterordner zu erstellen, aber das erlaubte nicht den eingeschränkten Zugriff wie ich erwähnt habe über.

Ich verstehe, dass ich das gesamte Projekt in mehrere kleinere Repositories partitionieren kann und dann die git Submodul-Funktion verwenden, um bestimmte Repositories unter anderen Repos zu referenzieren.So habe ich separate Repositories von Main/Plugins/Source, Main/Source und für die Custom Module jeweils eigene Repositories für Main/Custom/Source/CustA, Main/Custom/Source/CustB, Main/Custom/Source/CustC etc und lade sie auf die Fernbedienung hoch. Dann habe ich ein Repository für den Hauptordner selbst erstellt und die Main/Dll-, Main/Lib-, Main/Plugins/Dll-Ordner hinzugefügt. Hier erscheinen die #/Source-Module als Untermodule, die auf den ersten Blick OK erscheinen. Wenn ich dieses Hauptrepo auf die Fernbedienung drücke, zeigt die Fernbedienung auch an, dass CustA, CustB ..., Main/Source, Main/Plugins/Source usw. Untermodule sind, während die Dll- und Lib-Ordner die korrekten Dateien anzeigen.

Aber ich kann nicht verstehen, wie man diese richtig klont.

Das Problem:

Als ich Haupt Repo von entfernten klonen, wird das Klonen das auslagern Szenario neu, wo die Quellordner enthalten nichts, als sie Submodule sind, während die DLL und Lib Ordner richtig bevölkerten . Aber wenn ich versuche, die Main/Source oder Main/Plugins/Source Ordner explizit zu ziehen, funktioniert es nicht. Weder erlaubt es mir nicht, den Remote-Pfad der Quellordner festzulegen, da diese Ordner selbst Teil des Hauptrepos sind, noch erlaubt es mir, einen Pull auszuführen, wenn ich diese leeren Quellordner lösche und sie dann neu erstellen und deren festlegen Remote-Pfad, um die tatsächliche Repo-URL des Sub-Moduls widerzuspiegeln.

Ist die Partitionierung, die ich falsch gemacht habe? Oder ist der Klonschritt falsch? Wenn ja, wie kann ich git richtig einrichten, um die oben genannten Anforderungen zu erfüllen?

Answer 1

Endlich gelang es mir, Dinge mit viel Googeln und anderen Ideen zu finden, die ich auf SO selbst fand.

Ich ging mit einem einfachen einfachen Git-Arbeitsbaum. Grundsätzlich partitionierte ich die gesamte Projektstruktur in 3 Teile.

Teil 1: Speichert die eigentliche Ordner-Unterordner-Struktur sowie die Dlls, pdb, lib und Header-Dateien. Diese Dateien sind sowohl für die Entwicklung des 'Custom' Teils als auch für die 'Main' Anwendung selbst notwendig. Somit ermöglicht dieser Repo Zugang sowohl zu unserem lokalen Team als auch zu dem ausgelagerten Team.

Teil 2: Speichert den eigentlichen Code (cpp) und csproj, sln und zugehörige Dateien im Zusammenhang mit der Entwicklung der 'Main'-Anwendung. Dieses Repo ermöglicht den Zugriff nur auf unser eigenes lokales Team.

Teil 3: Speichert die 'Custom' Module. Diese Module sind unterteilt, jedes Modul (CustA, CustB, CustC ...) zu seinem eigenen Repo. Unser lokales Team hat Zugriff auf alle diese Repos. Das ausgelagerte Team hat nur Zugriff auf den Repo, der das ihm zugewiesene Modul enthält.

Jedes dieser Repos hat bereits einen Master und einen 'Develop'-Zweig. Die eigentliche Entwicklung wird in einem benutzerdefinierten Zweig ausgeführt, der vom Zweig 'Entwickeln' abgeleitet und bei der vollständigen Ausführung zusammengeführt wird. Der 'Develop'-Zweig wird bei jedem Release mit dem Master synchronisiert, so dass der Master-Zweig immer nur stabilen' Release'-Code enthält.

Ich habe 2 einfache Bash-Skripte geschrieben, um eine einfache Einrichtung des Entwicklungs-Repos zu ermöglichen.

Das Skript für das lokale Team fragt nach einem Stammordner, dem Namen eines benutzerdefinierten Moduls (wenn ein benutzerdefiniertes Modul entwickelt wird) und einer URL für ein benutzerdefiniertes Modul-Repo (wenn ein benutzerdefiniertes Modul entwickelt wird). Dann erstellt es ein leeres Git-Repo auf dem lokalen Rechner, auf dem es ausgeführt wird, zieht das 'Teil 1'-Repo, wie es für alle Entwicklungsszenarien notwendig ist, fährt mit dem Ziehen des' Teil 2'-Repos in die richtigen Ordner fort. Wenn ein benutzerdefinierter Modulname und eine benutzerdefinierte URL angegeben werden, wird mit dem entsprechenden Repo von "Teil 3" fortgefahren. Als nächstes wird das 'Teil 1' Repo nicht generell geändert, um versehentliche Commits oder Pushes zu verhindern, navigiert das Skript zu seinem Stammordner und benennt das '.git' in etwas anderes um, so dass der Repo von Teil 1 wie ein Repo nicht mehr. Wenn Sie diesen Repo ändern oder aktualisieren müssen, müssen Sie den Ordner explizit wieder in '.git' Pull/Sync umbenennen, um ihn auf die neueste Version zu bringen, und dann die Änderungen vornehmen und drücken. Natürlich gibt es einen kleinen Haken, dass wir nach dem Abschluss daran denken müssen, den .git-Ordner in etwas anderes umzubenennen und dafür zu sorgen, dass die richtigen Header-Dateien nach Teil 1 geschoben werden, während der Code an ihn weitergegeben wird Teil 2.

Der 'Teil 2'-Repo und alle' Teil 3'-Repos werden automatisch in den 'Develop'-Zweig geschaltet, und der Master-Zweig wird vom lokalen Rechner gelöscht. Natürlich wird der Master-Zweig immer dann zurückgebracht, wenn wir mit der Fernbedienung synchronisieren.

Im Falle eines Outsource-Teams wird das Skript den 'Part 2' Repo nicht ausführen. Es wird speziell nach einem Stammordner und einem benutzerdefinierten Modulnamen und einer URL gefragt, die Repos "Part 1" und "Part 3" eingerichtet, der Ordner ".git" des Repo "Part 1" umbenannt, in den Zweig "Develop" gewechselt von 'Teil 3', und wenn ein Verzweigungsname auch als Argument an das Skript übergeben wird, leitet eine neue Verzweigung von Develop ab und wechselt zu dieser neuen Verzweigung. Nochmals, hier werden wir einen Leitfaden oder Regeln geben, die zu befolgen sind, bevor ein Commit/Push an das Outsource-Team durchgeführt wird, damit sie wissen, wie und wann sie das "Part 1" -Repo erneut ziehen und sich nicht daran erinnern sollen Commit/Push zu "Part 1" und andere Regeln, die befolgt werden müssen.