Git-Branching-Strategien für Salesforce-Teams: eine Entscheidungsregel

Kurz gesagt: Wählen Sie Ihr Branching-Modell aus zwei Eingaben, Teamgröße und Sandbox-Topologie, und aus nichts sonst. Unter etwa vier Mitwirkenden mit nur Developer-Sandboxes: ein Main-Branch und kurzlebige Feature-Branches. Zwischen vier und zehn mit einer Partial Copy für UAT: ein Release-Branch je Release, mehr nicht. Darüber, oder mit einer Full Sandbox und festem Change-Fenster, verdient GitFlow seine Zeremonie. Branch pro Umgebung ist eine Compliance-Entscheidung, keine technische.

Was entscheidet eine Branching-Strategie wirklich?

Drei Dinge, und nur drei: wo laufende Arbeit lebt, wie eine Änderung in die nächste Umgebung befördert wird, und was wahr sein muss, bevor etwas die Produktion erreicht. Alles andere ist Diagrammschmuck.

Salesforce-Teams verrechnen sich hier, weil der allgemeine Engineering-Rat etwas voraussetzt, das auf der Plattform nicht gilt: dass ein Branch Ihnen auch einen Ort zum Ausführen gibt.

Was sind die drei Modelle im Klartext?

Trunk-based mit kurzlebigen Feature-Branches

Ein langlebiger Branch, main, der immer abbildet, was Produktion sein sollte. Feature-Branches leben Tage, nicht Wochen, und kommen über einen Pull Request zurück. Die wenigsten beweglichen Teile, die wenigsten Konflikte, die härteste Disziplin.

GitFlow

main für ausgelieferten Code, develop für integrierte Arbeit, dazu Release- und Hotfix-Branches. Gebaut für geplante Releases und für die Pflege einer laufenden Version, während die nächste entsteht. Kostet einen zusätzlichen dauerhaften Branch und viel Mergen.

Branch pro Umgebung

Ein Branch je Org: Dev, UAT, Staging, Produktion. Meist das Erste, was Teams bauen, weil es aussieht wie die Org-Landschaft, die sie ohnehin haben. Die Beförderung wird zum Merge zwischen Umgebungsbranches, was ordentlich klingt und in Merges von Merges plus regelmäßigem Cherry-Picking endet.

Welche Salesforce-Zwänge brechen den Lehrbuchrat?

Hier hören die meisten Branching-Artikel auf, und hier fällt die eigentliche Entscheidung.

• Ein Branch gibt Ihnen keine Org. Umgebungen sind knapp und träge. Salesforce setzt Mindestintervalle für den Refresh von einem Tag für Developer und Developer Pro, fünf Tagen für Partial Copy und 29 Tagen für Full. Die Zahl langlebiger Branches, die Sie wirklich testen können, begrenzt Ihr Sandbox-Bestand, nicht Ihr Git-Können.
• Metadaten werden abgerufen, nicht geschrieben. Admins ändern etwas in einer Org und jemand holt es später. Ein langlebiger Branch lässt sich nicht mit deklarativer Arbeit versöhnen, die nie in Git gelandet ist.
• Manches hat gar keinen Branch. Org-weite Einstellungen, Lizenzen, bestimmte Konfiguration und sämtliche Datensätze leben außerhalb des Repos. Ein Modell, das jede Umgebungsdifferenz in Git vermutet, lügt Sie leise an.
• Es gibt keine Feature Flags für Klicks. Klassisches Trunk-based stützt sich auf Schalter, um unfertige Arbeit zu mergen. Deklarative Konfiguration hat oft keinen Schalter, das Salesforce-Äquivalent ist also: Metadaten ausrollen und die Permission-Set-Zuweisung bis zum Go-live zurückhalten.
• Merge-Kosten sind asymmetrisch. Profiles, Permission Sets und Layouts kollidieren weit schlimmer als Apex. Jede zusätzliche Lebenswoche eines Branches vervielfacht diese Kosten und drängt Salesforce stärker zu kurzen Branches als übliche Software.

Wie lautet also die Entscheidungsregel?

1. Ein bis drei Mitwirkende, nur Developer-Sandboxes, kein festes Release-Datum. Main plus kurzlebige Feature-Branches. Alles Weitere ist Zeremonie, die Sie im dritten Monat aufgeben.
2. Vier bis zehn Mitwirkende, eine Partial Copy für UAT, Release je Sprint. Main, kurzlebige Feature-Branches und ein Release-Branch je Release. Widerstehen Sie einem dauerhaften develop, Ihr Sandbox-Bestand rechtfertigt ihn nicht.
3. Mehr als zehn Mitwirkende, oder eine Full Sandbox, oder ein festes Change-Fenster, oder Sie müssen das laufende Release patchen, während das nächste entsteht. GitFlow. Jetzt kauft die Zeremonie etwas Echtes.
4. Paket- und ISV-Teams. Branchen Sie nach Paketversion, nicht nach Umgebung. Ihre Release-Einheit ist die Paketversion und Ihr Prüfstand eine Scratch Org, Umgebungsbranches modellieren also das Falsche.
5. Branch pro Umgebung. Gerechtfertigt, wenn ein Branch ein prüfbares Spiegelbild des Org-Zustands sein muss, also aus regulatorischen Gründen und nicht aus Liefervorliebe. Gehen Sie mit offenen Augen hinein: Cherry-Picking wird Routine und Drift wird unsichtbar.

Auffällig ist, wie wenig die Release-Kadenz vorkommt. Kadenz ist ein Ergebnis Ihrer Sandbox-Topologie, keine unabhängige Eingabe, und Teams, die nach Wunschkadenz wählen, bekommen einen Prozess, den ihre Umgebungen nicht tragen.

Wie kommt man ohne Big Bang vom Branch pro Umgebung weg?

1. Legen Sie ab heute keine neuen Umgebungsbranches mehr an. Das Modell hört auf zu wachsen, bevor es zu schrumpfen beginnt.
2. Gleichen Sie main mit der Produktion ab und behandeln Sie die Differenz als echtes Backlog, nicht als Kuriosität. Dort stecken meist die Überraschungen.
3. Machen Sie aus Umgebungsbranches Deployment-Ziele in der Pipeline statt Git-Branches. Die Umgebung bleibt, sie ist nur kein Ort mehr, an dem Code lebt.
4. Begrenzen Sie das Alter von Feature-Branches auf einen Sprint. Länger braucht eine Paketgrenze oder ein Berechtigungstor, keinen längeren Branch.
5. Behalten Sie genau einen Release-Branch, und nur wenn Sie wirklich ein laufendes Release pflegen, während das nächste entsteht.

Damit das Modell hält

Das Modell, das den Kontakt mit einem echten Team überlebt, ist das von der Pipeline erzwungene, nicht das im Onboarding-Dokument. Muss sich ein Berater die Branch-Regeln merken, brechen sie in der ersten vollen Release-Woche. Serpent arbeitet ticketbasiert mit Git im Hintergrund, sodass Branch, Pull Request und Beförderungspfad aus dem Ticket kommen statt aus dem Gedächtnis. Weitere Pipeline-Leitfäden finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Ist Trunk-based für ein Admin-Team realistisch?

Ja, und meist einfacher als GitFlow, weil es nur einen Branch zu verstehen gibt. Entscheidend ist die Disziplin kurzer Branches, nicht Git-Routine.

Brauchen wir einen Git-Branch pro Sandbox?

Nein. Eine Sandbox ist ein Deployment-Ziel. Ein Branch je Org ist die Hauptursache für Merges von Merges und dauerhaftes Cherry-Picking. Zur richtigen Zuordnung siehe Git-Branches Salesforce-Sandboxes zuordnen.

Wie lange darf ein Salesforce-Feature-Branch leben?

Tage. Ein Sprint ist die Obergrenze. Danach kosten Metadaten-Drift und Profilkonflikte mehr, als der Branch einbringt.

Wie funktionieren Hotfixes bei Trunk-based?

Vom letzten ausgelieferten Commit abzweigen, korrigieren, validieren, ausrollen und sofort zurück in main mergen, damit der Fix beim nächsten Release nicht verloren geht.

Ändert sich das Modell für 2GP-Paketteams?

Ja. Nach Paketversion branchen und in Scratch Orgs testen. Umgebungsbranches modellieren eine Org-Landschaft, in die ein Paketteam gar nicht ausliefert.