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:

/Repos/samuel@firma.de/projekt-xyz/
│
├── notebooks/
│   └── transform_customer_data.py
│
├── resources/
│   └── workflow_customer_job.yml
│
├── databricks.yml
└── README.md

💡 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:

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:

main                   → Produktion  
develop                → gemeinsame Test- und Integrationsumgebung  
dev/samuel             → Samuels Entwicklungsbranch  
dev/lisa               → Lisas Entwicklungsbranch

🔹 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:

git checkout -b feature/abc-123-add-billing-cleanup

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:

💡 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

✅ 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.