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.
Der Umgang mit Maven-Abhängigkeiten bei der Umstellung auf Git
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.
Git: Automatische Merges mit serverseitigen Hooks – die Strategie der Gewinner
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.
Git Forks und Upstreams: Anleitung und ein cooler Tipp
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.
Neu in Git 2.1
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!
Kernkonzept, Workflows und Tipps
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.
Team-Workflows in Git: mergen oder rebasen?
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).
Kompetente Nutzung von Pull-Requests: Abrufen leicht gemacht!
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.
Git und Projektabhängigkeiten
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.
Der einfache Git-Workflow ist genau das: einfach
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.
Arbeite mit Git, auch wenn dein Team dies nicht macht: Tipps und Tricks zu git-svn
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.