Git-Branching für agile Teams

Mit dem Wechsel zu Git begeben sich Softwareteams auf eine ganz neue Ebene der Agilität – hier erfährst du, warum

Sarah Goff-Dupont Sarah Goff-Dupont

Nachdem die Entwickler nun von den für die zentralisierte Versionskontrolle typischen klobigen Code Freezes und monolithischen Mega-Merges erlöst wurden, können sie WIP-Aufgaben isolieren und leicht Builds in schmalen vertikalen Schnitten erstellen. Branching und Merging sind mit Git so mühelos, dass viele Teams für jede implementierte User Story oder Fehlerkorrektur neue Branches erstellen. Dieses Modell ist auf dem besten Weg zum neuen Goldstandard für agile Teams zu werden – zu Recht!

Schnapp dir eine Tüte Popcorn und schau dir eines unserer beliebtesten Webinare aller Zeiten an. Du erhältst darin Antworten auf folgende Fragen: 

  • Wie hilft ein Branch-pro-Vorgang-Modell den Teams bei der kontinuierlichen Auslieferung von funktionierendem Code?
  • Wie sieht der Workflow der Entwickler aus?
  • Wie lässt sich das Modell in deine bestehenden Verfahren bezüglich Continuous Integration und Code-Review einbinden?
  • Was muss bei der Beurteilung dieses Modells abgewogen werden?

Sehen und Lernen

Q&A-Runde

Klingt doch gut, oder? 

Wenn du es wie ich machst, wirst du wohl nicht die gesamte Q&A-Runde am Ende des Webinars ansehen. Das ist schon in Ordnung, du kannst es ruhig zugeben. Deshalb habe ich für ein paar Fragen ein Transkript erstellt, das du überfliegen und nach Lust und Laune lesen kannst. 

F: Wie verfährst du mit den Versionsnummern in all diesen Branches? Wie unterscheidest du diese Codezeilen? 

A: Die Teams benennen den Branch normalerweise nach der entsprechenden Release-Version. Als beispielsweise das Team, das Stash entwickelt, seinen Release 2.9 vorbereitete, hat es einen stabilen Branch namens "stash-2.9" erstellt, damit in seinem Repository klar ersichtlich ist, um was für einen Branch es sich handelt. Du kannst die Methode der Namensgebung anwenden, die für dein Team am besten funktioniert – aber füge auf jeden Fall irgendwo die Versionsnummer ein.

F: In deinen Beispielen hat an jedem Branch eine Person gearbeitet. Wie sollte die Branch-Struktur und Benennung aussehen, wenn zwei Personen an einer Story arbeiten?

A: Es ist möglich, dass zwei Personen am selben Issue-Branch arbeiten. Dafür muss nur die Grundregeln der Etikette für gemeinsame Branches eingehalten werden: z. B. kein Rebasing und generell keine Änderungen an der lokalen Branch-Kopie, die der anderen Person Kopfschmerzen bereiten könnten. Eine andere Möglichkeit wäre, dass jeder Mitarbeiter seinen eigenen Branch für das Issue erstellt und für die Branches regelmäßig Merges durchgeführt werden. Die Benennung kann beispielsweise folgendermaßen aussehen: <Name/Initialien>-<Vorgangsschlüssel>-<Beschreibung> (z. B. sarah-DEV-1234-Unternehmensname-auf-Homepage-falsch-geschrieben). Im Prinzip unterscheiden sich die Benennungen kaum von denen der Branches, an denen nur ein Entwickler arbeitet.

F: Wie gehst du mit Abhängigkeiten um, wenn du nicht für jede Änderung einen Merge in einen einzigen Branch durchführst, sobald sie an einem Entwicklungsbranch vorgenommen wurde?

A: Wenn es sich bei den abhängigen Teilen bei beiden um WIP-Teile handelt, sollten die Entwickler, die daran arbeiten, für ihre Änderungen häufige Merges durchführen. Dies ist in Git möglich, ohne zuerst einen Merge in einen zentralen Branch durchzuführen – du und der andere Entwickler könnt eure Branches direkt mergen. Eine weitere Option ist die Nutzung des gemeinsamen Integrations-Branch, über den wir vorhin gesprochen haben.

F: Vor einer Weile hat Martin Fowler sich gegen Feature Branching ausgesprochen, da es seiner Meinung nach die Überarbeitung erschwert und während der Lebensdauer des Feature Branch zwar eine kontinuierliche Entwicklung stattfindet, aber keine Continuous Integration.

A: Ja, ich kenne seinen Beitrag zu diesem Thema. Er ist schon etwas älter – aus dem Jahr 2008 oder 2009, glaube ich. Ich denke, dass unsere Möglichkeiten zur Ausführung von CI in Feature Branches sich seither ein ganzes Stück weiterentwickelt haben. Wie ich im Teil des Webinars zu den Überlegungen gesagt habe, bedeutet ein Branch-pro-Vorgang-Ansatz, dass du keine reine CI betreibst. Du führst eine kontinuierliche Entwicklung und kontinuierliche Tests durch, aber keine Continuous Integration. Du kannst allerdings der reinen CI sehr nahekommen, indem du einen gemeinsamen Integrationsbranch in dein Branching-Schema einfügst.