Alex Napitupulu
Ich habe ein Projekt mit Client- und Serverteilen. Ich möchte, dass sich der Client- und der Servercode in verschiedenen Git-Repositories befinden, um den Code klar zu trennen. Sie teilen sich jedoch einige Dateien, und im Idealfall sind die gemeinsam genutzten Dateien sowohl auf dem Client als auch auf dem Server immer identisch.
Wie soll ich vorgehen? Ist es besser, das dritte Repository für den gemeinsamen Code zu haben?
Ich werde keine Ratschläge dazu geben, „wie Sie vorgehen sollten“. Aber ich werde erklären, wie man ein drittes Repository mit gemeinsamem Code in die anderen Repositorys integriert: Dies ist eine Aufgabe für Git-Submodule. Git-Submodule ermöglichen es Ihnen, auf einen Snapshot eines Git-Repositorys unter einem angegebenen Pfad zu verweisen:
git submodule add git://example.com/repository.git path
Erstellen Sie anschließend ein Commit. Nun wird auf einen Snapshot des angegebenen Repositorys verwiesen path.
git submodule initgit submodule updateJedes konfigurierte Submodul wird aktualisiert, damit es dem Zustand entspricht, wie es aussehen soll.
git pull / git fetch + git checkout um das Submodul auf das gewünschte Commit / Tag zu aktualisieren.gitmodules DateiWerfen Sie einen Blick auf die offizielles Handbuch für weitere Informationen zu Submodulen.
Es ist erwähnenswert, dass Submodule nur vom Master-Zweig nachverfolgt werden.
– Entwickler Yego
11. April 2020 um 7:40 Uhr
@DevYego Ich bin mir nicht sicher, was du damit meinst. Sie können die Submodule auf jeden Commit verweisen lassen, nicht nur auf den Master-Zweig. Tracking ist ein Konzept von lokalen vs. entfernten Zweigen, und dies können Sie im Git jedes Submoduls verwalten – es ist sich nicht bewusst, dass es ein Submodul ist.
– Amichai Schreiber
15. Juli 2020 um 11:37 Uhr
Schwern
Wenn sie gemeinsamen Code teilen, sehe ich zwei sinnvolle Optionen. Trennen Sie den gemeinsamen Code in ein eigenes Projekt oder führen Sie die Server- und Client-Repositories zusammen, um die gemeinsame Arbeit an ihnen zu vereinfachen.
Ob das Trennen des gemeinsamen Codes den Mehraufwand wert ist, liegt bei Ihnen. Ist der allgemeine Code für sich genommen sinnvoll oder handelt es sich nur um eine Reihe von Funktionen, die für dieses Produkt spezifisch sind? Wenn Sie beispielsweise einen gemeinsamen SSL- oder Datumsanalysecode hätten, wäre dies ein gutes Spin-off-Projekt. Oder vielleicht haben Sie einen speziellen Code für das Parsen von Konfigurationsdateien geschrieben, der eigenständig bearbeitet werden kann, selbst wenn ihn niemand außer Ihrem Projekt verwendet. Wenn Sie gemeinsamen Code ausgliedern, nur weil die beiden Projekte ihn teilen, machen Sie sich keine Sorgen, er hat keine eigene Richtung. Das Ausgliedern wird sowohl für die Server- als auch für die Client-Teams nur ein Entwicklungshindernis sein.
Ob Sie Client und Server zusammenführen sollten, ist eine weitere Überlegung. Es kommt auch darauf an, ob es sinnvoll ist, sie als separate Produkte zu betrachten. Sind sie als separate Produkte sinnvoll? Können verschiedene Versionen des Clients und des Servers zusammenarbeiten oder muss es sich um dieselbe Version handeln? Arbeiten unterschiedliche Personen am Client und am Server? Die Tatsache, dass Sie alles in einem Super-Repository zusammenhalten möchten, sagt nein.
Wenn Sie in mehrere Repositorys (Client, Server, verwandte Projekte) aufteilen, folgen Sie der Antwort von TimWolla.
Wenn Sie sich nicht sicher sind, führen Sie sie alle in einem Repository mit zusammen server/, client/ Und common/ Verzeichnisse der obersten Ebene. Wenn ihre Anliegen verstrickt sind, bringen Sie sie zusammen. Dadurch wird es auch einfacher, doppelten Code zu erkennen und zu migrieren. Sie können daran arbeiten, sie zu entwirren und konkrete “gemeinsame” Projekte zu erstellen, und zu diesem Zeitpunkt sollten sie in ihre eigenen Repositories ausgegliedert werden.
Verwenden Sie einfach Git-Submodule, um Ihren gemeinsamen Code zu speichern. Das ist der Anwendungsfall, für den sie gedacht sind. Es gibt andere Optionen, aber hauptsächlich für Repositories auf demselben Dateisystem und mit wenig Vorteil, wenn sie über ein Netzwerk geklont werden.
Der richtige Weg, mit allgemeinem Code umzugehen, ist normalerweise durch Submodule oder Teilbaum zusammenführen. Wenn Sie jedoch Datei-Assets haben, die identisch sind (und bleiben), können Sie Symlinks auf Dateisystemen nutzen, die sie unterstützen. Dieser Ansatz hat mindestens drei Nachteile:
Sie können auch die Verwendung von untersuchen Stellvertreter um Objekte zwischen Repositories auf demselben Dateisystem zu teilen. Im Handbuch steht (Hervorhebung von mir):
Sie könnten die Mechanismen objects/info/alternates oder $GIT_ALTERNATE_OBJECT_DIRECTORIES verwenden Objekte aus anderen Objektlagern auszuleihen. Ein Repository mit dieser Art von unvollständigem Objektspeicher ist nicht geeignet, um für die Verwendung mit dummen Transporten veröffentlicht zu werden, ist aber ansonsten in Ordnung, solange objects/info/alternates auf die Objektspeicher zeigt, aus denen es entlehnt wird.
Diese Art der erweiterten Nutzung wird normalerweise verwendet, um das Forking auf Systemen wie Atlassian Stash zu beschleunigen, anstatt bestimmte Blobs zu teilen, aber die Tools sind da, wenn Sie mit Kettensägen jonglieren möchten.
Es fühlt sich seltsam an, dass ein Repository die “echte” Datei in dem Fall hat, in dem es nicht offensichtlich ist, eine der anderen vorzuziehen. Sie müssten sich merken, welches Repo die echte Datei enthält
– Guillermo Mosse
28. Januar 2022 um 11:32 Uhr
Verwenden Sie entweder Submodule, Subtrees oder Subrepos:
https://medium.com/@porteneuve/mastering-git-submodules-34c65e940407
https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec
Verwenden Sie einen Paketmanager (wie NPM für node.js, abhängig von Ihrer Sprache/Umgebung),
Verschieben Sie die gemeinsamen Dateien in ein Paket,
vielleicht ein Post-Install-Skript hinzufügen,
und installieren Sie das gemeinsame Paket sowohl im Client- als auch im Serverpaket
