Rebase hält deinen Branch frisch

Ich arbeite in mehreren Softwareteams, und sehr oft committen wir direkt auf unseren Main-Branch. Typisch für meine Teams: kein develop-Branch und nicht mal Release-Zyklen. Wir releasen stattdessen regelmäßig.

In einem großen Konzern ist das nicht üblich, aber in wendigen, softwaregetriebenen Firmen ist es ziemlich normal.

Die Frage ist, wie wir das hinbekommen, ohne uns gegenseitig auf die Füße zu treten.

Git

Es läuft auf git und Agilität hinaus. Das Werkzeug, mit dem wir die Versionsverwaltung machen, und ein kleiner Splitter der Denkweise hinter unserem Projektmanagement.

Git ist schlicht eine Methode, Unterschiede zwischen Kopien zu erkennen. Enthält die Produktivkopie A, arbeitet Joe an B und Sally an C, kann Git die Unterschiede ermitteln und die Kopien ohne Konflikt zusammenführen.

Schwierig wird es, wenn Arbeit lange dauert und Beiträge in unterschiedlichen Abständen committed werden.

Dann kommt rebase ins Spiel. git rebase origin/main stellt sicher, dass meine Arbeit, also die Arbeit, die von main abzweigt, auf dem Stand aller Beiträge meiner Kollegen ist. Das ist das Richtige, und es spart später Nacharbeit, wenn Konflikte auftauchen. Es sorgt dafür, dass meine Arbeit aktuell ist, bevor sie in den main-Branch gemergt wird. Die Quelle der Wahrheit.

Flow

Viele Teams halten sich an git-flow. Atlassian hat es sehr gut definiert, es braucht keine weitere Erklärung.

Aber ich halte es nicht für perfekt.

In der Softwareentwicklung neigen wir manchmal dazu, Prozesse, die uns heilig sind, zu automatisieren, damit wir produktiver werden. Das funktioniert gut, hat aber eigene Schwächen.

Ein Feature-Branch ist zum Beispiel ein gutes Mittel, um ein bestimmtes Feature zu testen. Jeder Commit kann also ein Quasi-Deployment auslösen, das zeigt, was die neue Funktion kann.

Das unschöne Ergebnis: Der Feature-Branch stößt einen automatisierten Prozess an, der dieses Demo-Feature deployt.

Das ist teuer und unbefriedigend.

Work-Branches

Ein einfacher Ansatz, den ich in meinem Team einführe, sind work/*-Branches. Sie funktionieren wie Feature-Branches, liegen aber in einem eigenen Namensraum, damit die automatisierten Prozesse sie nicht anfassen.

Work-Branches tragen das Präfix work/ und sind ausdrücklich von den automatisierten Pipelines ausgeschlossen. Sie sind der „Auto-Save“ der Versionsverwaltung.

Ich ermutige meine Teams, hauptsächlich in ihrem work/*-Branch zu arbeiten und Features erst dann in ihren feature/*-Branch zu mergen, wenn eine Pipeline laufen soll.

Fazit

Ich muss einräumen, dass ich das erst seit kurzer Zeit mit meinen Teams praktiziere. Trotz des Mehraufwands, feature/*- und work/*-Branches auseinanderzuhalten, scheint es gut zu funktionieren.

Mir ist klar, dass auch Block-Steps ein gutes Mittel sind, unnötige Deployments und Builds zu vermeiden. Damit erreichst du Ähnliches, aber leider gibt es sie in den Umgebungen nicht, in denen ich arbeite.

Ich freue mich immer über Feedback und vielleicht Vorschläge für neue Arbeitsweisen. Wenn du Ideen hast, melde dich.