Feature Branch

Was ist ein Feature Branch?

Wenn mehrere Developer an derselben Codebasis arbeiten, wird es schwierig, ohne Überschneidungen oder das Überschreiben von Änderungen zu arbeiten.

Die einfache Lösung besteht darin, eine Kopie der Codebasis zu erstellen, sodass jeder Developer an seinen eigenen Features arbeiten kann. Stell dir das wie einen Baum vor, bei dem der Master Branch als Stamm (auch als Main oder Mainline bezeichnet) dient und jede Kopie der Codebasis als Branch bezeichnet wird.

Wenn das Team das Feature als fertig betrachtet, wird dieser Branch wieder in den Stamm integriert. Der Prozess der Einbeziehung von Änderungen in den Masterstamm wird als Merging bezeichnet. Die Entwicklung und das Merging von Feature Branches werden in Versionskontrollsoftware wie GitHub, GitLab oder Bitbucket durchgeführt.

Der Vorteil von Feature Branching

Einfach ausgedrückt, wenn ein Developer an einem Feature arbeiten möchte, erstellt er einen Branch, in dem er alle Arbeiten an diesem Feature durchführt. Sobald das Feature fertig ist, teilt er diese Änderungen mit dem Rest des Teams, indem er eine Mainline-Integration durchführt.

Zusammenarbeit

Ein Feature Branch ermöglicht es Developern, effizient um eine zentrale Codebasis herum zusammenzuarbeiten, indem Änderungen an einem spezifischen Branch vorgenommen werden, sodass andere Developer nicht beeinträchtigt werden. Ein Feature Branch ermöglicht es agilen Teams auch, Bugs zu erkennen, da jeder Bug in einem eigenen Branch existiert. So können sie sehen, welche Themen in Arbeit und welche bereit zur Veröffentlichung sind. Dies geschieht durch Pull Requests, bei denen Änderungen besprochen werden können, bevor sie in den Master Branch gemergt werden, was den Developern die Möglichkeit gibt, diese Änderungen zu überprüfen. Zusammengefasst lautet das grundlegende Prinzip dieses Konzepts laut Martin Fowler:

Alle Arbeiten für ein Feature sollen in einem eigenen Branch durchgeführt werden und in die Mainline integriert werden, wenn das Feature fertig ist.

Der Nachteil von Feature Branching

Merge-Konflikte

Einerseits hilft Feature-fokussierte Entwicklung bei der Verwaltung groß angelegter Projekte, indem Ressourcen je nach den Bedürfnissen der einzelnen Features zugewiesen werden.

Andererseits kann es schwierig werden, Tausende von Branches zu verwalten. Wenn ein Feature Branch zu lange in der Entwicklung bleibt, kann es beim Merging zu Konflikten mit anderen Branches kommen. Ein Branch kann für sich allein perfekt funktionieren, aber nach dem Merging nicht mehr, weil sich die Mainline in der Zwischenzeit geändert hat.

Dies führt zu verzögerten Einführungen, da oft viele Pull Requests analysiert werden müssen, um Merge-Konflikte zu lösen. Außerdem können die restlichen Teammitglieder keine Änderungen sehen, bis der Branch gemergt ist, was ebenfalls zu Verzögerungen führt.

Ein Beispiel: Wenn ein Feature eines Developers nicht unabhängig veröffentlicht werden kann, bevor das Feature eines anderen Developers fertig ist, werden mehrere unabhängige Arbeitsströme so miteinander verknüpft, dass eines nicht ohne das andere veröffentlicht werden kann. Dadurch können diese Features nicht unabhängig voneinander veröffentlicht werden.

Die Lösung scheint durch den Einsatz von Feature Branching einfach, aber es entstehen schwierige Merges, insbesondere wenn Developer getrennt an verschiedenen Branches zu unterschiedlichen Zeiten arbeiten, ohne kontinuierliche Integration und ohne kontinuierlich Code in einen gemeinsamen Branch zu pushen.

Zusammengefasst besteht das Risiko größerer Merge-Konflikte, wenn parallele Feature Branches signifikante Änderungen enthalten. Dies führt zu dem, was als „Merge Hell“ bezeichnet wird. Dies kann vermieden werden, wenn man mehrmals am Tag in die Mainline integriert. Diese alternative Methode wird als „trunk-based development“ bezeichnet.

Feature Branching mit Feature Flags

Die beste Lösung ist die Verwendung von Feature Flags und die Praxis der Continuous Integration. Feature Branches werden oft mit Feature Flags gekoppelt, um die Aktivierung und Deaktivierung eines Features zu ermöglichen und es einer ausgewählten Benutzergruppe anzuzeigen. Beim Feature Branching ist das Feature Release Management an Code Deployments gebunden.

Hier kommen Feature Flags ins Spiel. Mit Flags können unvollständige Änderungen in einen gemeinsamen Branch gepusht werden, ohne die Veröffentlichung dieses Branches zu blockieren. Entwickler können also das fertige Feature veröffentlichen, während unvollständige Features deaktiviert bleiben. So haben Entwickler die volle Kontrolle über die Feature-Lebenszyklen, ohne auf Code Deployments angewiesen zu sein.

Zusammenfassend lässt sich sagen, dass Feature Branching eine nützliche Technik ist, um alle Arbeiten von der gemeinsamen Codebasis fernzuhalten, bis sie abgeschlossen sind. Um optimale Ergebnisse mit Feature Branching zu erzielen, ist es oft notwendig, Features innerhalb eines Tages oder höchstens zwei Tagen abzuschließen.

Bei der Arbeit über Wochen und Monate ist die Wahrscheinlich größer, dass sich Probleme entwickeln. In anderen Situationen, in denen Teams eine effiziente Produktveröffentlichung durch schnelles Feedback anstreben, setzen sie auf Continuous Integration, was Merge-Konflikte durch kontinuierliches Merging aller Änderungen in die Mainline verringert.

Developer, die diese Methode anwenden, pushen Code so schnell wie möglich direkt in den Stamm, normalerweise in weniger als einem Tag, sodass ein Branch, wenn er erstellt wird, nur kurzlebig ist.