Git-Branching-Strategien fuer 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 Aenderung auf einem eigenen kurzlebigen Branch liegt. Fuegen Sie Umgebungs- oder Release-Branches erst hinzu, wenn Packaging, parallele Release-Zuege oder ein grosses 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 taeglich Steuer; waehlen 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, zusammenfuehrt und befoerdert. Auf Salesforce wiegt sie aus drei Gruenden schwerer: Ihre Quelle der Wahrheit ist deklarative Metadaten (XML) neben Apex, Ihre Umgebungen sind Orgs und Sandboxes statt Servern, und Sie koennen das gesamte Projekt nicht lokal kompilieren, also erfolgt die Validierung gegen eine Org. Das macht zwei Fragen unausweichlich, die andere Stacks aufschieben koennen: welcher Branch fuer welche Sandbox steht, und wie Sie Konflikte in Dateien wie Profilen und Flows loesen, die viele Leute anfassen. Salesforce DevOps Center, jetzt allgemein verfuegbar, stuetzt 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 Aenderung zweigt von main ab und kehrt ueber einen Pull Request zurueck. Am einfachsten zu betreiben, und die beste Voreinstellung fuer die meisten Teams.
• Branch pro Umgebung. Ein langlebiger Branch pro Org (dev, uat, main), befoerdert durch Merge stromaufwaerts. Intuitiv und leicht zu visualisieren, aber anfaellig fuer Drift, wenn ein Hotfix eine Stufe ueberspringt.
• Release Branch. Ein kurzlebiger release/x, aus main geschnitten, um eine Version zu stabilisieren, waehrend neue Arbeit weiterlaeuft. Nuetzlich, wenn Sie Aenderungen zu geplanten Releases buendeln.
• Gitflow. Feature-, Develop-, Release- und Hotfix-Branches zusammen. Stark fuer parallele Versionen und ISV-Packaging, schwer fuer 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 taeglich, Partial Copy alle 5 Tage und Full alle 29 Tage, daher kann eine Full-Sandbox fuer die finale UAT nicht Ihr schnelles Integrationsziel sein. Eine gaengige, reibungsarme Zuordnung:

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

Die vollstaendige 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 grosse XML-Dateien, die viele Aenderungen anfassen, daher beschaedigen 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 fuer Zeile zu mergen. Wir gehen das durch in wie Sie einen Salesforce-bewussten Git-Merge-Driver einrichten.

Welche Branching-Strategie sollte Ihr Team waehlen?

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

• Eine Produktions-Org, haeufige Releases: Feature Branch von main. Fuegen Sie nichts weiter hinzu.
• Geplante Releases mit einem Freeze: Feature Branches plus ein Release Branch.
• ISV oder mehrere unterstuetzte Versionen: Gitflow oder ein Package-pro-Branch-Modell.

Wenn zwei Optionen gleich gueltig aussehen, waehlen Sie die einfachere; Sie koennen spaeter immer aufstocken. Unsere Entscheidungsregel fuer Git-Branching-Strategien macht daraus eine einzige Frage, die Sie in einem Meeting beantworten koennen. Und weil jedes Modell irgendwann eine schlechte Aenderung ausliefert, koppeln Sie es an einen Plan zum Zurueckrollen fehlgeschlagener Salesforce-Deployments.

Wo passt das Tooling hinein?

Die Strategie ist Git; das Tool automatisiert die Befoerderung 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 gedraengt 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 fuer Salesforce?

Fuer 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 fuer Integration und finale Validierung.

Ist Gitflow eine gute Wahl fuer Salesforce?

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

Wie vermeide ich Profil-Merge-Konflikte?

Halten Sie Branches kurzlebig, bevorzugen Sie Permission Sets gegenueber Profilen, und nutzen Sie einen Salesforce-bewussten Merge-Driver, damit XML nach Struktur statt nach Zeile zusammenfuehrt.