Suche…
Bemerkungen
Klonen wirklich großer SVN-Repositories
Wenn der SVN-Repo-Verlauf wirklich sehr groß ist, kann dies einige Stunden dauern, da git-svn den gesamten Verlauf des SVN-Repos neu erstellen muss. Glücklicherweise müssen Sie das SVN-Repo nur einmal klonen. Wie bei jedem anderen git-Repository können Sie den Repo-Ordner einfach auf andere Mitbearbeiter kopieren. Das Kopieren des Ordners auf mehrere Computer ist schneller als das Klonen großer SVN-Repos von Grund auf.
Über Commits und SHA1
Ihre lokalen git Commits wird neu geschrieben werden , wenn der Befehl git svn dcommit . Dieser Befehl fügt der Nachricht von git commit einen Text hinzu, der auf die auf dem SVN-Server erstellte SVN-Version verweist, was sehr nützlich ist. Wenn Sie jedoch einen neuen Text hinzufügen, müssen Sie die Nachricht eines vorhandenen Commits ändern, was eigentlich nicht möglich ist: git-Commits sind nicht veränderbar. Die Lösung besteht darin, ein neues Commit mit demselben Inhalt und der neuen Nachricht zu erstellen, aber technisch gesehen ist es sowieso ein neues Commit (dh die SHA1 des Git-Commits ändert sich).
Da für git-svn erstellte git-Commits lokal sind, unterscheiden sich die SHA1-IDs für git-Commits zwischen den einzelnen git-Repositorys! Das bedeutet, dass Sie ein SHA1 nicht verwenden können, um auf ein Commit einer anderen Person zu verweisen, da das gleiche Commit in jedem lokalen Git-Repository ein anderes SHA1 hat. Sie müssen sich auf die an die Commit-Nachricht angehängte svn-Revisionsnummer verlassen, wenn Sie auf den SVN-Server pushen, wenn Sie ein Commit zwischen verschiedenen Kopien des Repositorys referenzieren möchten.
Sie können den SHA1 jedoch für lokale Operationen verwenden (ein bestimmtes Commit anzeigen, abgleichen, zurücksetzen usw.).
Fehlerbehebung
Der Befehl git svn rebase gibt einen Prüfsummenfehler aus
Der Befehl git svn rebase löst einen Fehler ähnlich dem folgenden aus:
Checksum mismatch: <path_to_file> <some_kind_of_sha1>
expected: <checksum_number_1>
got: <checksum_number_2>
Die Lösung für dieses Problem ist, svn auf die Revision zurückzusetzen, wenn die problematische Datei zum letzten Mal geändert wurde. Führen Sie einen git svn-Abruf durch, damit die SVN-Historie wiederhergestellt wird. Die Befehle zum SVN-Reset sind:
- git log -1 -
<path_to_file>(kopieren Sie die SVN-Revisionsnummer, die in der Festschreibungsnachricht<path_to_file>) - git svn reset
<revision_number> - git svn holen
Sie sollten in der Lage sein, Daten erneut aus dem SVN zu pushen / zu ziehen
Datei wurde beim Festschreiben nicht gefunden Wenn Sie versuchen, SVN abzurufen oder von diesem abzurufen, wird eine ähnliche Fehlermeldung angezeigt
<file_path> was not found in commit <hash>
Dies bedeutet, dass eine Revision in SVN versucht, eine Datei zu ändern, die aus irgendeinem Grund in Ihrer lokalen Kopie nicht vorhanden ist. Der beste Weg, um diesen Fehler zu beseitigen, besteht darin, einen Abruf zu erzwingen, der den Pfad dieser Datei ignoriert, und er wird in der neuesten SVN-Version auf seinen Status aktualisiert:
-
git svn fetch --ignore-paths <file_path>
Klonen des SVN-Repository
Sie müssen mit dem Befehl eine neue lokale Kopie des Repository erstellen
git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH
Wenn Ihr SVN-Repository dem Standardlayout (Stamm, Verzweigungen, Tag-Ordner) entspricht, können Sie einige Eingaben speichern:
git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]
git svn clone überprüft jede SVN-Revision nacheinander und führt ein git-Commit in Ihrem lokalen Repository durch, um den Verlauf neu zu erstellen. Wenn das SVN-Repository viele Commits enthält, wird dies eine Weile dauern.
Wenn der Befehl abgeschlossen ist, haben Sie ein vollständiges Git-Repository mit einem lokalen Zweig namens Master, der den Trunk-Zweig im SVN-Repository verfolgt.
Die neuesten Änderungen von SVN abrufen
Das Äquivalent zu git pull ist der Befehl
git svn rebase
Dadurch werden alle Änderungen aus dem SVN-Repository abgerufen und auf Ihre lokalen Commits in Ihrem aktuellen Zweig angewendet.
Sie können den Befehl auch verwenden
git svn fetch
Abrufen der Änderungen aus dem SVN-Repository und Übertragen der Änderungen auf den lokalen Computer
Lokale Änderungen in SVN verschieben
Der Befehl
git svn dcommit
erstellt eine SVN-Revision für jedes Ihrer lokalen Git-Commits. Wie bei SVN muss Ihr lokaler Git-Verlauf mit den neuesten Änderungen im SVN-Repository git svn rebase . Versuchen Sie daher, wenn der Befehl fehlschlägt, zuerst ein git svn rebase .
Vor Ort arbeiten
Verwenden Sie einfach Ihr lokales Git-Repository als normales Git-Repo mit den normalen Git-Befehlen:
-
git add FILEundgit checkout -- FILEUm eine Datei zu inszenieren / entpacken -
git commitZum Speichern Ihrer Änderungen. Diese Commits sind lokal und werden nicht wie beim normalen Git-Repository in das SVN-Repo "verschoben" -
git stashundgit stash popErmöglicht die Verwendung von Stashes -
git reset HEAD --hardAlle lokalen Änderungengit reset HEAD --hard -
git logZugriff auf den gesamten Verlauf im Repository -
git rebase -idamit Sie Ihre Ortsgeschichte frei umschreiben können -
git branchundgit checkout, um lokalegit checkoutzu erstellen
Wie in der git-svn-Dokumentation angegeben ist "Subversion ist ein System, das weitaus weniger ausgereift ist als Git", so dass Sie nicht die ganze Leistungsfähigkeit von git nutzen können, ohne den Verlauf des Subversion-Servers zu beeinträchtigen. Zum Glück sind die Regeln sehr einfach: Halten Sie die Geschichte linear
Das bedeutet, dass Sie nahezu jede beliebige Git-Operation ausführen können: Verzweigungen erstellen, Commits entfernen / neu sortieren / zerquetschen, Historie verschieben, Commits löschen usw. Alles außer einer Fusion . Wenn Sie die Historie lokaler Zweige wieder integrieren git rebase stattdessen git rebase .
Wenn Sie eine Zusammenführung durchführen, wird ein Zusammenführungs-Commit erstellt. Das Besondere an Merge-Commits ist, dass sie zwei Eltern haben, und das macht die Geschichte nicht linear. Nicht-linearer Verlauf verwirrt SVN in dem Fall, dass Sie eine Zusammenführungsfestschreibung in das Repository "pushen".
Aber keine Sorge: Sie werden nichts kaputt machen, wenn Sie ein Git-Merge-Commit an SVN "pushen" . Wenn Sie dies tun, wird der git merge-Commit an den svn-Server gesendet, der alle Änderungen aller Commits für diese Zusammenführung enthält. Dadurch verlieren Sie den Verlauf dieser Commits, nicht jedoch die Änderungen in Ihrem Code.
Umgang mit leeren Ordnern
git kennt das Konzept von Ordnern nicht, es funktioniert nur mit Dateien und deren Dateipfaden. Dies bedeutet, dass git keine leeren Ordner verfolgt. SVN tut es jedoch. Die Verwendung von git-svn bedeutet, dass Änderungen, die leere Ordner mit git betreffen , standardmäßig nicht an SVN weitergegeben werden .
Die Verwendung des --rmdir bei der Ausgabe eines Kommentars behebt dieses Problem und entfernt einen leeren Ordner in SVN, wenn Sie die letzte darin enthaltene Datei lokal löschen:
git svn dcommit --rmdir
Leider werden vorhandene leere Ordner nicht entfernt : Sie müssen dies manuell tun.
Um zu vermeiden, dass Sie das Flag jedes Mal hinzufügen, wenn Sie einen Commit ausführen, oder wenn Sie ein git-GUI-Tool (wie SourceTree) verwenden, können Sie dieses Verhalten mit dem Befehl als Standard festlegen:
git config --global svn.rmdir true
Dies ändert Ihre .gitconfig-Datei und fügt folgende Zeilen hinzu:
[svn]
rmdir = true
Um alle nicht erfassten Dateien und Ordner zu entfernen, die für SVN leer bleiben sollen, verwenden Sie den Befehl git:
git clean -fd
Bitte beachten Sie: Mit dem vorherigen Befehl werden alle nicht protokollierten Dateien und leeren Ordner entfernt, auch diejenigen, die von SVN protokolliert werden sollten! Wenn Sie die leeren Ordner, die von SVN verfolgt werden, generieren möchten, verwenden Sie den Befehl
git svn mkdirs
In der Praxis bedeutet dies, dass Sie, wenn Sie Ihren Arbeitsbereich von nicht protokollierten Dateien und Ordnern bereinigen möchten, immer beide Befehle verwenden müssen, um die leeren Ordner wiederherzustellen, die von SVN verfolgt werden:
git clean -fd && git svn mkdirs