Databricks Git Integration richtig nutzen
Erfahre, wie du mit der Git-Integration in Databricks Repos deine Notebook- und Python-Projekte versionssicher, nachvollziehbar und kollaborativ entwickelst. Lerne bewährte Branching-Strategien, Review-Flows und Best Practices für produktives Arbeiten im Team und effiziente Deployments im Data Lakehouse.
Databricks bietet eine extrem leistungsfähige Umgebung für Data Engineering, Machine Learning und Analytics - aber wer produktiv im Team arbeitet, weiß: Ohne saubere Versionskontrolle wird's schnell chaotisch.
Früher war Git in Databricks eher ein Nebenschauplatz. Heute ist es integraler Bestandteil - mit vollwertiger Git-Integration über Databricks Repos. Dadurch lassen sich Branches, Pull Requests und Reviews direkt im Workspace nutzen - ohne ständig zwischen IDE, Terminal und Notebook hin- und herzuspringen.
In diesem Artikel zeige ich dir, wie wir Git in Databricks konkret im Alltag nutzen:
- mit klaren Branching-Strategien
- integrierten Review-Flows
- und Best Practices, die sich bei echten Projekten bewährt haben.
Ob du allein arbeitest oder im Team - dieser Artikel hilft dir, deinen Databricks-Code nachvollziehbar, testbar und gemeinsam wartbar zu machen.
Was sind Databricks Repos und wie funktionieren sie?
Databricks Repos sind die Brücke zwischen Notebook-basierter Entwicklung und klassischer Git-Versionskontrolle. Statt Code nur im Workspace zu pflegen, kannst du mit Repos deine Notebooks direkt an ein Git-Repository binden - inklusive voller Kontrolle über Commits, Branches und Merges.
🔗 Was genau ist ein Databricks Repo?
Ein Repo in Databricks ist ein Verzeichnis in deinem Workspace, das direkt mit einem externen Git-Repository (z. B. auf GitHub, GitLab oder Azure Repos) verbunden ist.
Sobald du es eingebunden hast, kannst du:
- direkt im Notebook Änderungen committen und pushen
- zwischen Branches wechseln
- neue Branches erstellen
- Pull Requests außerhalb von Databricks erstellen oder mit CI/CD verknüpfen
🧱 Wie ist ein Repo aufgebaut?
Wenn du ein Repo z. B. auf main klonst, sieht es im Workspace so aus:
💡 Wichtig: Das Repo ist ein Workspace-Ordner, aber der Inhalt liegt in deinem Git-Repository - nicht im internen Workspace-Dateisystem (wie bei DBFS oder %run-Strukturen früher).
🧩 Hinweis zur Strukturierung:
Ob du pro dbx Bundle (also pro Job/Asset) ein eigenes Repository anlegst, oder mehrere Bundles in einem gemeinsamen Repo verwaltest, ist dir überlassen.
In vielen Projekten ist ein Repo pro Bundle sinnvoll - insbesondere, wenn die Deployments unabhängig voneinander laufen. In anderen Fällen kann es effizienter sein, mehrere Bundles in einem Monorepo zu bündeln.
Wichtig ist nur: Konsistenz im Team und saubere Trennung nach Funktionalität - ganz gleich, für welchen Weg du dich entscheidest.
✅ Unterstützte Funktionen direkt in der UI:
- Repo verbinden (GitHub, GitLab, Azure Repos)
- Branch wechseln
- Dateien stage'n, committen und pushen
- Merge-Konflikte erkennen (aber nicht direkt auflösen - dafür brauchst du den Git-Anbieter)
⚠️ Einschränkungen, die du kennen solltest:
| Einschränkung | Bedeutung |
|---|---|
| Kein Pull Request direkt in Databricks | PRs musst du im Git-Provider erstellen (z. B. GitHub UI) |
| Kein Rebase in der UI | Nur merge-basierte Flows sinnvoll |
| Keine direkte Auflösung von Konflikten | Dazu Git CLI oder IDE nötig |
| Jeder Benutzer hat eigene Repos | Es gibt keinen zentralen Shared Git Workspace |
Branching-Strategien für Teams: Entwickler-Branches, Feature-Flows & Environments
Sobald mehrere Personen an einem Databricks-Projekt arbeiten, braucht es eine klare Struktur: Wer arbeitet woran? Wie fließt Code in die Produktion? Wie vermeiden wir Konflikte?
Mit der Git-Integration in Databricks lässt sich das gut abbilden - aber es braucht eine durchdachte Branching-Strategie.
👥 Entwickler-Branches als isolierte Arbeitsbereiche
In der Praxis hat es sich bewährt, für jeden Entwickler einen eigenen Dev-Branch zu verwenden. So entstehen keine Konflikte bei gleichzeitiger Arbeit - insbesondere nicht bei parallelem Editieren von Notebooks.
Beispielhafte Struktur:
🔹 Jeder Entwickler arbeitet isoliert in seinem eigenen Branch
🔹 Änderungen werden regelmäßig in develop zusammengeführt
🔹 Der main-Branch bleibt immer produktionsbereit
Diese Struktur lässt sich hervorragend mit dbx oder dem Databricks CLI kombinieren - zum Beispiel über eigene Deployments aus databricks.yml, abhängig vom Branchnamen.
🌿 Optional: Feature Branches für größere Tasks
Zusätzlich oder alternativ kannst du bei größeren Features eigene Feature-Branches verwenden:
Diese Branches sind besonders sinnvoll, wenn du:
- mehrere Tage an einem isolierten Thema arbeitest
- später Pull Requests gezielt reviewen willst
- CI/CD automatisch anstoßen möchtest (z. B. über Branch-Namen)
Auch hier gilt: Merge erfolgt idealerweise über einen Pull Request zurück auf develop.
📌 Branch ≠ Umgebung, aber oft gekoppelt
Viele Teams koppeln Branches logisch an Deployments:
| Branch | Zielumgebung |
|---|---|
| main | Produktion |
| develop | Integration / Staging |
| dev/* | individuelle Entwicklerumgebung |
| feature/* | temporäre Preview-Deployments |
💡 Mit dbx oder dem Bundle-Deployment lässt sich diese Kopplung hervorragend automatisieren - z. B. mit Umgebungsfiltern in Pipelines.
🔁 Pull Requests als zentrale Review-Stelle
Der Merge zurück auf develop oder main erfolgt idealerweise immer über einen Pull Request.
So bleibt der Code nachvollziehbar, reviewbar - und CI/CD kann automatisch Tests oder Deployments anstoßen.
Diese Branching-Strategie funktioniert besonders gut in Databricks-Repos, da jeder Entwickler seinen eigenen Workspace-Pfad nutzen kann, ohne mit anderen in Konflikt zu geraten.
Von Notebook-Änderung bis Pull Request
Mit der Git-Integration in Databricks kannst du direkt im Workspace entwickeln - ohne auf Komfort wie Versionierung, Branching oder Pull Requests zu verzichten.
Hier zeige ich dir den konkreten Ablauf, wie du in einem Entwickler-Branch arbeitest und deine Änderungen sauber in den Haupt-Workflow einbringst.
🔄 Schritt-für-Schritt-Workflow
1. Repo klonen oder bestehendes Repo öffnen
Im Databricks UI:
→ Navigiere zu Repos > Add Repo
→ Füge die URL deines Git-Repositories ein
→ Wähle deinen Branch aus (z. B. dev/samuel)
Databricks erstellt daraus ein Workspace-Verzeichnis mit direkter Git-Verbindung.
2. Notebook oder Python-Dateien bearbeiten
Du arbeitest wie gewohnt:
- Notebooks editieren
- Python-Skripte im app/-Verzeichnis anpassen
- Neue Ressourcen oder Jobs im resources/-Ordner ergänzen
Alle Änderungen landen im geklonten Repo - lokal im Workspace, aber gekoppelt mit Git.
3. Änderungen committen und pushen
Im Header Deines Notebooks auf den Git-Tab klicken. Dort kannst du:
- Änderungen sehen (Diff-Ansicht)
- Commit-Nachricht eingeben
- Push zum Remote-Repo durchführen
4. Pull Request erstellen (außerhalb von Databricks)
Da PRs aktuell nicht in Databricks erstellt werden können, wechselst du zu GitHub, GitLab oder Azure Repos und:
- öffnest einen PR von dev/samuel nach develop
- fügst Reviewer hinzu
- triggert ggf. eine CI/CD-Pipeline
5. Merge nach Review → Deployment
Nach dem erfolgreichen Review wird der PR gemerged.
Der CI/CD-Prozess übernimmt:
- Validierung (z. B. dbx validate, Unit-Tests)
- Deployment (z. B. via Azure DevOps Pipeline in develop- oder prod-Umgebung)
- Optionale Benachrichtigung (Teams, Mail)
🧠 Tipp: Lokale Entwicklung + Repos kombinieren
Du kannst auch mit lokaler IDE + Git + dbx arbeiten und nur für Notebook-Tests in Databricks springen. So bekommst du das Beste aus beiden Welten - ohne auf Notebook-Komfort oder CI/CD zu verzichten.
Best Practices & Stolperfallen im Git-Alltag auf Databricks
Die Git-Integration in Databricks ist ein großer Fortschritt für kollaboratives Arbeiten - aber wie bei jedem Tool gibt es Feinheiten, die du beachten solltest, um Konflikte, Chaos oder doppelte Arbeit zu vermeiden.
Hier sind die wichtigsten Empfehlungen aus der Praxis:
✅ Best Practices
1. Klare Namenskonventionen für Branches
Nutze sprechende Branch-Namen - idealerweise mit Ticket- oder Themenbezug:
➡ So findest du dich auch nach Wochen noch zurecht - und CI/CD-Systeme lassen sich leicht auf Branch-Muster konfigurieren.
2. Arbeiten mit kleinen, überschaubaren Commits
Mach lieber mehrere kleine Commits als einen „All-in-One"-Snapshot.
Das erleichtert Pull Requests, Reviews und Troubleshooting enorm.
3. Deployment-Umgebungen strikt trennen
Vermeide es, Branches direkt in main zu mergen oder dort Notebook-Experimente zu machen.
Halte dich an den Flow:
→ dev/* → develop → main
und nutze databricks.yml, um die passende Umgebung zu konfigurieren.
4. Nutze Repos bewusst - kein Wildwuchs
- Lege nicht für jedes kleine Skript ein neues Repo an
- Aber auch nicht alle Bundles in ein einziges Git-Monster
- Lieber ein Repo pro „Anwendungsbereich" oder logischem Paket (z. B. eine ETL-Route, ein ML-Modell, eine Streaming-Pipeline)
⚠️ Häufige Stolperfallen
| Problem | Ursache | Lösung |
|---|---|---|
| Merge-Konflikte in Notebooks | Gleichzeitiges Editieren desselben Notebooks | Bessere Branch-Disziplin + kleiner halten + ggf. Konvertierung nach Python |
| Kein PR möglich in UI | Technische Einschränkung von Databricks | PR im Git-System anlegen |
| Notebook-Änderungen versehentlich überschrieben | Direktes Editieren in mehreren Branches | Immer in einem Repo + Branch arbeiten |
| Verwirrung bei Repos & DBFS | Repos ≠ DBFS - kein %run aus Repos in DBFS-Code! | Klare Trennung & Umstrukturieren bestehender Pfade |
✅ Fazit
Mit der Git-Integration und Databricks Repos lässt sich endlich auch Notebook-basierter Code nachvollziehbar, versionssicher und teamfähig entwickeln.
In Kombination mit einer soliden Branching-Strategie, klaren Deployments und guten Review-Flows hast du alles, was du brauchst, um produktionsreif zu arbeiten - ganz ohne Copy-Paste-Kollateralschäden.