Leichtere Softwareentwicklung dank Git

Drei Tipps, die dir helfen, Git an deinen Agile-Workflow anzupassen (und umgekehrt)

Laura Daly Laura Daly
Themen durchsuchen

Git ist der De-facto-Standard für Versionskontrollsysteme bei der Agile-Softwareentwicklung. Das Open-Source-Projekt mit umfassendem Support ist so flexibel, dass es eine Reihe von Workflows unterstützt und damit die Anforderungen aller Arten von Softwareteams erfüllt. Dank der verteilten (statt zentralisierten) Struktur sorgt Git für überragende Leistung und lässt Entwicklern die Freiheit, lokal zu experimentieren und Änderungen erst dann zu veröffentlichen, wenn sie zur Verteilung im Team bereit sind.

Neben den Vorteilen, die eine flexible und verteilte Lösung mit sich bringt, verfügt Git über wichtige Funktionen zur Unterstützung und Förderung der Agile-Entwicklung. Du kannst dir Git als eine Komponente der Agile-Entwicklung vorstellen: Änderungen durchlaufen die Deployment-Pipeline schneller als bei monolithischen Releases und zentralisierten Versionskontrollsystemen. Git passt sich an die (tatsächliche und angestrebte) Arbeitsweise deines Agile-Teams an.

Profitipp:

Git ist ein verteiltes Versionskontrollsystem (Distributed Version Control System, DVCS). Anders als bei CVS oder bei SVN-Repositorys (Subversion) können Entwickler in Git eine eigene, persönliche Kopie des Team-Repositorys erstellen, die dann neben der Haupt-Codebasis gehostet wird. Diese Kopien werden als "Forks" bezeichnet. Wenn die Arbeit an einem Fork abgeschlossen ist, lassen sich die Änderungen leicht zurück in die Haupt-Codebasis übertragen.

Git-Branching | Atlassian Agile Coach

Tipp 1: Stelle dir Tasks als Git-Branches vor.

Git kommt ins Spiel, wenn die Features ausgearbeitet und in eine Produkt-Roadmap eingetragen wurden und wenn das Entwicklerteam bereit ist. Zunächst aber noch ein kleiner Crashkurs in Agile-Feature-Entwicklung: Die Zuständigen für Produkt, Design, Qualitätssicherung (QS) und Entwicklung halten ein Feature-Kick-off-Meeting ab, um sich darüber einig zu werden, wie das Feature aussehen soll (Anforderungen), welchen Umfang das Projekt haben soll und in welche Tasks das Feature zur Fertigstellung unterteilt werden muss. Diese auch als "User Storys" bezeichneten Tasks werden dann einzelnen Entwicklern zugewiesen.

An diesem Punkt fügt sich Git in den Agile-Workflow ein. Wir bei Atlassian erstellen für jeden Vorgang einen neuen Branch. Dabei spielt es keine Rolle, ob es sich um ein neues Feature, einen Bugfix oder um eine kleine Verbesserung am bestehenden Code handelt – jede Codeänderung erhält ihren eigenen Branch.

Branching ist unkompliziert und ermöglicht Teams eine mühelose Zusammenarbeit in einer zentralen Codebasis. Wenn ein Entwickler einen Branch erstellt, verfügt er im Endeffekt über eine eigene isolierte Version der Codebasis, in der er Änderungen vornimmt. Für ein Agile-Team bedeutet dies, dass das Entwicklerteam durch das Aufteilen von Features in User Storys Aufgaben unabhängig voneinander bearbeiten kann und effizienter am selben Code, aber in verschiedenen Repositorys arbeiten kann. Arbeit wird nicht doppelt erledigt, und die einzelnen Mitarbeiter können sich auf kleine Aufgabenteile in vom Haupt-Repository getrennten Repositorys konzentrieren, ohne dass zu viele Abhängigkeiten den Entwicklungsprozess ausbremsen.

Profitipp:

Neben dem Task-Branching gibt es in Git noch weitere Branching-Typen, die sich nicht gegenseitig ausschließen. Du kannst zum Beispiel Branches für ein Release erstellen. Diese ermöglichen den Entwicklern die Stabilisierung und das Härten eines bestimmten Release, ohne anderen Entwicklern in die Quere zu kommen, die an zukünftigen Releases arbeiten.

Nachdem du einen Release-Branch erstellt hast, musst du regelmäßige Merges in deinen Master-Branch durchführen, um sicherzustellen, dass deine Arbeit am Feature auch in zukünftigen Releases enthalten ist. Um den Aufwand möglichst gering zu halten, solltest du den Release-Branch am besten nicht zu weit entfernt vom Release-Datum erstellen.

Git-Branches im Detail | Atlassian Agile Coach

Tipp 2: Mehrere Branches können individuell getestet werden – das solltest du ausnutzen!

Sobald Branches bereit für den Code-Review sind, übernimmt Git eine weitere wichtige Rolle im Workflow der Agile-Entwicklungs: das Testen. Erfolgreiche Agile-Teams führen Code-Reviews durch und richten automatisierte Tests ein (Continuous Integration oder Continuous Development). Zur Unterstützung bei Code-Reviews und Tests können die Entwickler über einen Pull-Request problemlos den Rest des Teams benachrichtigen, dass die Branch-Aufgabe bereit für den Review ist. Einfach gesagt ist ein Pull-Request eine Möglichkeit, einen anderen Entwickler darum zu bitten, einen Merge deiner Branches in den Master-Branch durchzuführen, und ihm mitzuteilen, dass die Tests gestartet werden können.

Mit den richtigen Tools kann dein Continuous Integration-Server deine Pull-Requests erstellen und testen, bevor du einen Merge durchführst. So kannst du sicher sein, dass dein Merge keine Probleme verursachen wird. Diese Sicherheit erleichtert das Retargeting von Bugfixes und Konflikten, da Git die Unterschiede zwischen dem Branch und der Master-Codebasis seit der Trennung der Branches kennt.

Profitipp:

Ein langfristiger Feature-Branch, der nicht in den Master-Branch gemergt wird, kann die Agilität und die Iterationsfähigkeit beeinträchtigen. Bedenke bei langfristigen Feature-Branches immer, dass du praktisch über zwei voneinander abweichende Versionen deiner Codebasis verfügst, was zu weiteren Bugfixes und Konflikten führt. Die beste Lösung sind kurzfristige Feature-Branches. Dazu solltest du User Storys in kleinere Tasks aufteilen, Sprints sorgfältig planen und Code frühzeitig mergen, um ihn als Dark Features auszuliefern.

Tipp 3: Git sorgt in der agilen Entwicklung für Transparenz und Qualität

Bei Git und Agile dreht sich alles um Effizienz, Tests, Automatisierung und Agilität insgesamt. Sobald du einen Branch in den Master-Branch gemergt hast, ist dein Agile-Workflow abgeschlossen. Entsprechend bedeutet das Mergen von Code durch Pull-Requests, dass du nach Fertigstellung des Codes dokumentieren kannst, dass deine Arbeit geprüft wurde, dass andere Teammitglieder den Code bestätigt haben und dass er bereit zum Release ist. So bleiben Agile-Teams schnell und haben das nötige Vertrauen für häufige Releases – ein Merkmal erfolgreicher Agile-Teams.

Profitipp:

Ein regelmäßiger Release-Rhythmus ist in der Agile-Entwicklung entscheidend. Damit Git in deinem Agile-Workflow funktioniert, musst du dafür sorgen, dass dein Master immer grün ist. Dies bedeutet, dass bei Features, die noch nicht fertig sind, auf den nächsten Release gewartet werden muss. Bei kürzeren Release-Zyklen ist dies auch kein Problem.

Weiter geht's
Branching