Einer der Vorteile von git ist, dass man ziemlich einfach gegen ein Subversion Repository arbeiten kann. Nach einem git svn clone hat man das Ganze Subversion Repo auf der eigenen Festplatte. In der Regel reichen einem jedoch die letzten 100 Commits und man möchte die Struktur des Subversion Repos beibehalten. Hierfür erweitert man den o.g. Befehl um die Optionen -r<Startrevision>:HEAD um den Ausschnitt aus dem SVN Repo zu verkleinern. Und -s bzw. --stdlayout wählt man, wenn man für trunk, tags und branches eben diese Verzeichnisse im Wurzelverzeichnis des Subversion Repositories hat. Daraus ergibt sich dann git svn clone -r1000:HEAD -s https://svn.codehaus.org/foobar zielverzeichnis wenn man die Revisionen ab 1000 bis zum aktuellen Stand von https://svn.codehaus.org/foobar clonen möchte. Das Klonen kann je nach Größe des Repositories und Netzbandbreite einige Minuten dauern. Danach hat man ALLES auf der Platte. Dateien die man bei Subversion ignoriert hat, kann man automatisch auch bei git ignorieren, wenn man (echo; git-svn show-ignore) >> .git/info/exclude ausführt. Nun kann man ganz normal mit git arbeiten. Also einen eigenen Branch erstellen, Dateien ändern... # Optional, aber empfohlen: Einen eigenen lokalen development Branch erstellen git checkout -b development trunk # Geänderte, gelöschte oder neue Dateien bekannt machen für den nächsten Commit mit git add file [file ...] # Änderungen als logischen Commit bündeln git commit -m "Message" Sicher möchte man auch mal die eigenen Änderungen dem SVN Repository bereitstellen. Vorher sollte man sich jedoch mit dem entfernten Repository synchronisieren. Dies geschieht mittels git svn rebase. Entfernte Änderungen werden geholt und ein automatischer Merge versucht. Das Absender der eigenen Änderungen erfolgt mittels git svn dcommit Zuvor ist es sinnvoll mit der -n Option einen Testlauf zu starten. Insgesamt ergibt sich folgender Workflow: Änderungen in den lokalen development Branch committen git svn rebase ausführen um mögliche Konflikte zu svn zu lösen Mit git checkout master auf den Hauptzweig wechseln git svn rebase Master branch mit svn synchronisieren Merge die Änderungen aus dem Entwicklungsbranch in den Master: git merge --no-ff work developmenty Löse mögliche Merge Konflikte Mit git svn dcommit die Änderungen ans Subversion schicken. Fertig. Ich habe im Artikel bisher gezeigt, wie man relativ einfach git gegen ein Subversion Repository nutzen kann. Möchte man eigentlich den Inhalt des Subversion Repositorys in Zukunft in einem git Repository verwalten, so genügt nach dem clonen, das Hinzufügen eines neuen Remotes Repositories: git svn clone ... git remote add origin Pfad_zum_git_Repository git push origin master Empfohlen sei auch ein anderer Artikel zu git best practices: branching. Mehr Infos und die Git Doku findet man bei Pro Git Git Community Book Git man page

Einer der Vorteile von git ist, dass man ziemlich einfach gegen ein Subversion Repository arbeiten kann. Nach einem git svn clone hat man das Ganze Subversion Repo auf der eigenen Festplatte. In der Regel reichen einem jedoch die letzten 100 Commits und man möchte die Struktur des Subversion Repos beibehalten. Hierfür erweitert man den o.g. Befehl um die Optionen -r<Startrevision>:HEAD um den Ausschnitt aus dem SVN Repo zu verkleinern. Und -s bzw. --stdlayout wählt man, wenn man für trunk, tags und branches eben diese Verzeichnisse im Wurzelverzeichnis des Subversion Repositories hat.
Daraus ergibt sich dann

git svn clone -r1000:HEAD -s https://svn.codehaus.org/foobar zielverzeichnis

wenn man die Revisionen ab 1000 bis zum aktuellen Stand von https://svn.codehaus.org/foobar clonen möchte. Continue reading →