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.

Sobald Branches bereit für den Code-Review sind, übernimmt Git eine weitere wichtige Rolle im agilen Entwicklungs-Workflow – 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 eine Pull-Anfrage problemlos den Rest des Teams benachrichtigen, dass die Branch-Aufgabe bereit für den Review ist. Einfacher ausgedrückt: Eine Pull-Anfrage ist eine Möglichkeit, einen anderen Entwickler darum zu bitten, einen Merge deiner Branches in den Haupt-Branch durchzuführen, und ihm mitzuteilen, dass die Tests gestartet werden können.

Mit den richtigen Tools kann dein Continuous Integration-Server deine Pull-Anfragen 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 Haupt-Codebasis seit der Trennung der Branches kennt.

Bei Git und Agile dreht sich alles um Effizienz, Tests, Automatisierung und Agilität insgesamt. Sobald du einen Branch in den Haupt-Branch gemergt hast, ist dein Agile-Workflow abgeschlossen. Entsprechend bedeutet das Mergen von Code durch Pull-Anfragen, 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.