Remote in das Unterverzeichnis ziehen

9

Ich habe ein Git-Repository auf bitbucket gehostet, das die folgende Verzeichnisstruktur hat:

%Vor%

Wir haben einen Lieferanten, der den /Website -Teil der Lösung erstellt.

Sie haben ein Repo, das so aussieht

%Vor%

Was ist der beste Weg, um ihren Repo in unseren Unterordner zu ziehen, und dann zu einem späteren Zeitpunkt zurückschieben zu können?

UPDATE: Es ist erwähnenswert, dass beide Repos Dateien im aktuellen Ordner '/ Website' haben, ohne voneinander zu wissen.

UPDATE 2: Dies ist auch ein Windows-basiertes Git-Repo, das von mehreren Entwicklern geteilt wird (so dass eine lokale Konfiguration der Maschine nicht möglich wäre).

    
Doug 24.06.2013, 00:40
quelle

2 Antworten

5
___ tag123git ___ Git ist ein Open-Source-Versionskontrollsystem (DVCS). Verwenden Sie dieses Tag für Fragen zur Verwendung von Git und Workflows. Verwenden Sie dieses Tag nicht für allgemeine Programmierfragen, die ein Git-Repository betreffen. ___ qstnhdr ___ Remote in das Unterverzeichnis ziehen ___ answer17267025 ___

Schlage am besten vor, Subtrees statt Submodule zu verwenden

Ein guter Durchlauf der Vorteile hier:

Ссылка

  

Es gibt mehrere Gründe, warum Sie Teilbäume besser verwenden können:

     

Die Verwaltung eines einfachen Workflows ist einfach.

     

Ältere Version von Git wird unterstützt (noch vor Version 1.5.2).

     

Der Code des Unterprojekts ist direkt nach dem Klonen des Superprojekts verfügbar.

     

subtree erfordert nicht, dass Benutzer Ihres Repositorys etwas Neues lernen, sie können die Tatsache ignorieren, dass Sie Teilbäume verwenden, um Abhängigkeiten zu verwalten.

     

subtree fügt keine neuen Metadatendateien wie Submodule doe (d. h. .gitmodule) hinzu.

     

Der Inhalt des Moduls kann geändert werden, ohne dass eine separate Repository-Kopie der Abhängigkeit an einer anderen Stelle vorhanden ist.

     

Meiner Meinung nach sind die Nachteile akzeptabel:

     

Sie müssen eine neue Zusammenführungsstrategie kennen (d. h. Teilbaum).

     

Der Beitrag, der für die Teilprojekte zurück in den Upstream-Bereich fließt, ist etwas komplizierter.

     

Die Verantwortung, Super- und Subprojektcode nicht in Commits zu mischen, liegt bei Ihnen.

    
___ antwort32390552 ___

Es gibt eine Möglichkeit, ein Remote-Repository ohne Verwendung von Submodulen oder Teilbäumen einzufügen, auch wenn dieses Repository völlig unabhängig von Ihnen ist und gegensätzliche Verzeichnisse aufweist.

Fügen Sie zuerst dieses Repository als eine Ihrer Fernbedienungen in .git/config hinzu. Nehmen wir zum Beispiel an, du möchtest Zaldors Gruff-Bibliothek von Github mitbringen. Diese Namen sind völlig fiktiv:

%Vor%

Jetzt können Sie git fetch gruff-upstream machen, um alle Objekte zu erhalten. Jetzt können Sie die verfügbaren Zweige in den gruff -Projekten sehen.

%Vor%

Die zwei gruff -Zeilen sind gruff 's Zweige. Der origin/master ist unser eigener Ursprung. Die Namen kollidieren: gruff hat master und wir haben auch master . Das macht nichts: Wir können gruff/master einen anderen lokalen Zweignamen geben.

%Vor%

Nun, wenn wir git checkout gruff-master haben, werden alle unsere git-tracked Dateien verschwinden, ersetzt durch die gruff Arbeitskopie:

%Vor%

Jetzt können wir diesen gruff-master Zweig ein wenig verbessern. Zum Beispiel können wir alle seine Dateien in ein Unterverzeichnis verschieben, unerwünschte Dateien entfernen und so:

%Vor%

Als nächstes wechseln wir zurück zu unserem eigenen master . Gruff-Dateien verschwinden und unsere Dateien sind zurück:

%Vor%

Jetzt können wir einige Dateien von gruff in unser master bringen:

%Vor%

Diese Dateien materialisieren sich in unserer Arbeitskopie und werden unserem Index hinzugefügt:

%Vor%

wir können sie jetzt in unsere master einfügen.

Wenn der Upstream gruff neue Versionen der Dateien veröffentlicht, können wir zu unserem gruff-branch wechseln und ziehen. Lösen Sie die neuen Änderungen gegen unsere Bereinigung und Festschreibung. Zurück zu unserem master , können wir dieses neue Update aus unserem lokalen Zweig gruff-master auswählen.

Ja, im Grunde verwendet man Git als verklärtes Patch-Tool. Das Material von gruff-master ausgewählt in master hat keine Vorfahren; Es sieht nur wie hinzugefügte Dateien aus. Es ist jedoch besser als nichts und in vielerlei Hinsicht weniger umständlich als Teilbäume oder Module.

    
___ qstntxt ___

Ich habe ein Git-Repository auf bitbucket gehostet, das die folgende Verzeichnisstruktur hat:

%Vor%

Wir haben einen Lieferanten, der den %code% -Teil der Lösung erstellt.

Sie haben ein Repo, das so aussieht

%Vor%

Was ist der beste Weg, um ihren Repo in unseren Unterordner zu ziehen, und dann zu einem späteren Zeitpunkt zurückschieben zu können?

UPDATE: Es ist erwähnenswert, dass beide Repos Dateien im aktuellen Ordner '/ Website' haben, ohne voneinander zu wissen.

UPDATE 2: Dies ist auch ein Windows-basiertes Git-Repo, das von mehreren Entwicklern geteilt wird (so dass eine lokale Konfiguration der Maschine nicht möglich wäre).

    
___
Kaz 04.09.2015 05:13
quelle
1

Schlage am besten vor, Subtrees statt Submodule zu verwenden

Ein guter Durchlauf der Vorteile hier:

Ссылка

  

Es gibt mehrere Gründe, warum Sie Teilbäume besser verwenden können:

     

Die Verwaltung eines einfachen Workflows ist einfach.

     

Ältere Version von Git wird unterstützt (noch vor Version 1.5.2).

     

Der Code des Unterprojekts ist direkt nach dem Klonen des Superprojekts verfügbar.

     

subtree erfordert nicht, dass Benutzer Ihres Repositorys etwas Neues lernen, sie können die Tatsache ignorieren, dass Sie Teilbäume verwenden, um Abhängigkeiten zu verwalten.

     

subtree fügt keine neuen Metadatendateien wie Submodule doe (d. h. .gitmodule) hinzu.

     

Der Inhalt des Moduls kann geändert werden, ohne dass eine separate Repository-Kopie der Abhängigkeit an einer anderen Stelle vorhanden ist.

     

Meiner Meinung nach sind die Nachteile akzeptabel:

     

Sie müssen eine neue Zusammenführungsstrategie kennen (d. h. Teilbaum).

     

Der Beitrag, der für die Teilprojekte zurück in den Upstream-Bereich fließt, ist etwas komplizierter.

     

Die Verantwortung, Super- und Subprojektcode nicht in Commits zu mischen, liegt bei Ihnen.

    
Jak Charlton 24.06.2013 01:47
quelle

Tags und Links