Git-Branches Salesforce-Sandboxes zuordnen

Git-Branches Salesforce-Sandboxes zuzuordnen heißt zu entscheiden, welcher Branch die Source of Truth für jede Umgebung ist, damit eine Änderung über geprüfte Merges statt Org-zu-Org-Deployments von Dev in die Produktion wandert. Langlebige Branches werden persistenten Sandboxes zugeordnet; kurzlebige Feature-Branches Scratch Orgs und Developer-Sandboxes. Stimmt die Zuordnung, ist Beförderung nur ein Merge. Stimmt sie nicht, erbst du Merges von Merges und stille Drift.

Dieser Leitfaden behandelt die Zuordnungsmechanik, nicht die Wahl des Modells. Wenn du noch zwischen Trunk-based, GitFlow und Branch pro Umgebung schwankst, beginne mit Git-Branching-Strategien für Salesforce-Teams: eine Entscheidungsregel, und komm dann hierher zurück, um es mit deinen Orgs zu verdrahten.

Welcher Sandbox-Typ stützt welchen Branch?

Ein Branch ist nur real, wenn es eine Org gibt, in die man ihn deployen und testen kann. Ordne jeden Branch dem Sandbox-Typ zu, der zu seinem Zweck und seiner Refresh-Kadenz passt:

• Feature-Branch zu einer Scratch Org oder Developer-Sandbox. Wegwerfbar, pro Ticket erstellt, beim Merge verworfen.
• Integration-Branch zu einer Developer-Pro-Sandbox, wo Feature-Arbeit landet und gemeinsam getestet wird.
• UAT-Branch zu einer Partial-Copy- oder Full-Sandbox, damit Business-User gegen repräsentative Daten testen.
• Main-Branch zur Produktion, stets geschützt und nur über einen geprüften Merge aktualisiert.

Die Refresh-Kadenz begrenzt, wie viele langlebige Branches du wirklich stützen kannst. Salesforce setzt Mindest-Refresh-Intervalle von einem Tag für Developer und Developer Pro, fünf Tagen für Partial Copy und 29 Tagen für Full, ein Branch, den du nicht refreshen kannst, ist also ein Branch, dem du nicht trauen kannst.

Wie fließt die Beförderung zwischen Branches?

Beförderung ist ein Merge, kein Redeploy. Eine Änderung startet auf einem Feature-Branch und steigt die Kette hinauf, sobald sie jedes Tor passiert:

1. Ziehe einen Feature-Branch, entwickle gegen seine Scratch Org oder Developer-Sandbox.
2. Öffne einen Pull Request in den Integration-Branch; beim Merge Deploy in die Integrations-Sandbox.
3. Merge Integration in den UAT-Branch für die Business-Freigabe in der Partial-Copy- oder Full-Sandbox.
4. Merge UAT in Main; das Deploy in die Produktion ist dieselbe Metadata, die UAT bereits bestanden hat.

Die Regel, die den meisten Schmerz erspart: lass einen Branch, der der Produktion zugeordnet ist, nie einen direkten Commit annehmen. Alles erreicht ihn über einen geprüften Merge, sodass die Branch-Historie auch deine Deployment-Historie ist.

Wie hält Source Tracking einen Branch und seine Org im Gleichtakt?

Source Tracking erfasst, welche Metadata sich in einer Sandbox geändert hat, sodass du diese Änderungen in den Branch ziehst, statt einen vollständigen Retrieve zu raten. Deploye aus git in die zugeordnete Org und lass Source Tracking alles markieren, was ein Admin direkt in dieser Org geändert hat. Diese Schleife hält den Branch als Source of Truth und verhindert, dass Org und Branch leise auseinanderlaufen.

Daten, org-weite Einstellungen und Lizenzen leben außerhalb des Repos, die Zuordnung deckt also nur Metadata ab. Behandle jene als Umgebungskonfiguration, die du separat seedest, nicht als etwas, das ein Branch befördern kann.

Was sind die häufigen Zuordnungsfehler?

• Ein langlebiger Branch pro Developer-Sandbox. Jeder zusätzliche langlebige Branch ist ein weiteres Merge-Ziel, das driftet. Halte Feature-Branches kurz und wegwerfbar.
• Org zu Org deployen und es Beförderung nennen. Wenn der Branch nicht das ist, was du deployst, hört die Branch-Historie auf, dem Live-Stand zu entsprechen.
• Einen UAT-Branch mit einer Developer-Sandbox stützen. Ohne repräsentative Daten testet die Freigabe das Falsche und übersieht datengeformte Bugs.
• Admins die Produktion direkt ändern lassen. Ein Klick in der Produktion, der nie in git landet, macht deine Zuordnung beim nächsten Deploy zur Fiktion.

Lass die Zuordnung sich selbst erzwingen

Eine Zuordnung, die in einem Onboarding-Dokument lebt, bricht in der ersten vollen Release-Woche. Serpent arbeitet ticketbasiert mit Git im Hintergrund, sodass der Branch, seine Sandbox und der Beförderungspfad aus dem Ticket kommen statt aus dem Gedächtnis. Weitere Pipeline-Leitfäden finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Brauche ich einen Branch pro Sandbox?

Nein. Ordne langlebige Branches nur persistenten Umgebungen wie Integration, UAT und Produktion zu. Nutze kurzlebige Feature-Branches für Scratch- und Developer-Orgs.

Welche Sandbox sollte meinen UAT-Branch stützen?

Eine Partial-Copy- oder Full-Sandbox, damit Business-User gegen repräsentative Daten testen statt gegen eine leere Developer-Org.

Wie wird eine Änderung zwischen Umgebungen befördert?

Über einen geprüften Merge von einem Branch zum nächsten, gefolgt von einem Deploy aus git in die zugeordnete Org. Beförderung ist ein Merge, kein Redeploy aus einer Org.

Was hält einen Branch und seine Org davon ab, auseinanderzulaufen?

Source Tracking plus Deploy-aus-git. Der Branch bleibt Source of Truth, und jede direkte Org-Änderung taucht als getrackter Diff zum Abgleich auf.

Welches Branching-Modell ordne ich zuerst zu?

Wähle das Modell vor der Zuordnung. Siehe unsere Entscheidungsregel zur Wahl nach Teamgröße und Sandbox-Topologie.