Matt Shelton von Nuance Healthcare ist der Verfasser des heutigen Gastbeitrags. Dies ist der erste Beitrag einer Serie zur Umstellung von Subversion auf Git in seinem Team, zu den Gründen für den Wechsel und den Schwierigkeiten, auf die sie während der Migration gestoßen sind. Matt spricht auch auf dem Atlassian Summit 2015 über dieses Thema. In dieser Serie werden alle Aspekte behandelt, auf die in seinem 30-minütigen Vortrag nicht eingegangen werden konnte. Zudem erhalten Sie zusätzlichen Kontext.

Wir wechseln jetzt also zu Git und finden Git-flow toll. Was nun? Probieren wir alle Funktionen aus! Mein Team ist großartig. Es hat auf Basis unserer Teamaktivitäten und allen seltsamen Dingen, die wir in Zukunft vielleicht machen werden, in Confluence eine Hitliste der Entwickler-Workflows zusammengestellt. Anschließend hat es in einer Projektstruktur, die unsere eigene widerspiegelt (aber ohne Code, nur mit einer pom.xml), jeden Workflow ausprobiert.

Enterprise DVCS Workflows etablieren sich zunehmend und die entsprechenden Muster festigen sich. Die Flexibilität von git ist so groß, dass selbst Teams im gleichen Unternehmen unterschiedliche Ansätze zum Teilen von Code und zur Zusammenarbeit wählen können.

Es gibt unzählige nützliche Leitfäden dazu, wie man forks auf demselben aktuellen Stand wie die upstream-Repositorys hält (und falls du dich fragst, warum du Forks in einer Unternehmensumgebung verwenden solltest, findest du hier ein paar Gründe). In diesem Blogpost gehe ich darauf ein, wie das Forking mit dem upstream interagiert, erkläre einige Grundlagen und häufige Fehler und verrate dir einen nützlichen Tipp. Um das Ganze abzurunden, mache ich dich zum Schluss noch ausgesprochen neidisch oder ausgesprochen ungeduldig, das liegt bei dir. Interessiert? Lies weiter.

Zweieinhalb Monate nach dem Release von Git 2.0.0 können wir uns über eine kleine neue Version von Git mit einigen spannenden neuen Features freuen: Git 2.1.0!

Durch die Arbeit mit Untermodulen in deiner Git-Entwicklung kannst du andere Projekte in deine Codebasis einschließen. Dabei werden deren Verläufe separat gehalten, aber gleichzeitig mit deinem synchronisiert. Dies ist eine praktische Methode zum Lösen der Probleme durch Fremdbibliotheken und Abhängigkeiten. Wie bei allem rund um Git ist die Vorgehensweise eigenwillig und erfordert ein wenig Lernaufwand, bevor sie kompetent angewendet werden kann. Es gibt bereits gute und detaillierte Informationen zu den Untermodulen, diese werde ich hier nicht wiederholen. Stattdessen werde ich ein paar interessante Punkte erläutern, mit denen du das Optimum aus dem Feature herausholen kannst.

Die Frage ist einfach: Was ist in einem Team, das Git und Feature Branching nutzt, die beste Methode zur Integration fertiger Arbeitsresultate zurück in die Hauptentwicklungslinie? Zu diesem Thema wird eine dieser typischen, immer wiederkehrenden Debatten geführt, bei denen beide Seiten sehr von ihrer Meinung überzeugt sind, wodurch eine rationale Gesprächsführung schwierig wird (ein anderes Beispiel für hitzige Debatten: das Internet).

Heutzutage ist das Einfügen von Korrekturen in ein Projekt so einfach wie das Erstellen von Forks (dabei erhältst du eine vollständige Remote-Kopie des Projekts, in der du munter werkeln kannst): Du musst nur die zu ändernde Datei auswählen, auf Bearbeiten klicken und einen Commit für deine Korrekturen durchführen.

Vielleicht stellst auch du dir die folgenden Fragen: Wie geht man in Git mit Projektabhängigkeiten um? Unser Projekt besteht aus mehreren untereinander abhängigen Repositorys. Derzeit verwalten wir sie mit svn:externals. Wie gehen wir mit ihnen in Git am besten um? Wie unterteilt man ein sehr großes Repository mit Git in kleinere Komponenten? Diese Fragen gehören zu den am häufigsten gestellten Fragen bei der europäischen Etappe unserer Getting Git Right-Tour.

Viele Teams haben bereits auf git umgestellt und noch viele weitere befinden sich gerade in der Übergangsphase. Neben dem Training für einzelne Entwickler und der Ernennung von Experten, die bei der Einführung behilflich sind, musst du unbedingt ein einfaches Verfahren zur Zusammenarbeit an Code wählen, das dem Team das Leben nicht unnötig schwer macht. Ich habe mit eigenen Augen gesehen, dass man mit git extrem komplizierte Workflows erschaffen kann.

Bevor ich bei Atlassian anfing, habe ich an verschiedenen Projekten gearbeitet, bei denen noch Subversion (SVN) als Versionskontrollsystem verwendet wurde. Ich hatte schon Jahre zuvor zu Git gewechselt und wollte es so viel wie möglich weiterhin nutzen.