Git-Integration in Power Platform: Deine Solution als lesbarer Code im Repo

„Wer hat diese Business Rule geändert?” Auf diese Frage gibt dir eine Dataverse-Umgebung bis heute keine ehrliche Antwort. Die Solution ist der Stand — es gibt keine Historie, keinen Diff, keinen „git blame”. Seit April 2025 schließt Microsoft genau diese Lücke: Die Git-Integration in Power Platform (allgemein verfügbar) bindet eine Umgebung direkt an ein Git-Repo und legt deine Solution als lesbaren Quelltext dort ab — mit Commit-Historie, Diff und Rollback.

Das klingt nach dem Ende einer langen Bastelphase (export → unpack → committen per Pipeline). Ist es teilweise auch. Aber im Marketing-Satz „GitHub integration and deploy from Git” stecken Wörter, die für den ausgerollten Stand nicht stimmen — dazu ein paar bewusste Grenzen, die man kennen muss. Der Reihe nach.

Das Problem: die Wahrheit liegt in der Umgebung, nicht im Repo

Klassischer ALM-Alltag ohne Source Control an der Umgebung:

Zwei Maker arbeiten in derselben Dev-Umgebung an derselben Solution. Wer wann was geändert hat, weiß niemand.
Ein Formular ist plötzlich anders. Rückgängig? Nur, wenn du zufällig einen alten Export-ZIP herumliegen hast.
Der „Stand” existiert genau einmal — live in der Umgebung. Ein Review vor dem Deployment ist ein Klick-durch, kein Diff.

Wer es sauber wollte, baute sich das selbst: pac solution export, dann pac solution unpack, das Ergebnis in ein Repo committen, per Azure DevOps Pipeline automatisieren. Funktioniert — ist aber Infrastruktur, die jedes Team neu zusammenschraubt.

Was du zuerst siehst

In einer dafür freigeschalteten Umgebung taucht im Solution-Bereich ein neuer Punkt auf: die Umgebung lässt sich mit einem Git-Repo verbinden. Nach dem Verbinden bekommst du pro Solution einen Source-Control-Status: geänderte Komponenten, ein Commit-Knopf, und zu jedem Commit einen Link, der dich in Azure DevOps direkt auf den Diff führt.

Schema: Beim Commit landet die Solution als aufgeteiltes, lesbares YAML im Repo (solutions/, publishers/, entities/, workflows/, canvasapps/) — eine neue Spalte taucht im Pull Request als grüner Diff auf.

Der entscheidende Unterschied zum Bastelweg: Du exportierst nichts mehr. Das Committen passiert aus der Umgebung heraus, und im Repo liegt kein ZIP, sondern eine aufgeklappte, menschenlesbare Ordnerstruktur.

Was technisch wirklich passiert

Beim Verbinden bindest du die Umgebung an genau einen Branch eines Azure-DevOps-Repos. Ab da gilt:

Änderungen entstehen in der Umgebung, nicht im Repo. Du bearbeitest Solution-Komponenten wie gewohnt im Maker-Portal. Das Repo ist die Ablage, nicht der Editor — direkte Änderungen an den Dateien im Repo sind nicht der vorgesehene Weg.
Ein Commit schreibt die Solution als lesbares YAML in den Branch. Statt des kryptischen customizations.xml bekommst du eine aufgeteilte Ordnerstruktur:

/
├─ solutions/
│  └─ <SolutionUniqueName>/        # Solution-Metadaten
├─ publishers/
│  └─ <PublisherUniqueName>/       # Publisher-Info
├─ entities/                       # Tabellen, Spalten, Forms, Views …
├─ workflows/                      # Flows, Business Rules, klassische Workflows
└─ canvasapps/                     # Canvas Apps

Diese Dateien sind diff-bar. Ein Pull Request zeigt dann wirklich „diese drei Spalten kamen dazu, diese View wurde geändert” statt einer XML-Wand.

Zwei ehrliche Einschränkungen zum Format: Dieses YAML entsteht durch die native Git-Integration (bzw. pac solution clone/sync, PAC ≥ 2.4.1) — ein klassisches pac solution unpack liefert weiter XML (Solution.xml, Customizations.xml). Und nicht jede Komponente wird YAML: Security Roles, globale Option Sets, Dashboards, Site Maps und Ribbon-Anpassungen bleiben intern XML, Environment-Variable-Werte liegen als JSON vor. Der Diff-Vorteil greift also vor allem bei Tabellen, Spalten, Formularen und Ansichten.

3. Nur unmanaged. Ins Git gehört ausschließlich dein unmanaged Quellstand. Ob am Ende managed oder unmanaged herauskommt, entscheidet sich erst beim Build/Release — nicht im Repo. (Das ist dieselbe Trennung wie bei Connection References: Logik reist, der Zielzustand wird beim Deployment festgelegt.)

Umgebung (unmanaged)  ──Commit──▶  Git-Branch (YAML)  ──pac pack / Pipeline──▶  managed Artefakt  ──▶  UAT/Prod

Aus dieser Mechanik folgt direkt, welche zwei Reflexe hier danebengehen.

Die naheliegende, aber falsche Lösung

Reflex 1: „Endlich — ich häng meine Prod-Solution an Git und arbeite ab jetzt so.” Falsch — aber nicht wegen Preview (das Feature ist GA). Die Git-Integration ist per Design nur für Dev-Umgebungen gedacht; die Doku ist ausdrücklich: nicht an Test- oder Prod-Umgebungen binden. Dorthin kommt kein Git-Branch, sondern ein aus dem Quellstand gebautes managed Artefakt über Pipelines. Git ist der Entwicklungs- und Reviewort, nicht der Prod-Kanal.

Reflex 2: „Dann committe ich eben selektiv nur die eine Änderung.” Geht nicht. Ein Commit nimmt alle anstehenden Änderungen der Solution zusammen — kein Cherry-Picking einzelner Komponenten wie im normalen Git. Wer das ignoriert, schiebt beim schnellen Fix ungewollt halbfertige Nachbararbeit mit hoch.

Und der dritte, der im Marketing steckt: „GitHub integration”. Der Release-Plan verkauft „GitHub integration and deploy from Git”. Der real ausgerollte Stand unterstützt als Provider nur Azure DevOps. GitHub kann über das Provider-Modell später dazukommen — heute ist es nicht da. Wer die Roadmap-Überschrift für den Ist-Zustand hält, plant an der Realität vorbei.

Die belastbare Lösung: der saubere Ablauf

Wenn du die Git-Integration heute sinnvoll nutzt, dann so:

1. Voraussetzungen schaffen

Managed Environments für Dev und Ziel — die Git-Integration setzt Managed Environments voraus, kein Nice-to-have.
System Administrator in der Dataverse-Umgebung.
Ein Azure DevOps Git-Repo, Zugriffslevel mindestens Basic — angelegt und initialisiert (sonst fehlt der Default-Branch).
Zugriff über make.powerapps.com — die Git-Integration steckt in der regulären Solutions-Oberfläche.

2. Umgebung an einen Feature-Branch binden

Ein Branch pro Umgebung. Für einen PR-Workflow trennst du die Bindung und verbindest neu auf einen anderen Branch — das ist der dokumentierte Weg, um Feature-Branches zu bedienen.

Schema: Git ist die Quelle, nicht der Deployment-Kanal — aus der Umgebung committen, mit pac solution pack ein managed Artefakt bauen, über Pipelines ins Ziel binden.

3. In der Umgebung arbeiten, dann committen

Komponenten wie gewohnt im Maker bearbeiten. Wenn ein sinnvoller Stand erreicht ist: committen. Programmatisch stehen dafür die Dataverse-Messages bereit — nützlich, wenn du das in eigene Automatisierung gießt:

CommitToGit          # lokalen Solution-Stand als Commit in den Branch schreiben
RefreshChangesFromGit# Änderungen aus dem Branch sichtbar machen
PullChangesFromGit   # Änderungen aus dem Branch in die Umgebung ziehen

Bei divergierenden Ständen fragt dich das Feature, welche Seite gewinnt: den Stand aus der Umgebung behalten oder die Version aus Source Control ziehen. (Große Dateien splittet die Integration automatisch, um das 17-MB-pro-Datei-Limit von Azure DevOps einzuhalten — darum musst du dich nicht kümmern.)

Schema: Weichen Umgebung und Branch ab, entscheidest du, welche Seite gewinnt — plus die drei Dataverse-Messages CommitToGit, RefreshChangesFromGit, PullChangesFromGit.

4. Deployen wie gehabt — über das Build-Artefakt

Das Repo ist die Quelle, nicht der Deployment-Kanal. Zum Ausrollen baust du aus dem Branch ein Artefakt und importierst es ins Ziel:

# Aus dem ausgecheckten Branch die Solution zu einem managed Artefakt packen
pac solution pack \
  --zipfile ./out/CustomerService_managed.zip \
  --folder ./ \
  --packagetype Managed

# Import ins Ziel — mit Deployment-Settings für Connection References & Environment Variables
pac solution import \
  --path ./out/CustomerService_managed.zip \
  --settings-file ./deploymentSettings.prod.json \
  --activate-plugins true --publish-changes true

In einer Azure DevOps Pipeline oder mit GitHub Actions ist das derselbe Schritt, nur automatisiert: pac solution pack baut das Artefakt, pac solution import (oder die Pipelines in Power Platform) bringt es ins Ziel. Die Bindung der Connection References läuft dabei genau wie gewohnt über die Deployment-Settings — dazu der eigene Beitrag unten.

Diagnose- und Entscheidungscheckliste

Wann heute schon Git-Integration, wann (noch) der klassische pac-Weg?

Test- oder Prod-Umgebung binden? Nicht tun — die Git-Integration ist für Dev-Umgebungen; nach Prod geht ein managed Artefakt über Pipelines.
Sind Dev und Ziel Managed Environments? Wenn nicht, fehlt die Voraussetzung — erst umstellen.
Azure DevOps vorhanden? GitHub als Provider gibt es (noch) nicht. Wer GitHub-nativ arbeitet, bleibt vorerst bei pac pack + GitHub Actions ohne die eingebaute Umgebungs-Bindung.
Brauchst du selektive Commits? Dann passt das „alles zusammen”-Commit-Modell nicht — kleinere Solutions schneiden hilft.
Willst du Diffs im PR? Genau dafür ist das lesbare YAML da — hier spielt die Integration ihren Vorteil aus.

Grenzen und die unbequemen Teile

Nur Azure DevOps. Trotz „GitHub integration”-Überschrift im Release-Plan ist GitHub als Provider im ausgerollten Stand nicht dabei. Provider-Modell = „später vielleicht”.
Nur für Dev-Umgebungen (per Design). Ausdrücklich nicht an Test- oder Prod-Umgebungen binden — dorthin geht nur das gebaute managed Artefakt über Pipelines.
Nur unmanaged. Ins Repo gehört der Quellstand; managed entsteht erst beim Build.
Keine selektiven Commits. Alle Änderungen wandern zusammen.
Ein Branch pro Bindung. Branch-Wechsel = Bindung trennen und neu verbinden.
Kein Cross-Tenant. Umgebung und Repo im selben Tenant-Kontext.
Änderungen nur aus der Umgebung. Direktes Editieren der Repo-Dateien ist nicht der vorgesehene Weg.
Legacy-Objekttypen. Einzelne ältere Komponententypen werden (noch) nicht unterstützt; Developer-Tools-Deployment für das neue Format ist noch nicht überall verfügbar.

Kurz: Die Git-Integration ist der überfällige, eingebaute Ersatz für den export/unpack/commit-Bastelweg — mit echtem Mehrwert bei Historie und Diff, und seit April 2025 allgemein verfügbar. Sie bleibt an Azure DevOps und Managed Environments gebunden und ist bewusst auf Dev-Umgebungen beschränkt: Der Weg nach Prod läuft weiter über ein gebautes managed Artefakt und Pipelines, nicht über einen Branch-Merge. Für saubere Feature-Arbeit, Reviews am lesbaren Diff und Team-Zusammenarbeit ist sie jetzt der Standardweg — nur „deploy from Git” direkt aus dem Repo und GitHub-Support fehlen weiterhin.

Stand: Juli 2026. Die Git-Integration ist seit April 2025 allgemein verfügbar (Public Preview seit November 2024); Provider bleibt Azure DevOps. Microsoft entwickelt das Feature laufend weiter — im Zweifel die zugehörige Learn-Seite zur Git-Integration prüfen.