Verschieben eines vorhandenen Git-Repositorys in SVN


384

Ich habe meine ganze Arbeit in Git gemacht und auf GitHub gepusht. Ich war sowohl mit der Software als auch mit der Website sehr zufrieden und möchte an dieser Stelle meine Arbeitspraktiken nicht ändern.

Mein Doktorvater bittet alle Studenten, ihre Arbeit in einem SVN-Repository zu behalten, das an der Universität gehostet wird. Ich habe unzählige Dokumentationen und Tutorials gefunden, um ein vorhandenes SVN-Repository in Git abzurufen, aber nichts darüber, ein Git-Repository in ein neues SVN-Repository zu verschieben. Ich gehe davon aus, dass es einen Weg geben muss, dies mit einer Kombination aus git-svn und einem frischen Zweig und Rebasing und all diesen wunderbaren Begriffen zu tun, aber ich bin ein Git-Neuling und fühle mich mit keinem von ihnen sicher.

Ich möchte dann nur ein paar Befehle ausführen, um Commits an dieses SVN-Repository zu senden, wenn ich dies wähle. Ich möchte weiterhin Git verwenden und nur das SVN-Repository spiegeln lassen, was in Git enthalten ist.

Ich werde die einzige Person sein, die sich jemals für SVN engagiert, wenn dies einen Unterschied macht.


1
Bemerkenswert: Sie werden wahrscheinlich Ihre ursprünglichen Datumsstempel verlieren, wenn Sie dies tun. Die neuen Daten basieren auf dem Zeitpunkt des Imports in Subversion.
Nobar

Für diejenigen, die nach aktuelleren Informationen suchen, finden einige möglicherweise den folgenden Beitrag hilfreich bei ihrer Suche nach Automatisierung: köstlichbrains.com
deploying-wordpress-plugins-travis

Antworten:


402

Ich brauchte das auch, und mit Hilfe von Bombes Antwort + einigem Herumspielen konnte ich es zum Laufen bringen. Hier ist das Rezept:

Git importieren -> Subversion

1. cd /path/to/git/localrepo
2. svn mkdir --parents protocol:///path/to/repo/PROJECT/trunk -m "Importing git repo"
3. git svn init protocol:///path/to/repo/PROJECT -s
4. git svn fetch
5. git rebase origin/trunk
5.1.  git status
5.2.  git add (conflicted-files)
5.3.  git rebase --continue
5.4.  (repeat 5.1.)
6. git svn dcommit

Nach # 3 erhalten Sie eine kryptische Nachricht wie folgt:

Verwenden einer höheren URL-Ebene: protocol:///path/to/repo/PROJECT => protocol:///path/to/repo

Ignoriere das einfach.

Wenn Sie # 5 ausführen, können Konflikte auftreten. Beheben Sie diese Probleme, indem Sie Dateien mit dem Status "nicht zusammengeführt" hinzufügen und die Rebase fortsetzen. Schließlich sind Sie fertig; Synchronisieren Sie dann mit dem SVN-Repositorydcommit . Das ist alles.

Repositorys synchron halten

Sie können jetzt mit den folgenden Befehlen von SVN zu Git synchronisieren:

git svn fetch
git rebase trunk

Verwenden Sie zum Synchronisieren von Git zu SVN Folgendes:

git svn dcommit

Schlussbemerkung

Möglicherweise möchten Sie dies auf einer lokalen Kopie ausprobieren, bevor Sie sich bei einem Live-Repository bewerben. Sie können eine Kopie Ihres Git-Repositorys an einem temporären Ort erstellen. Verwenden Sie einfach cp -r, da sich alle Daten im Repository selbst befinden. Anschließend können Sie ein dateibasiertes Test-Repository einrichten, indem Sie Folgendes verwenden:

svnadmin create /home/name/tmp/test-repo

Und überprüfen Sie eine Arbeitskopie mit:

svn co file:///home/name/tmp/test-repo svn-working-copy

So können Sie mit den Dingen herumspielen, bevor Sie dauerhafte Änderungen vornehmen.

Nachtrag: Wenn Sie es vermasseln git svn init

Wenn Sie versehentlich git svn initmit der falschen URL ausgeführt wurden und nicht klug genug waren, um eine Sicherungskopie Ihrer Arbeit zu erstellen (fragen Sie nicht ...), können Sie denselben Befehl nicht einfach erneut ausführen. Sie können die Änderungen jedoch rückgängig machen, indem Sie Folgendes ausgeben:

rm -rf .git/svn
edit .git/config

Und entfernen Sie den Abschnitt [svn-remote "svn"]Abschnitt.

Sie können dann erneut ausführen git svn init.


2
Gute Antwort. Verwechselt dies auch die Festschreibungsdaten?
Drew Noakes

4
Gute Fragen - Leider weiß ich auch keine Antwort darauf. Dies ist eher eine praktische Anleitung für das, was ich als funktionierend empfunden habe. Ich verstehe nicht alle Details. In Bezug auf die Festschreibungstermine könnten Sie einen Test machen und es herausfinden. Denken Sie daran, dass Sie ein lokales (fs-basiertes) SVN-Repo initiieren können, um Dinge zu testen.
Troelskn

10
Ich habe die gleichen Schritte mit "git rebase --onto trunk --root" anstelle von Schritt 5 ausgeführt und hatte viel mehr Erfolg. Es müssen nur eine Handvoll Zusammenführungskonflikte gelöst werden, anstatt Tonnen.
Kubi

5
In meinem Fall hat diese Sequenz nicht funktioniert. Es wurde immer die Meldung "Upstream-SVN-Informationen können nicht aus dem HEAD-Verlauf ermittelt werden" angezeigt. Also kein Commit möglich.
Fedir RYKHTIK

2
Trotzdem habe ich versucht, schlau zu werden und das -s wegzulassen, da ich nicht dem SVN-Standard-Setup (trunk / branch / tags /) folgen wollte. Ohne das könnte es überhaupt nicht funktionieren.
James McMahon

33

So haben wir es geschafft:

Klonen Sie Ihr Git-Repository irgendwo auf Ihrem Computer.

Öffnen Sie .git / config und fügen Sie Folgendes hinzu (unter Verwalten eines schreibgeschützten SVN-Spiegels eines Git-Repositorys ):

[svn-remote "svn"]
    url = https://your.svn.repo
    fetch = :refs/remotes/git-svn

Geben Sie nun in einem Konsolenfenster Folgendes ein:

git svn fetch svn
git checkout -b svn git-svn
git merge master

Wenn es hier aus irgendeinem Grund kaputt geht, geben Sie diese drei Zeilen ein:

git checkout --theirs .
git add .
git commit -m "some message"

Und schließlich können Sie sich zu SVN verpflichten:

git svn dcommit

Hinweis: Ich verschrotte diesen Ordner immer danach.


6
+1 das hat tatsächlich bei mir funktioniert (ich habe überhaupt keinen Kofferraum / Basis), im Gegensatz zu anderen Antworten, die immer wieder gegeben wurdenUnable to determine upstream SVN information from HEAD history.
stijn


2
Ich habe diese Technik ausprobiert, aber sie hat keinen Verlauf importiert. Übrigens ist "Git Merge Master" jetzt "Git Merge - Allow-Un-Related-Histories Master"
Berend de Boer

1
Wenn Sie unbedingt das, was in SVN enthalten ist, mit dem, was in Git enthalten ist, überschreiben möchten, verwenden Sie git merge -s recursive -Xtheirs --allow-unrelated-histories master.
user1475814

28

Bei git rebasedirekter Verwendung wird das erste Commit verloren. Git behandelt es anders und kann es nicht neu gründen.

Es gibt ein Verfahren, bei dem der vollständige Verlauf beibehalten wird: http://kerneltrap.org/mailarchive/git/2008/10/26/3815034

Ich werde die Lösung hier transkribieren, aber Credits sind für Björn.

Git-svn initialisieren:

git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2

Das --prefix gibt Ihnen Fernverfolgungszweige wie "svn / trunk", was nett ist, weil Sie keine mehrdeutigen Namen erhalten, wenn Sie Ihren lokalen Zweig dann nur "trunk" nennen. Und-s ist eine Verknüpfung für das Standardlayout für Trunk / Tags / Zweige.

Holen Sie sich die ersten Sachen von SVN:

git svn fetch

Suchen Sie nun den Hash Ihres Root-Commits (sollte ein einzelnes Commit anzeigen):

git rev-list --parents master | grep '^.\{40\}$'

Holen Sie sich dann den Hash des Commits für den leeren Trunk:

git rev-parse svn/trunk

Erstellen Sie das Transplantat:

echo <root-commit-hash> <svn-trunk-commit-hash> >> .git/info/grafts

Jetzt sollte "gitk" svn/trunkals erstes Commit angezeigt werden , auf dem Ihr Hauptzweig basiert.

Machen Sie das Transplantat dauerhaft:

git filter-branch -- ^svn/trunk --all

Lassen Sie das Transplantat fallen:

rm .git/info/grafts

Gitk sollte sich immer noch svn/trunkin der Abstammung des Meisters zeigen.

Linearisieren Sie Ihren Verlauf über dem Kofferraum:

git svn rebase

Und jetzt sollte "git svn dcommit -n" Ihnen sagen, dass es auf Trunk festgeschrieben wird.

git svn dcommit

Können Sie erklären, wie sich diese Technik von oben unterscheidet?
cmcginty

3
Wenn ich "git rev-parse svn / trunk" versuche, werden unbekannte Revisionen oder Pfade gemeldet, die nicht im Arbeitsbaum enthalten sind.
Adam Ness

Dies ist die einzige Antwort, die für mich funktioniert hat, außer dass die Schritte git filter-branch und drop transplantat nicht benötigt wurden: Ich habe nach dem Erstellen des Transplantats eine Rebase durchgeführt und dann git svn dcommit.
fc7

8

Erstellen Sie ein neues Verzeichnis im Subversion-Repository für Ihr Projekt.

# svn mkdir --parents svn://ip/path/project/trunk

Wechseln Sie zu Ihrem von Git verwalteten Projekt und initialisieren Sie git-svn.

# git svn init svn://ip/path/project -s
# git svn fetch

Dadurch wird ein einzelnes Commit erstellt, da Ihr SVN-Projektverzeichnis noch leer ist. Stellen Sie nun alles auf dieses Commit zurück, git svn dcommitund Sie sollten fertig sein. Es wird jedoch Ihre Commit-Daten ernsthaft durcheinander bringen.


Ich habe diese Antwort mit den Anweisungen unter hassox.blogspot.com/2007/12/using-git-with-svn.html verwendet. Ich habe diese Befehle befolgt und dann "#git branch -a", um den Trunk-Namen anzuzeigen. Dann: # git checkout -b local-svn trunk # git merge master # git svn dcommit Denken Sie daran, das .svn-Verzeichnis .gitignore!
Cflewis

Da ich gerade die gleiche Operation ausgeführt habe, wollte ich deutlich machen, dass git seit einiger Zeit (Januar '09) eine Rebase-Operation für das Root-Commit ausführen kann. Dies macht den Prozess viel einfacher als in vielen alten Artikeln angegeben, siehe Kommentare auf its.arubything.com/2009/1/4/…
Louis Jacomet

Was macht die Option "-s" git svn init? Ich kann das nicht in den Manpages für git svn sehen.
Nathan

Lesen Sie die Manpage noch einmal und suchen Sie möglicherweise nach "-s", weil es dort drin ist. Es ist ein Alias ​​für "--stdlayout".
Bombe

7

Git -> SVN mit vollständigem Commit-Verlauf

Ich hatte ein Git-Projekt und musste es nach SVN verschieben. So habe ich es gemacht und die gesamte Commit-Geschichte beibehalten. Das einzige, was verloren geht, ist die ursprüngliche Festschreibungszeit, da libSVN die Ortszeit festlegt, wenn wir dies tun git svn dcommit.

Wie man:

  1. Haben Sie ein SVN-Repository, in das wir unsere Inhalte importieren und mit git-svn klonen möchten:

    git svn clone https://path.to/svn/repository repo.git-svn`
    
  2. Geh dorthin:

    cd repo.git-svn
    
  3. Fügen Sie die Fernbedienung des Git-Repositorys hinzu (in diesem Beispiel verwende ich C: /Projects/repo.git ). Sie möchten zu SVN pushen und ihm den Namen old-git geben:

    git remote add old-git file:///C/Projects/repo.git/
    
  4. Rufen Sie die Informationen aus dem Hauptzweig vom Old-Git-Repository in das aktuelle Repository ab:

    git fetch old-git master
    
  5. Checken Sie den Hauptzweig der Old-Git-Fernbedienung in einen neuen Zweig namens old im aktuellen Repository aus:

    git checkout -b old old-git/master`
    
  6. Rebase, um den KOPF auf Old-Git / Master zu setzen. Dadurch bleiben alle Ihre Commits erhalten. Dies bedeutet im Grunde, dass Sie Ihre gesamte Arbeit in Git auf die Arbeit setzen, auf die Sie über SVN zugreifen.

    git rebase master
    
  7. Gehen Sie jetzt zurück zu Ihrer Hauptniederlassung:

    git checkout master
    

    Und Sie können sehen, dass Sie einen sauberen Commit-Verlauf haben. Dies ist, was Sie zu SVN pushen möchten.

  8. Schieben Sie Ihre Arbeit zu SVN:

    git svn dcommit
    

Das ist alles. Es ist sehr sauber, kein Hacken und alles funktioniert sofort. Genießen.


Ähnlicher Prozess auch detailliert unter chani.wordpress.com/2012/01/25/…
TWiStErRob

Sieht aus wie. Ich finde ihren Weg jedoch ziemlich verwirrend und meiner ist viel kürzer (8 Schritte als 19/23). Vielleicht verstehe ich sie nicht richtig, aber ich denke, sie mischt bei ihrer zweiten Kugel SVN- und Git-Befehle.
Codingdave

Ah, ja, der Unterschied besteht darin, dass Ihr Prozess Git in das Stammverzeichnis des SVN-Repos importiert, ihr Prozess in einen Unterordner. Deshalb werden die wenigen git svnVorbereitungen benötigt.
TWiStErRob

Sollte es in Schritt 7 keine alte Git-Zusammenführung geben? Für mich scheint es, dass Sie eine Verpflichtung des Meisters eingehen, die Sie nicht geändert haben?!
Alexander

@Alexander mit 'git rebase master' erhalten wir eine schnelle Zusammenführung, dh eine lineare Zusammenführung ohne ein Zusammenführungs-Commit mit zwei Eltern. Wir wollen hier eine lineare Geschichte haben.
Codingdave


3

Ich musste mein vorhandenes Git-Repository in ein leeres SVN-Repository übertragen.

So habe ich es geschafft:

$ git checkout master
$ git branch svn
$ git svn init -s --prefix=svn/ --username <user> https://path.to.repo.com/svn/project/
$ git checkout svn
$ git svn fetch
$ git reset --hard remotes/svn/trunk
$ git merge master
$ git svn dcommit

Es hat ohne Probleme funktioniert. Ich hoffe das hilft jemandem.

Da ich mich mit einem anderen Benutzernamen als dem SVN-Repository autorisieren musste (ich originverwende die Authentifizierung mit privatem / öffentlichem Schlüssel), musste ich die --usernameEigenschaft verwenden.


Möglicherweise müssen Sie installieren, git-svnbevor dies möglich ist. Siehe stackoverflow.com/questions/527037/git-svn-not-a-git-command
flexponsive

2

Wenn Sie weiterhin mit Git als Haupt-Repository arbeiten möchten und nur die Revisionen von Zeit zu Zeit in SVN "exportieren" müssen, können Sie Tailor verwenden , um das SVN-Repository synchron zu halten. Es kann Revisionen zwischen verschiedenen Versionsverwaltungssystemen kopieren und würde den SVN mit den Änderungen aktualisieren, die Sie in Git vornehmen.

Ich habe keine Git-zu-SVN-Konvertierung versucht, aber für ein SVN -> SVN-Beispiel siehe diese Antwort .


2

Noch eine Sequenz, die funktioniert hat (mit einigen Kommentaren zu jedem Schritt):

  1. Installation git-svnund subversionToolkits:

    sudo apt-get install git-svn subversion
    
  2. Schalten Sie in die PROJECT_FOLDER

    cd PROJECT_FOLDER
    
  3. Erstellen Sie den Projektpfad auf dem Subversion-Server (leider git-svnweist das aktuelle Plugin im Vergleich zu TortoiseSVN einen Defekt auf). Es ist nicht möglich, Quellcode direkt in der zu speichern PROJECT_FOLDER. Stattdessen wird standardmäßig der gesamte Code in hochgeladen PROJECT_FOLDER/trunk.

    svn mkdir - Elternprotokoll: /// path / to / repo / PROJECT_FOLDER / trunk -m "Git Repo Platzhalter erstellen"

Dies ist der Ort, an dem trunkam Ende des Pfades obligatorisch ist

  1. Initialisieren Sie den git-svnPlugin-Kontext im .gitOrdner

    git svn init -s protocol:///path/to/repo/PROJECT_FOLDER
    

    Dies ist der Ort, an dem trunkam Ende des Pfades keine Notwendigkeit besteht

  2. Rufen Sie eine leere SubversionRepository-Information ab

    git svn fetch
    

    Dieser Schritt hilft dabei, den Subversion-Server mit dem git-svnPlugin zu synchronisieren . Dies ist der Moment, in dem das git-svnPlugin den remotes/originPfad erstellt und ihn dem trunkUnterordner auf der Serverseite zuordnet.

  3. Das Zurücksetzen alter Git-Commits erfolgte, bevor das git-svnPlugin in den Prozess einbezogen wurde (dieser Schritt ist optional ).

    git rebase origin/trunk
    
  4. Fügen Sie neue / geänderte Dateien zum Festschreiben hinzu (dieser Schritt ist für Git-Aktivitäten normal und optional ).

    git add .
    
  5. Übertragen Sie frisch hinzugefügte Dateien in das lokale Git-Repository (dieser Schritt ist optional und gilt nur, wenn Schritt 7 verwendet wurde):

    git commit -m "Importing Git repository"
    
  6. Durch Verschieben des gesamten Projektänderungsverlaufs auf den Subversion-Server:

    git svn dcommit
    

1

Sie können ein neues SVN-Repository erstellen. Exportieren Sie Ihr Git-Projekt (Ausarbeitung der Git-Dateien). Fügen Sie es dem SVN-Repository hinzu (Initialisieren Sie das Repository mit dem, was Sie bisher in Git hatten). Verwenden Sie dann die Anweisungen zum Importieren von SVN-Repositorys in ein neues Git-Projekt.

Dies verliert jedoch Ihre vorherige Git-Geschichte.



1

Ich möchte ein großartiges Tool teilen, das in der WordPress-Community verwendet wird und Scatter heißt

Git WordPress Plugins und ein bisschen Vernunftstreuung

Auf diese Weise können Benutzer ihr Git-Repository automatisch an wordpress.org SVN senden. Theoretisch kann dieser Code auf jedes SVN-Repository angewendet werden.


Die Verbindung scheint effektiv unterbrochen zu sein ( "Der Server bei evansolomon.me benötigt zu lange, um zu antworten." ).
Peter Mortensen

1

Ich musste kürzlich mehrere Git-Repositorys auf SVN migrieren, und nachdem ich alle Lösungen ausprobiert hatte, die ich finden konnte, funktionierte für mich schließlich Mercurial (ja, mit einem dritten VCS). Mit diesem Handbuch habe ich den folgenden Prozess entwickelt (unter Linux, aber die Grundidee sollte auch unter Windows funktionieren).

  1. Die notwendigen Pakete:

    $ sudo apt-get install git subversion mercurial python-subversion
    
  2. Mercurial muss konfiguriert werden, indem Folgendes hinzugefügt wird ~/.hgrc:

    [extensions]
    hgext.convert=
    
  3. Erstellen Sie einige temporäre Arbeitsverzeichnisse (ich musste mehrere Repositorys migrieren, also habe ich Verzeichnisse für die SVN- und Git-Versionen erstellt, um sie getrennt zu halten):

    $ mkdir svn
    $ mkdir git
    
  4. Erstellen Sie ein leeres lokales SVN-Repository:

    $ svnadmin create svn/project
    
  5. Klonen Sie das vorhandene Git-Repository:

    $ git clone server/path/project.git git/project
    
  6. Lassen Sie Mercurial sein Ding machen:

    $ hg convert --dest-type svn git/project svn/project
    
  7. Jetzt sollte das SVN-Repository den vollständigen Festschreibungsverlauf enthalten, jedoch nicht mit den ursprünglichen Zeitstempeln. Wenn dies kein Problem ist, überspringen Sie den nächsten Teil mit Schritt 11.

  8. Mit ein wenig Arbeit können Datum und Uhrzeit jedes Commits geändert werden . Da meine Repositories ziemlich klein sind, war es für mich möglich, dies manuell zu tun. Erstellen Sie zunächst einen pre-revprop-changeHook im SVN-Repository mit den folgenden Inhalten, damit die erforderliche Eigenschaft geändert werden kann:

    #!/bin/bash
    exit 0;
    

    Dieses Skript muss ausführbar gemacht werden:

    $ chmod +x svn/project/hooks/pre-revprop-change
    
  9. Mercurial hat eine Arbeitskopie des SVN-Repositorys mit dem Namen project -wc erstellt. Wechseln Sie also dorthin und bearbeiten Sie die Festschreibungszeiten:

    $ cd project-wc
    $ svn propedit svn:date --revprop -r 1
    

    Geben Sie das richtige Datum und die richtige Uhrzeit ein (achten Sie auf Zeitzonen!) Und speichern Sie. Sie sollten die Meldung "Neuen Wert für Eigenschaft svn: Datum bei Revision 1 festlegen" erhalten.
    Jetzt spülen und für jede weitere Revision wiederholen.

  10. Überprüfen Sie optional den Commit-Verlauf, um sicherzustellen, dass alles in Ordnung ist:

    $ svn log -r 1:HEAD
    

    Dann gehe eine Ebene zurück:

    $ cd ..
    
  11. Speichern Sie das Repository:

    $ svnadmin dump svn/project > project.dump
    
  12. Und laden Sie den Speicherauszug auf Ihren Subversion-Server. Erledigt!

Dieser Prozess würde wahrscheinlich auch direkt zwischen Remote-Repositorys funktionieren, aber ich fand es einfacher, mit lokalen Repositorys zu arbeiten. Das Festlegen der Festschreibungszeiten war eine Menge Arbeit, aber insgesamt war der Prozess viel einfacher als jede andere Methode, die ich gefunden habe.


1

Es gibt drei Methoden:

  1. Rebase: wie die anderen Antworten

  2. Commit - ID: Finden Sie svn erste id begehen und git erster id verpflichten, Echo ihrer in .git / info / Transplantate: echo "git_id svn_id}" > .git/info/graftsdanngit svn dcommit

  3. Checke jedes Git-Commit aus, kopiere Dateien in svn_repo, svn commit

Bash-Demo: Github-Demo

v1.x: Verwenden Sie Rebase und Commit-ID

v2.x: Verwenden Sie Kopierdateien und dann svn commit


0

In meinem Fall musste ich ein sauberes Projekt von SVN initiieren

$ Project> git svn init protocol://path/to/repo -s
$ Project> git svn fetch

Fügen Sie alle Ihre Projektquellen hinzu ...

$ Project> git add .
$ Project> git commit -m "Importing project sources"
$ Project> git svn dcommit

0

Ich möchte nur einige meiner Erfahrungen mit der akzeptierten Antwort teilen. Ich habe alle Schritte gemacht und alles war in Ordnung, bevor ich den letzten Schritt ausgeführt habe:

git svn dcommit

$ git svn dcommit

Verwendung des nicht initialisierten Werts $ u in Substitution (s ///) in Zeile 101 von /usr/lib/perl5/vendor_perl/5.22/Git/SVN.pm.

Verwendung des nicht initialisierten Werts $ u in Verkettung (.) Oder Zeichenfolge in /usr/lib/perl5/vendor_perl/5.22/Git/SVN.pm Zeile 101. refs / remotes / origin / HEAD: ' https://192.168.2.101/ svn / PROJECT_NAME 'nicht gefunden in' '

Ich fand den Thread https://github.com/nirvdrum/svn2git/issues/50 und schließlich die Lösung, die ich in der folgenden Datei in Zeile 101 /usr/lib/perl5/vendor_perl/5.22/Git/SVN.pm angewendet habe

ich ersetzte

$u =~ s!^\Q$url\E(/|$)!! or die

mit

if (!$u) {
    $u = $pathname;
} 
else {
       $u =~ s!^\Q$url\E(/|$)!! or die
      "$refname: '$url' not found in '$u'\n";
}

Dies hat mein Problem behoben.


-1

Was ist, wenn Sie nicht jedes Commit, das Sie in Git vornehmen, in das SVN-Repository übertragen möchten ? Was ist, wenn Sie nur selektiv Commits über die Pipe senden möchten? Nun, ich habe eine bessere Lösung.

Ich behalte ein lokales Git-Repository, in dem ich nur SVN abrufe und zusammenführe. Auf diese Weise kann ich sicherstellen, dass ich dieselben Änderungen wie SVN einbeziehe, aber meinen Commit-Verlauf vollständig vom SVN getrennt halte.

Dann behalte ich eine separate lokale SVN-Arbeitskopie, die sich in einem separaten Ordner befindet. Das ist derjenige, von dem ich Commits zurück zu SVN mache, und ich benutze dafür einfach das SVN-Befehlszeilenprogramm.

Wenn ich bereit bin, den Status meines lokalen Git-Repositorys auf SVN zu übertragen, kopiere ich einfach das gesamte Durcheinander von Dateien in die lokale SVN-Arbeitskopie und schreibe es von dort mithilfe von SVN anstelle von Git fest.

Auf diese Weise muss ich nie eine Neubasis durchführen, da eine Neubasierung wie ein Freebasing ist.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.