Git-Branching-Strategien für Salesforce-Teams: ein praktischer Leitfaden

Kurze Antwort: Die meisten Salesforce-Teams sollten mit einem Feature-Branch-Modell beginnen, bei dem main stets die Produktion abbildet und jede Änderung auf einem eigenen kurzlebigen Branch liegt. Fügen Sie Umgebungs- oder Release-Branches erst hinzu, wenn Packaging, parallele Release-Züge oder ein großes Team es erzwingen. Der Salesforce-spezifische Teil ist nicht der Git-Graph, sondern die Zuordnung jedes langlebigen Branches zu einer Sandbox und der Umgang mit Metadaten-Merge-Konflikten.

Die Branching-Strategie ist der Punkt, an dem die meisten Salesforce-DevOps-Setups einrasten oder unter ihrem eigenen Gewicht zusammenbrechen. Kopieren Sie ein komplexes Modell, das Sie nicht brauchen, und jeder Entwickler zahlt täglich Steuer; wählen Sie eines, das zu Ihrem Release-Rhythmus passt, und Git tritt in den Hintergrund.

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

Eine Branching-Strategie ist der Satz von Regeln, wie Ihr Team Branches erstellt, zusammenführt und befördert. Auf Salesforce wiegt sie aus drei Gründen schwerer: Ihre Quelle der Wahrheit ist deklarative Metadaten (XML) neben Apex, Ihre Umgebungen sind Orgs und Sandboxes statt Servern, und Sie können das gesamte Projekt nicht lokal kompilieren, also erfolgt die Validierung gegen eine Org. Das macht zwei Fragen unausweichlich, die andere Stacks aufschieben können: welcher Branch für welche Sandbox steht, und wie Sie Konflikte in Dateien wie Profilen und Flows lösen, die viele Leute anfassen. Salesforce DevOps Center, jetzt allgemein verfügbar, stützt sich darauf, indem es GitHub oder Bitbucket als einzige Quelle der Wahrheit behandelt.

Welche Git-Branching-Strategien nutzen Salesforce-Teams wirklich?

Vier Muster decken fast jedes Team ab:

• Feature Branch (GitHub Flow). main ist immer auslieferbar; jede Änderung zweigt von main ab und kehrt über einen Pull Request zurück. Am einfachsten zu betreiben, und die beste Voreinstellung für die meisten Teams.
• Branch pro Umgebung. Ein langlebiger Branch pro Org (dev, uat, main), befördert durch Merge stromaufwärts. Intuitiv und leicht zu visualisieren, aber anfällig für Drift, wenn ein Hotfix eine Stufe überspringt.
• Release Branch. Ein kurzlebiger release/x, aus main geschnitten, um eine Version zu stabilisieren, während neue Arbeit weiterläuft. Nützlich, wenn Sie Änderungen zu geplanten Releases bündeln.
• Gitflow. Feature-, Develop-, Release- und Hotfix-Branches zusammen. Stark für parallele Versionen und ISV-Packaging, schwer für ein Team mit einer einzigen Produktion.

Wie ordnen Sie Branches den Salesforce-Sandboxes zu?

Verbinden Sie jeden langlebigen Branch mit einer Sandbox, die zu seiner Aufgabe passt, und lassen Sie die Refresh-Grenzen die Form bestimmen. Salesforce aktualisiert Developer- und Developer-Pro-Sandboxes täglich, Partial Copy alle 5 Tage und Full alle 29 Tage, daher kann eine Full-Sandbox für die finale UAT nicht Ihr schnelles Integrationsziel sein. Eine gängige, reibungsarme Zuordnung:

1. feature/*-Branches zu Developer- oder Developer-Pro-Sandboxes zum Bauen.
2. Ein Integrations-Branch zu einer Partial-Copy-Sandbox für kombiniertes Testen.
3. main gegen eine Full-Sandbox validiert, bevor es die Produktion erreicht.

Die vollständige Mechanik steht in wie Sie Git-Branches den Salesforce-Sandboxes zuordnen.

Wie gehen Sie mit Metadaten-Merge-Konflikten um?

Hier tut Salesforce-Branching wirklich weh. Profile, Permission Sets und Flows sind große XML-Dateien, die viele Änderungen anfassen, daher beschädigen naive Merges sie. Halten Sie Branches kurzlebig, damit sie weniger auseinanderlaufen, teilen Sie Profile in Permission Sets auf, und nutzen Sie einen Salesforce-bewussten Merge-Driver, der das XML versteht, statt es Zeile für Zeile zu mergen. Wir gehen das durch in wie Sie einen Salesforce-bewussten Git-Merge-Driver einrichten.

Welche Branching-Strategie sollte Ihr Team wählen?

Richten Sie das Modell an Ihrem Release-Rhythmus aus, nicht an einem Organigramm:

• Eine Produktions-Org, häufige Releases: Feature Branch von main. Fügen Sie nichts weiter hinzu.
• Geplante Releases mit einem Freeze: Feature Branches plus ein Release Branch.
• ISV oder mehrere unterstützte Versionen: Gitflow oder ein Package-pro-Branch-Modell.

Wenn zwei Optionen gleich gültig aussehen, wählen Sie die einfachere; Sie können später immer aufstocken. Unsere Entscheidungsregel für Git-Branching-Strategien macht daraus eine einzige Frage, die Sie in einem Meeting beantworten können. Und weil jedes Modell irgendwann eine schlechte Änderung ausliefert, koppeln Sie es an einen Plan zum Zurückrollen fehlgeschlagener Salesforce-Deployments.

Wo passt das Tooling hinein?

Die Strategie ist Git; das Tool automatisiert die Beförderung entlang dieser. Plattformen wie Copado, Gearset und AutoRABIT setzen jeweils ein Branching-Modell voraus, also bewahrt Sie die vorherige Wahl Ihres Modells davor, in das eines anderen gedrängt zu werden. Wenn Sie ein bestehendes Branching-Setup auf eine neue Pipeline verschieben, behandelt unser Migrationsleitfaden, wie Sie Ihre Branches ohne Neuschreiben mitnehmen. Weitere Salesforce-DevOps-Anleitungen finden Sie in unseren SF Guides.

FAQ

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

Für die meisten Teams ein Feature-Branch-Modell mit einem stets auslieferbaren Main-Branch. Es ist am einfachsten zu betreiben und skaliert, bis Packaging oder parallele Releases etwas Komplexeres erzwingen.

Sollte jede Salesforce-Sandbox einen eigenen Branch haben?

Nur langlebige Branches sollten Sandboxes zugeordnet sein. Kurzlebige Feature Branches teilen sich Developer-Sandboxes; reservieren Sie Partial Copy und Full für Integration und finale Validierung.

Ist Gitflow eine gute Wahl für Salesforce?

Gitflow passt zu ISVs und Teams, die mehrere Versionen gleichzeitig pflegen. Für eine einzige Produktions-Org fügt es meist mehr Branches hinzu, als der Release-Rhythmus braucht.

Wie vermeide ich Profil-Merge-Konflikte?

Halten Sie Branches kurzlebig, bevorzugen Sie Permission Sets gegenüber Profilen, und nutzen Sie einen Salesforce-bewussten Merge-Driver, damit XML nach Struktur statt nach Zeile zusammenführt.