Wenn Teams Git adaptieren wollen, ist es oft problematisch, den richtigen Einstieg für die Implementierung zu finden. In mehreren Artikeln erläutern wir die häufigsten Git-Workflows, nach denen Enterprise-Teams arbeiten, und zeigen einige Möglichkeiten auf, Aspekte verschiedener Workflows zu vermengen und anzupassen, um spezifische Bedürfnisse des Entwicklungsteams zu erfüllen.
Der zentralisierte Workflow
Die Transition zu einer verteilten Versionskontrolle wird häufig als große Herausforderung angesehen. Dabei muss ein Entwicklungsteam seinen bestehenden Workflow gar nicht aufgeben, um sich Git zunutze zu machen. Vielmehr kann es Projekte auf exakt dieselbe Weise wie mit Subversion entwickeln.
Git bietet gegenüber SVN allerdings einige große Vorteile. Zunächst hat jeder Entwickler seine eigene lokale Kopie des gesamten Projekts. In dieser isolierten Umgebung arbeiten alle Entwickler unabhängig von allen anderen Änderungen am Projekt – sie können ihrem lokalen Repository Commits hinzufügen und die Upstream-Entwicklung komplett ignorieren, bis zum Beispiel das Feature fertig ist, mit dem sie sich gerade beschäftigen.
Zweitens bietet Git ein ausgereiftes Branching- und Merging-Modell. Anders als bei SVN bringen Git-Workflows ausgereifte Sicherheitsmechanismen für die Integration von Code und das Teilen von Änderungen zwischen Repositories mit.
So funktioniert es
Wie Subversion nutzt der zentralisierte Git-Workflow ein zentrales Repository als Einstiegspunkt für alle Änderungen am Projekt. Statt trunk heißt der Entwicklungs-Branch master, und alle Änderungen werden in diesen Branch commitet. Dieser Workflow erfordert keine anderen Branches neben dem Master.
Entwickler starten, indem sie das zentrale Repository klonen. In ihren eigenen lokalen Kopien des Projekts editieren sie Dateien und committen Änderungen, wie sie es mit SVN tun würden. Allerdings werden neue Commits lokal gespeichert – sie sind vollständig von der zentralen Repository isoliert. So kann der Entwickler die Synchronisation Richtung Upstream aufschieben, bis er einen geeigneten Break-Point erreicht hat.
Um Änderungen ins offizielle Projekt auszuliefern, "pusht" der Entwickler seinen lokalen Master-Branch in das zentrale Repository. Dies ist das Äquivalent zu svn commit, abgesehen davon, dass all jene lokalen Commits hinzugefügt werden, die nicht bereits im zentralen Master-Branch sind.
Konflikte handhaben
Das zentrale Repository repräsentiert das offizielle Projekt, seine Commit-History sollte also als unantastbar und unveränderlich gelten. Wenn die lokalen Commits eines Entwicklers vom zentralen Repository abweichen, verweigert Git das Pushen dieser Änderungen, da sie offizielle Commits überschreiben würden.
Bevor der Entwickler sein Feature veröffentlichen kann, muss er die aktualisierten zentralen Commits zu sich holen und per Rebasing seine eigenen Änderungen auf diese aufsetzen. Er fügt seine Änderungen also dem hinzu, was alle anderen bereits getan haben. Das Ergebnis ist eine durch und durch lineare History wie bei traditionellen SVN-Workflows.
Wenn lokale Änderungen in direktem Konflikt mit Upstream-Commits stehen, pausiert Git den Rebasing-Prozess und bietet die Möglichkeit, die Konflikte manuell zu lösen. Das Gute an Git ist, dass es mit git status und git add für das Generieren von Commits und für die Auflösung von Merge-Konflikten dieselben Befehle nutzt.
Das macht es neuen Entwicklern einfach, ihre eigenen Merges zu handhaben. Und falls größere Probleme auftreten, ist es jederzeit möglich, das gesamte Rebasing abzubrechen und es neu zu versuchen.
Im zweiten Artikel zeigen wir am konkreten Beispiel, wie Entwickler nach dem zentralisierten Git-Workflow arbeiten.
Weiterführende Infos: Ihr Partner für Git und Stash
Kennen Sie Stash von Atlassian? Stash bietet eine zentrale Lösung zum Management des gesamten distributierten Codes: Hier kommen alle Git-Repositories im Unternehmen zusammen, hier finden Entwickler immer die letzte offizielle Version eines Projekts, hier können Projektverantwortliche Berechtigungen kontrollieren, um sicherzustellen, dass die richtigen Nutzer Zugriff auf den richtigen Code haben.
Möchten Sie mehr erfahren? Wir sind offizieller Vertriebspartner von Atlassian und einer der größten Atlassian Experts Partner weltweit. Gerne unterstützen wir Sie bei der Evaluierung, Lizenzierung und Adaption von Stash. Und wenn Sie Atlassian-Lizenzen bei //SEIBERT/MEDIA kaufen, gewähren wir Ihnen einen Rabatt in Höhe von 10% der Lizenzkosten in Form von Beratungsleistungen. Bitte sprechen Sie uns einfach an.
Git und Stash in der Software-Entwicklung: Eine Einführung
Stash in der Praxis
Stash Enterprise: Git-Repository-Management in großen Unternehmen
So funktioniert die Lizenzierung von Atlassian-Produkten
