Einleitung
Git svn wird benutzt um unter Git mit SVN arbeiten zu können und um die Vorteile von Git zur Verfügung zu haben. Es ist auch ein Schritt zum Umstieg zu Git. Langfristig sollte das Git Repository aber nicht mit git svn benutzt werden da in der Übergangszeit ein unnötiger Overhead ensteht der bei ganz grossen Projekten eventuelle Ressourcen Probleme erzeugt (Zeit, Speicher, CPU).
Dieser Beitrag reduziert sich auf das Minimum des Workflows der zu beachten wäre. Im offiziellen Git Buch gibt es die Hintergründe (siehe Quellenangaben).
Vorraussetzungen
Es gibt bereits ein SVN Repository das man unter Git benutzen möchte.
Erste Schritte
Das SVN Repsoitory in git holen. Wenn es trunk, branches und tags gibt können sie wie folgt angegeben werden od. mit entsprechender Bezeichung: -T myTrunk -b myBranches … (Hast du keine tags, branches und trunk lass die zusätzlichen Parameter einfach weg)
git svn clone url-zum-svn-repository -s oder: git svn clone url-zum-svn-repository -T myTrunk -b myBranches -t tags # ohne branches, tag oder trunk: git svn clone url-zum-svn-repository
Das dauert vermutlich eine weile…
Mit git branch -a listet man alle tags, branches auf .
Mit git show-ref auch woher sie kommen. Etwas unterschiedlich zum normalen git um remote und lokale Zweige zu enttarnen.
Allgemein: Tags und Branches unterscheiden sich in git sehr! Tags sind quasi Marker während Branches wie z.b der Trunk behandelt werden. Der Trunk ist ein Branch ggf. mit der Bezeichnung trunk. Oft wird der Trunk in git als „master“ bezeichnet. Ich verwende „stable“ und benutze Branches als sog. Staging-Bereiche mind. jedoch: „unstable“, „testing“, „stable“. Der „master“ wird bei vielen Entwicklern als „das Endergebnis“- Zweig behandel und nicht als jener Zweig wo die neuste Code Basis existiert!
Nun sollten die SVN History und alle anderen Bearbeitungen (Tags/Branches/Trunk) vom Server geholt und via git verfügbar. Du kannst nun Änderungen dieser Kopie zu weiteren git remotes sowie dem SVN Repository committen bzw. push’en. git push wird nur benötigt wenn du dein git Repository bzw. deine Änderungen auch woanders verfügbar haben möchtest! Ein commit bleibt in der Regel immer lokal.
Workflow
Du arbeitest an deinen Quellen und willst dann die Änderungen ins Repository überspielen:
Erst ins lokale git Repository dann ins Subversion Repository! Ob nun alle Änderungen oder in einzelne commits. Jeder commit nach git wird später auch nach svn automatisch überführt.
Um Änderungen ins SVN Repository zu übertragen reicht nachher und abschliessend ein einziger Befehl.
Wichtig ist nur: Erst zum Schluss wenn alles nach git committed wurde _dann_ zu svn! Sonnst gibt es Probleme!
Alle aktuellen Änderungen sollen für einen commit markiert werden (staging):
git add -A
Nur diese Dateien sollen für einen commit markiert werden (staging):
git add -- datei1 datei2 ...
Prüfen welche Dateien markiert wurden und welche nicht:
git status
Alle markierten Dateien in git committen:
git commit -m "Was beinhaltet die Änderungen des commits"
Git commit Historie ansehen (letzten 3 commits):
git log -3
Abschliessend alle Änderungen in svn überführen:
git svn dcommit
Sofern dir niemand zuvorgekommen ist und deine Änderungen keinen Konflikt verursachen, läuft das jetzt durch und svn wird mit den neuen commits und den einzelnen commit Nachrichten versorgt.
Wenn Konflikte auftauchen muss Hand angelegt werden:
Anstelle svn update benutzt du nun git svn rebase. Damit werden die Neuerungen vom SVN Server geholt und in Git überführt. Eventuelle Konflikte müssen nun ggf. behoben werden und dann wieder:
– staging der Änderungen
– commit nach Git
– Abschliessender commit nach SVN
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.