Tag Archives: Subversion

Warum verteilte Versionskontrolle mit Git?

Verteilte Versionskontrollsysteme (Distributed Version Control System, DVCS) sind in der Software-Entwicklung ein großer Schritt vorwärts. Aber in der Regel können Teams nicht einfach per Knopfdruck umsteigen. Die Codebasis der Produkte und Bibliotheken muss von zentralisierten Versionskontrollsystemen (zumeist SVN) auf DVCS migriert werden – und diese Migrationen sind häufig richtig groß. Was bringt eine verteilte Versionskontrolle und warum ist die Migration die Kosten wert?

Migration von Subversion zu Git: Das Git-Repository teilen

Der Umstieg von Subversion auf eine Git-basierte verteilte Versionskontrolle ist nicht so komplex, wie viele Entwicklungsteams annehmen. Der Prozess lässt sich in fünf aufeinanderfolgende Schritte aufteilen, die der Migration Struktur geben. Nach der Vorbereitung des lokalen Rechners eines Migrationsleiters, der Konvertierung des SVN-Repositorys in ein lokales Git-Repository und der Synchronisation des lokalen Git-Repositorys geht es nun darum, wie das neue Repo mit dem Rest des Teams geteilt werden kann.

Migration von Subversion zu Git: Die Konvertierung

Den Wechsel von Subversion (SVN) zu einer Git-basierten verteilten Versionskontrolle kann ein Software-Entwicklungsteam in fünf einfache Schritte aufbrechen und so nahtlos und zielgerichtet strukturieren. Nach der Vorbereitung des lokalen Rechners des Migrationsleiters steht als nächste Etappe der Import der Inhalte des SVN-Repositorys in ein neues Git-Repository an. Das Vorgehen beschreibt dieser Artikel.

Migration von Subversion zu Git: Überblick

Der Umstieg eines Software-Entwicklungsteams von Subversion (SVN) auf die verteilte Versionskontrolle Git muss keine Herkulesaufgabe sein, sondern lässt sich in fünf nahtlose Abschnitte strukturieren und zielgerichtet vorantreiben. Diese Artikelreihe zeigt auf, wie eine bestehende Projekt-History in ein Git-Repository importiert wird, wie man es mit dem originalen SVN-Repository synchronisiert und wie sich schließlich mithilfe von Bitbucket ein Git-basierter Kollaborations-Workflow implementieren lässt. Dabei muss das Team die aktive SVN-Entwicklung nicht opfern, bis es tatsächlich bereit ist, den reinen Git-Workflow zu adaptieren. Zunächst ein Überblick.

Git-Workflows: Der Pull-Request-Workflow (Teil 2)

Im letzten Beitrag wurde das Konzept der Pull-Requests im Rahmen der Git-Entwicklung grundsätzlich vorgestellt. Nun soll ein Beispiel demonstrieren, wie Pull-Requests im Rahmen des Forking-Workflows zum Einsatz kommen können. Es ist gleichermaßen anwendbar auf Entwickler, die in einem kleinen Team arbeiten, und auf Dritt-Entwickler, die sich an einem Open-Source-Projekt beteiligen.

Git-Workflows: Der Pull-Request-Workflow (Teil 1)

Ein Pull-Request ist mehr als nur eine Benachrichtigung – Er bietet ein dediziertes Forum, um ein Feature zu diskutieren. Gibt es Probleme mit den Änderungen, können Teammitglieder im Pull-Request Feedback abgeben und das Feature sogar optimieren, indem sie Follow-up-Commits pushen. All diese Aktivitäten werden direkt im Pull-Request getrackt. Dieser Artikel beschreibt die Zusammenarbeit von Git-Teams, die Pull-Requests nutzen.

FishEye und Crucible 3.4: Stash-Integration, Performance-Steigerung, Full-Screen-Modus

Die Software-Entwicklung ist eine Branche, die sich extrem schnell weiterentwickelt. Aktuell können wir dies zum Beispiel daran sehen, dass viele Unternehmen von traditionellen Versionskontrollsystemen wie Subversion zu Git wechseln. Diesen Teams bietet Atlassians Stash eine ausgereifte Umgebung, um ihre Repositories zu managen. Mit der gerade ausgelieferten neuen Version von FishEye und Crucible ist die Integration dieser Plattform ebenso vorangetrieben worden wie die Git-Indizierungs-Performance. Diese und weitere Neuerungen in FishEye/Crucible 3.4 zeigt dieser Beitrag.