Git-Branching-Strategien für Salesforce-Teams: So wählen Sie

Kurz gesagt: Eine Git-Branching-Strategie ist das Regelwerk, das entscheidet, wo Salesforce-Metadatenänderungen leben, bevor sie die Produktion erreichen. Die meisten Teams sollten mit einem einfachen Feature-Branch-Modell auf einem einzigen, stets deploybaren Main-Branch beginnen und Komplexität erst hinzufügen, wenn ihre Release-Kadenz oder Teamgröße es verlangt. Es gibt keine einzige richtige Antwort, nur die passende für Ihre Kadenz, Ihr Team und dafür, wie Ihre Branches auf Sandboxes abbilden.

Was ist eine Git-Branching-Strategie, und warum braucht Salesforce eine?

Eine Branching-Strategie legt fest, wie Arbeit isoliert, überprüft und gemergt wird. In klassischer Software ist das gut ausgetretenes Gelände. Salesforce fügt zwei Feinheiten hinzu: Ihre Quelle der Wahrheit sind deklarative Metadaten, die aus Orgs gezogen werden, statt Code, den Sie an einem Ort schreiben, und Salesforce empfiehlt, dem Org-zu-Org-Change-Set-Modell hin zu Git-Releases zu entwachsen. Das macht die Branch-zu-Sandbox-Abbildung, nicht das Branching-Muster selbst, zu dem Teil, den Teams am häufigsten falsch machen.

Bevor Sie ein Muster wählen, einigen Sie sich auf drei Dinge: welcher Branch die Produktion repräsentiert, wie eine Änderung promotet wird und wie Sie sich erholen, wenn ein Merge schiefgeht. Können Sie das nicht beantworten, ist der Mustername Dekoration.

Was sind die wichtigsten Branching-Strategien für Salesforce?

Vier Muster decken fast jedes Salesforce-Team ab. Sie tauschen Einfachheit gegen Kontrolle, je weiter Sie die Liste hinuntergehen.

Feature-Branch-Modell

Ein langlebiger main-Branch hält die neuesten deploybaren Metadaten. Jede Änderung bekommt einen kurzlebigen Branch, öffnet einen Pull Request und mergt nach der Review zurück.

• Am besten für: Kleine bis mittlere Teams, die heute starten wollen.
• Stärke: Einfach, schnell einzuführen, hält main stets releasebar.
• Kosten: Weniger Struktur zum Koordinieren mehrerer paralleler Releases.

Environment-Branch-Modell (Branch pro Org)

Jeder Branch bildet auf eine Salesforce-Umgebung ab: dev, uat, main für die Produktion. Änderungen werden durch Hochmergen der Kette promotet.

• Am besten für: Teams, deren mentales Modell bereits org-basiert ist und die wollen, dass Branches Sandboxes spiegeln.
• Stärke: Die Pipeline ist offensichtlich; jeder Merge ist eine Promotion.
• Kosten: Langlebige Umgebungs-Branches driften, und eine einzelne Änderung aus einem Batch herauszupicken ist schmerzhaft.

GitFlow

Dedizierte develop-, release-, feature- und hotfix-Branches mit strengen Regeln, 2010 für geplante Software-Releases geschaffen.

• Am besten für: Große Teams mit formalen, kalenderbasierten Release-Trains und schwerer Governance.
• Stärke: Maximale Kontrolle und klare Trennung laufender Arbeit.
• Kosten: Viele bewegliche Teile; Overkill für die meisten Salesforce-Läden und langsam für häufige Releases.

Trunk-based Development

Alle committen hinter sehr kurzlebigen Branches auf main, mit Automatisierung als Sicherheitsnetz. Es ist die Richtung, zu der hochfrequente Teams tendieren.

• Am besten für: Teams mit reifer CI, starken automatisierten Tests und einem echten Rollback-Pfad.
• Stärke: Schnellster Fluss, kleinste Batches, geringste Merge-Drift.
• Kosten: Unversöhnlich ohne zuvor eingerichtete automatisierte Validierung und Rollback.

Welche Branching-Strategie sollten Sie wählen?

Passen Sie das Muster an Ihre Realität an, nicht an das Ideal eines Blogs:

• Neu in der Versionskontrolle? Feature-Branch auf einem einzigen Main-Branch. Nichts anderes verdient seine Komplexität noch.
• Denken Sie in Sandboxes? Environment-Branch, aber halten Sie die Branches, wo möglich, kurzlebig und automatisieren Sie die Promotions.
• Regulierte, kalenderbasierte Releases? GitFlow gibt Ihnen die Kontrolle, die die Prüfer wollen.
• Tägliches Ausliefern mit solider Automatisierung? Trunk-based, sobald Ihre Tests und Ihr Rollback vertrauenswürdig sind.

Der entscheidende Faktor ist selten das Diagramm. Es ist, ob Ihre Metadaten sauber mergen und ob jeder Branch ein Zuhause in einer echten Sandbox hat. Wir gehen tiefer auf diese Abbildung ein in wie Sie Git-Branches auf Salesforce-Sandboxes abbilden, und legen eine klare Entscheidungsregel dar in diesem Entscheidungsregel-Leitfaden.

Welche Salesforce-spezifischen Fallen brechen eine Branching-Strategie?

Hier hört generischer Git-Rat auf zu genügen. Achten Sie auf:

• Metadaten, die nicht sauber mergen. Profile und manche XML-Metadaten erzeugen rauschende Diffs; bevorzugen Sie Permission Sets und kleine, fokussierte Änderungen.
• Langlebige Umgebungs-Branches, die driften. Je länger ein Branch fern von main lebt, desto härter der eventuelle Merge. Halten Sie sie kurz oder gleichen Sie oft ab.
• Kein Rollback-Plan. Eine Branching-Strategie ohne getestete Möglichkeit, einen schlechten Merge rückgängig zu machen, ist eine Strategie für langsame, ängstliche Releases. Kombinieren Sie sie mit einem echten Wiederherstellungspfad, wie wir es in Rollback-Strategien für fehlgeschlagene Deployments behandeln.
• Branches ohne Sandbox. Jeder Branch, den eine Promotion anvisiert, braucht eine Org zum Validieren, sonst ist die Pipeline Theater.

Sie können den Rest unserer praktischen Playbooks in der SF-Guides-Bibliothek durchstöbern. Wenn Sie bereit sind, eine echte Pipeline von Change Sets wegzubewegen, ist unser Migrationspfad darauf ausgelegt, schrittweise statt eine Big-Bang-Neuschrift zu sein.

FAQ

Was ist die beste Git-Branching-Strategie für ein kleines Salesforce-Team?

Beginnen Sie mit einem Feature-Branch-Modell auf einem einzigen, stets deploybaren Main-Branch. Es ist das einfachste Muster, das Ihnen dennoch Review, Nachvollziehbarkeit und saubere Releases gibt.

Ist GitFlow gut für Salesforce?

Nur für große Teams mit formalen, kalenderbasierten Release-Trains. Seine vielen Branches fügen Kontrolle hinzu, die die meisten Salesforce-Teams nicht brauchen, und verlangsamen häufige Releases.

Sollten Salesforce-Branches eins zu eins auf Sandboxes abbilden?

Environment-Branch-Modelle tun genau das, was intuitiv ist, aber halten Sie die Branches kurzlebig, um Drift zu vermeiden. Jeder Branch, zu dem Sie promoten, braucht eine echte Org zum Validieren.

Wie hängt eine Branching-Strategie mit Rollback zusammen?

Direkt. Branches entscheiden, wie Änderungen ankommen; Rollback entscheidet, wie Sie eine schlechte rückgängig machen. Eine Strategie ohne getesteten Rollback-Pfad führt zu langsamen, vorsichtigen Releases.