Git-Branching-Strategien fuer Salesforce-Teams: eine Entscheidungsregel

Kurz gesagt: Waehlen Sie Ihr Branching-Modell aus zwei Eingaben, Teamgroesse 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 fuer UAT: ein Release-Branch je Release, mehr nicht. Darueber, 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 Aenderung in die naechste Umgebung befoerdert 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 Ausfuehren 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 ueber einen Pull Request zurueck. Die wenigsten beweglichen Teile, die wenigsten Konflikte, die haerteste Disziplin.

GitFlow

main fuer ausgelieferten Code, develop fuer integrierte Arbeit, dazu Release- und Hotfix-Branches. Gebaut fuer geplante Releases und fuer die Pflege einer laufenden Version, waehrend die naechste entsteht. Kostet einen zusaetzlichen 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 Befoerderung wird zum Merge zwischen Umgebungsbranches, was ordentlich klingt und in Merges von Merges plus regelmaessigem Cherry-Picking endet.

Welche Salesforce-Zwaenge brechen den Lehrbuchrat?

Hier hoeren die meisten Branching-Artikel auf, und hier faellt die eigentliche Entscheidung.

• Ein Branch gibt Ihnen keine Org. Umgebungen sind knapp und traege. Salesforce setzt Mindestintervalle fuer den Refresh von einem Tag fuer Developer und Developer Pro, fuenf Tagen fuer Partial Copy und 29 Tagen fuer Full. Die Zahl langlebiger Branches, die Sie wirklich testen koennen, begrenzt Ihr Sandbox-Bestand, nicht Ihr Git-Koennen.
• Metadaten werden abgerufen, nicht geschrieben. Admins aendern etwas in einer Org und jemand holt es spaeter. Ein langlebiger Branch laesst sich nicht mit deklarativer Arbeit versoehnen, die nie in Git gelandet ist.
• Manches hat gar keinen Branch. Org-weite Einstellungen, Lizenzen, bestimmte Konfiguration und saemtliche Datensaetze leben ausserhalb des Repos. Ein Modell, das jede Umgebungsdifferenz in Git vermutet, luegt Sie leise an.
• Es gibt keine Feature Flags fuer Klicks. Klassisches Trunk-based stuetzt sich auf Schalter, um unfertige Arbeit zu mergen. Deklarative Konfiguration hat oft keinen Schalter, das Salesforce-Aequivalent ist also: Metadaten ausrollen und die Permission-Set-Zuweisung bis zum Go-live zurueckhalten.
• Merge-Kosten sind asymmetrisch. Profiles, Permission Sets und Layouts kollidieren weit schlimmer als Apex. Jede zusaetzliche Lebenswoche eines Branches vervielfacht diese Kosten und draengt Salesforce staerker zu kurzen Branches als uebliche 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 fuer 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 muessen das laufende Release patchen, waehrend das naechste 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 Pruefstand eine Scratch Org, Umgebungsbranches modellieren also das Falsche.
5. Branch pro Umgebung. Gerechtfertigt, wenn ein Branch ein pruefbares Spiegelbild des Org-Zustands sein muss, also aus regulatorischen Gruenden und nicht aus Liefervorliebe. Gehen Sie mit offenen Augen hinein: Cherry-Picking wird Routine und Drift wird unsichtbar.

Auffaellig ist, wie wenig die Release-Kadenz vorkommt. Kadenz ist ein Ergebnis Ihrer Sandbox-Topologie, keine unabhaengige Eingabe, und Teams, die nach Wunschkadenz waehlen, 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 hoert 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 Kuriositaet. Dort stecken meist die Ueberraschungen.
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. Laenger braucht eine Paketgrenze oder ein Berechtigungstor, keinen laengeren Branch.
5. Behalten Sie genau einen Release-Branch, und nur wenn Sie wirklich ein laufendes Release pflegen, waehrend das naechste entsteht.

Damit das Modell haelt

Das Modell, das den Kontakt mit einem echten Team ueberlebt, 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 Befoerderungspfad aus dem Ticket kommen statt aus dem Gedaechtnis. Weitere Pipeline-Leitfaeden finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Ist Trunk-based fuer 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 fuer Merges von Merges und dauerhaftes Cherry-Picking.

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 zurueck in main mergen, damit der Fix beim naechsten Release nicht verloren geht.

Aendert sich das Modell fuer 2GP-Paketteams?

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