Ich benutze Git, um ein SVN-Repository zu importieren. Dann habe ich mein eigenes Projekt als Unterordner im Repository angelegt.
Ich benutze das SVN-Repository mit Git-SVN. Mein Arbeitsverfahren ist:
git commit -am "message" git svn rebase git svn dcommit . Jetzt möchte ich mein Projekt mit git tag -a RC1 -m 'Release Candidate 1' versehen, aber ich möchte nur, dass mein Projekt das Tag bekommt.
Wie kann ich das tun?
Es ist möglich, bestimmte Verzeichnisse (aka Bäume) zu markieren, wenn Sie den SHA-1 des Baumes kennen, aber es wird nicht oft gemacht & amp; nicht einfach, nützliche Dinge mit diesem Tag zu tun.
Jedes Objekt in Git hat eine einzigartige SHA-1. Am häufigsten beziehen sich SHA-1 auf Commits, aber sie können sich auch auf Blobs (Dateiinhalte) und Trees (Verzeichnisstrukturen & amp; Dateinamen / Datei-Erlaubnis-Mappings) beziehen. Sie können darüber in der Git Objects-Dokumentation nachlesen.
Angenommen, ich bin in einem bestimmten Verzeichnis in meinem Repository. Ich kann git ls-tree HEAD ausführen, um die Liste der Dateien / Verzeichnisse in meinem Pfad zusammen mit ihren SHA-1s zu erhalten:
Ich kann dann einen dieser Bäume markieren (sagen wir oben das data -Verzeichnis):
Das Tag ist jetzt ein Alias für dieses SHA-1 und ich kann es verwenden, wo immer ein SHA-1 für einen Baum akzeptiert wird:
%Vor%Um das Original SHA-1 zurückzubekommen:
%Vor%Was nützt dir das alles? Nicht viel wie-ist. Wenn Sie jedoch bereit sind, eigene Skripts zu schreiben, um den Inhalt eines Baumes zu rekonstruieren oder um die Commits zu finden, die einen Baum enthalten, könnte es für Sie nützlich sein. (z. B. diese SO-Antwort könnte für einen solchen Zweck angepasst werden).
Aber wie andere bereits gesagt haben, wird es Ihnen wahrscheinlich leichter fallen, ein Versions- / Tagging-Modell zu verwenden, das besser mit Git funktioniert, als zu versuchen, Ihr vorhandenes Modell anzupassen. Wie bereits von shikjohari & amp; andere, wenn Sie Projekte innerhalb eines Projekts haben möchten, die ihre eigenen Versionen haben, betrachten Sie Git Submodule statt.
Sie können nicht.
In Git gilt ein Tag by Design immer für das gesamte Repository (genau wie Commits und Branches). Dies ist anders als in Subversion, wo ein Tag (nur eine Kopie) auf einen Teilbaum angewendet werden kann.
Übrigens: Das Markieren eines Unterbaums wird normalerweise auch in Subversion nicht empfohlen, da es schnell verwirrend werden kann, welcher Teil des Baumes markiert wurde. Die meisten Quellen, die ich kenne (z. B. Version Kontrolle mit Subversion empfehlen, immer zu markieren, indem Sie trunk kopieren.
Über dein Problem:
Normalerweise sollten separate Projekte separate Git-Repositories erhalten. "Getrennt" bedeutet in diesem Zusammenhang normalerweise, dass Sie eine separate Verzweigung / Markierung erstellen möchten.
Wenn Sie dies nicht tun / können, ist es wahrscheinlich die beste Option, ein Tag-Präfix zu verwenden und alle Tags myproj-1.0 , myproj-1.1 etc.
Dies ist mit Git nicht möglich. Ein Git-Tag ist ein Zeiger auf ein bestimmtes Commit, während ein Subversion-Tag eine Kopie eines beliebigen Ordners im Subversion-Repository ist. Das Konzept, einen einzelnen Ordner in Subversion zu markieren, wird in Git nicht gut umgesetzt.
Das Problem besteht darin, dass Ihre ursprüngliche Konfiguration nicht mit dem Verzweigungsmodell von Git übereinstimmt. Der Weg, dies in einer git-freundlichen Weise zu tun, wäre, eine Verzweigung für Ihr Projekt einzurichten und dann Commits für diesen Zweig zu taggen.
Sie haben ein paar Optionen:
Markieren Sie das gesamte Repository zu einem bestimmten Zeitpunkt mit git svn tag . Führen Sie git help svn für Anweisungen zur Verwendung dieses Befehls aus.
Markieren Sie das Verzeichnis mit regulären Subversion-Befehlen. Dies erfordert nicht das Herunterladen einer Subversion-Arbeitskopie, da Sie einfach svn copy {URL to your project on the repository} {URL to your tag directory} ausführen können, aber Sie müssen Subversion installieren.
Starten Sie einen neuen Git-Klon Ihres Subversion-Repositorys in einem ganz neuen Verzeichnis. Geben Sie Ihren Projektordner als Trunk-URL statt der eigentlichen Trunk an. Git-svn wird dieses Verzeichnis dann als Hauptzweig behandeln und Ihnen erlauben, es durch Subversion zu markieren und zu kopieren.
Ich befand mich in einem ähnlichen Problem, als ich ein sehr großes Projekt nach Git verlegen musste. Ich stellte fest, dass das Team das SVN nicht richtig gehandhabt hat und die Markierungen von wo auch immer sie wollten. Also gab es Tags für einzelne Projekte und Ordner - was sehr zu empfehlen ist.
Wenn du vorhast, nach Git zu ziehen, solltest du es so halten, wie es in Git funktioniert und es sauber halten. Ich würde vorschlagen, separate Repositories für häufig wechselnde Projekte zu erstellen. Sie können auch Submodule verwenden, wenn Sie Ihr Projekt von anderen Projekten abhängig machen.