Git und Gitflow – ein durchdachter Branch-Workflow für Datenbank- und ETL-Projekte

Worum es geht und für wen

Versionskontrolle mit Git ist heute Standard – die eigentliche Kunst liegt nicht im Werkzeug, sondern im Workflow, also in der Vereinbarung darüber, welche Branches existieren, wie sie heißen, woher sie kommen und wohin sie fließen. Ein guter Workflow ist die unsichtbare Infrastruktur, die ein Team produktiv hält: Er verhindert, dass sich Entwickler gegenseitig blockieren, dass unfertige Arbeit versehentlich in Produktion gelangt oder dass ein dringender Fehler-Fix später wieder verloren geht. Ein schlechter oder fehlender Workflow hingegen führt zu „Merge-Hölle“, zu Releases, die niemand mehr nachvollziehen kann, und zu Produktionsständen, deren genauer Inhalt unklar ist.

Dieser Beitrag richtet sich an Teams, die SQL-Server-Datenbankprojekte (SSDT), Integrationspakete (SSIS) und Berichte (SSRS) gemeinsam versionieren und über mehrere gestaffelte Umgebungen ausliefern. Er beschreibt einen vollständigen, in der Praxis erprobten Workflow auf Basis von Bitbucket – von der ersten Verzweigung eines Features bis zum produktiven Release und zum dringenden Hotfix. Die beschriebenen Mechanismen sind aber nicht auf den Microsoft-Datenstack beschränkt: Dieselbe Branch-Topologie funktioniert genauso für Anwendungscode, APIs oder Infrastruktur-as-Code, weil sie ein generisches Problem löst – das Trennen von Integration und Auslieferung bei paralleler Arbeit.

Der rote Faden lautet: drei langlebige Branches beschreiben Umgebungsstände, kurzlebige Branches kapseln einzelne Arbeitspakete, und Release-Branches entscheiden bewusst, welche fertige Arbeit tatsächlich ausgeliefert wird. Wer dieses Prinzip verinnerlicht, kann den restlichen Workflow daraus ableiten.

Historisch geht die hier verwendete Branch-Topologie auf das von Vincent Driessen popularisierte Gitflow-Modell zurück, das Atlassian in seinen Tutorials aufgegriffen und für Teams aufbereitet hat. Das klassische Gitflow kennt zwei langlebige Branches – einen Entwicklungs- und einen Produktionsbranch – sowie die kurzlebigen Typen Feature, Release und Hotfix. Der in diesem Beitrag beschriebene Workflow erweitert dieses Grundmuster um eine dritte langlebige Stufe (test) und um eine konsequent selektive Release-Zusammenstellung, weil Datenbank- und ETL-Projekte typischerweise eine eigene, formal abgenommene Testumgebung zwischen Entwicklung und Produktion haben. Die Erweiterung ist also keine willkürliche Verkomplizierung, sondern die Anpassung eines bewährten Standardmodells an eine reale, dreistufige Auslieferungskette.

Wichtig ist dabei das richtige Erwartungsmanagement: Ein Workflow ist kein Selbstzweck und keine bürokratische Hürde, sondern ein Vertrag innerhalb des Teams. Er funktioniert nur, wenn alle Beteiligten ihn kennen, verstehen und einhalten – und wenn die wichtigsten Regeln technisch durch Branch-Schutz und Merge-Prüfungen erzwungen werden, statt sich allein auf Disziplin zu verlassen. Genau dieser Doppelweg aus klarer Vereinbarung und technischer Absicherung zieht sich als Leitgedanke durch den gesamten Beitrag.

Zielbild: umgebungsorientierter Workflow

Für ein Team, das Datenbank-, ETL- und Reporting-Artefakte gemeinsam pflegt, ist ein umgebungsorientierter Workflow mit den langlebigen Branches dev, test und main das tragfähige Fundament. Ergänzt wird er um kurzlebige Arbeits-Branches und um kurzlebige Release-Branches für selektive Auslieferungen. Bitbucket unterstützt dabei Branch Restrictions, Pull-Request-Regeln und Merge-Strategien, sodass sich der gesamte Prozess technisch absichern lässt.^1 2 3 4

Die Kernidee lautet: dev ist der Integrationsbranch der laufenden Entwicklung, test ist kein Sammelplatz aller Änderungen, sondern der Baseline-Branch für den jeweils aktuell stabilisierten Releasezug, und main beschreibt den produktiven Stand. Weil bei paralleler Feature-Entwicklung eine selektive Promotion notwendig ist, reicht ein rein lineares „alles von dev nach test und alles von test nach main“ in der Praxis nicht aus. Dafür werden pro Release kurzlebige release/*-Branches verwendet, die aus test oder dem zuletzt freigegebenen Stand erzeugt und nur mit den tatsächlich freigegebenen Features befüllt werden.⁵

Für die Datenbankprojekte ist das besonders passend, weil SQL Database Projects per DACPAC einen deklarativen Soll-Zustand abbilden und mit SqlPackage automatisiert gebaut, als Script oder DeployReport vorab geprüft und anschließend veröffentlicht werden können. Microsoft beschreibt SqlPackage ausdrücklich als Werkzeug für automatisierte Datenbank-Entwicklungs- und Bereitstellungsaufgaben in Pipelines.^10 11 12

Warum überhaupt ein so differenziertes Modell? In kleinen Projekten mit einem einzigen Entwickler und einer einzigen Zielumgebung genügt häufig ein einzelner Hauptbranch. Sobald jedoch mehrere Personen gleichzeitig an verschiedenen fachlichen Themen arbeiten, sobald es eine getrennte Test- und Produktionsumgebung gibt und sobald nicht jede fertige Entwicklung sofort live gehen soll, entstehen Zielkonflikte, die ein einfacher Workflow nicht auflösen kann. Das hier beschriebene Modell ist die Antwort auf genau diese Realität: parallele Entwicklung, gestaffelte Umgebungen und eine bewusste, gesteuerte Auslieferung. Es ist nicht komplexer als nötig, sondern genau so komplex wie die Aufgabenstellung es verlangt.

Ein weiterer Vorteil des umgebungsorientierten Ansatzes liegt in der Auditierbarkeit. In regulierten Umfeldern – etwa bei Finanzdaten, im Gesundheitswesen oder bei personenbezogenen Daten – muss jederzeit belegbar sein, welcher Stand sich in welcher Umgebung befindet und wie er dorthin gelangt ist. Wenn jeder langlebige Branch exakt einem Umgebungs-Sollstand entspricht und jede Änderung über einen dokumentierten Pull Request mit Review und grünem Build dorthin gekommen ist, lässt sich diese Frage lückenlos beantworten. Der Branch-Verlauf wird damit zum revisionssicheren Nachweis des Auslieferungsprozesses.

Drei Grundprinzipien

Die zentrale Leitlinie lautet: Jeder langlebige Branch beschreibt einen freigegebenen Zielzustand und nicht den persönlichen Arbeitsstand eines Entwicklers. Änderungen werden deshalb grundsätzlich in kurzlebigen Feature-, Bugfix-, Hotfix- oder Release-Branches entwickelt und nur per Pull Request in die langlebigen Zielbranches übernommen.^1 2 5

Trennung von Integration und Promotion

Das zweite Leitprinzip ist die Trennung von Integration und Promotion. dev ist die Integrationsfläche für parallel laufende Entwicklung, test die kontrollierte Freigabestufe und main ausschließlich der Produktivstand. Dadurch kann dev mehrere integrierte Features enthalten, während test und Produktion jeweils nur einen bewusst zusammengestellten Release-Inhalt tragen.⁵

Artefaktorientierung

Das dritte Leitprinzip ist Artefaktorientierung. Für SSDT, SSIS und SSRS sollten keine manuellen Änderungen direkt auf Zielumgebungen erfolgen, sondern gebaute, versionierte Artefakte durch einen klar definierten Branch- und Release-Prozess in die nächste Stufe gefördert werden. Einmal gebaute DACPAC-Artefakte werden unverändert in mehreren Umgebungen verwendet; die Umgebungsunterschiede steuert man über Publish-Profile, Variablen oder Pipeline-Parameter.^10 11 12

Nachvollziehbarkeit als viertes Prinzip

Eng verwandt mit der Artefaktorientierung ist ein viertes Prinzip, das in regulierten Umgebungen besonders schwer wiegt: lückenlose Nachvollziehbarkeit. Jede Änderung soll sich auf ein Ticket zurückführen lassen, jeder Merge in einen langlebigen Branch auf einen Pull Request mit Review und grünem Build, und jeder Produktionsstand auf einen Versions-Tag. Diese Verknüpfung von Ticket-ID im Branch-Namen, Pull-Request-Historie und Tag macht den gesamten Auslieferungsprozess prüfbar: Man kann zu jedem Zeitpunkt beantworten, welcher fachliche Auftrag hinter einer Codezeile steht, wer sie freigegeben hat und in welcher Version sie produktiv wurde. Genau deshalb sind Branch-Namen mit Ticket-ID und aussagekräftige Commit-Messages keine Formalität, sondern ein zentrales Werkzeug der Governance.

Warum Namenskonventionen wichtig sind

Konsistente Branch-Namen sind mehr als Kosmetik. Sie erlauben es, in Bitbucket Branch-Muster wie feature/*, release/* oder hotfix/* gezielt mit Rechten und Merge-Prüfungen zu belegen, und sie machen auf einen Blick erkennbar, woher ein Branch stammt und wohin er gehört.⁴ Ein Branch wie feature/ABC-123-kundenreport verrät Typ, Ticket und Inhalt; ein Branch namens „test2_final_neu“ verrät nichts und blockiert jede Automatisierung. Die Konvention ist damit die Grundlage dafür, dass sich die organisatorischen Regeln des Workflows überhaupt technisch durchsetzen lassen.

Das Branch-Modell im Überblick

Es gibt drei langlebige Branches und vier kurzlebige Branch-Typen. Jeder Typ hat eine klare Herkunft, ein klares Ziel und einen klaren Zweck:

Die wichtigste Ergänzung gegenüber einem einfachen dev-test-main-Modell ist der release/*-Branch. Microsofts Branching Guidance beschreibt Release-Branches als Mittel, einen Release gezielt zu stabilisieren und Korrekturen kontrolliert zwischen Release-Zweig und Hauptentwicklungszweig zu portieren; für die präzise Auswahl einzelner Änderungen wird dabei Cherry-picking empfohlen.^5 8

Diese Ergänzung ist im beschriebenen Szenario zwingend, weil mehrere Features parallel entwickelt werden und nicht gleichzeitig nach test oder Produktion gehen sollen. Ohne release/* würde jeder Vollmerge von dev nach test automatisch auch noch nicht freigegebene Features mitnehmen.⁵

# Langlebige Branches (geschuetzt, kein Direktpush)
dev      # Integrationsstand der laufenden Entwicklung
test     # stabiler Baseline-/Release-Kandidat
main     # produktiver Stand

# Kurzlebige Arbeits-Branches (immer mit Ticket-ID)
feature/ABC-123-kundenreport      # neues Feature, Abzweig von dev
bugfix/ABC-456-falscher-join      # Fehler im Entwicklungsstand
hotfix/ABC-789-prod-fehler        # Produktionsfehler, Abzweig von main
release/2026.05                   # selektiver Release-Container aus test

Der Lebenszyklus eines einzelnen Features

Ein neues Feature wird immer von dev abgezweigt. Der Entwickler erstellt einen Branch wie feature/ABC-123-neuer-etl-lauf auf Basis des aktuellen dev-Standes und arbeitet dort isoliert. Ein Branch ist dabei eine eigene Entwicklungslinie im Repository. Das Abzweigen von dev bedeutet fachlich: Das Feature startet auf dem aktuellen Integrationsstand, ist aber noch in keiner höheren Freigabestufe enthalten. Dadurch wird vermieden, dass sich Entwickler versehentlich an veralteten Test- oder Produktivständen orientieren.⁵

Ein normales Feature startet immer von dev, sammelt mehrere thematisch saubere Commits und wird per Pull Request wieder nach dev integriert. Erst danach folgt der selektive Weg in einen Release.

Arbeiten im Feature-Branch

Während der Entwicklung entstehen kleine, thematisch saubere Commits. Der Feature-Branch wird regelmäßig mit dev synchronisiert – entweder per Merge oder per Rebase –, damit Konflikte früh sichtbar werden und nicht erst kurz vor der Integration auftreten.^2 5 6 7 Im Feature-Branch werden nur Artefakte geändert, die fachlich zu diesem Ticket gehören. Für SSDT bedeutet das: nur die betroffenen DB-Projekte und möglichst keine großflächigen Formatierungs- oder Strukturumbauten; für SSIS und SSRS gilt zusätzlich, dass parallele Bearbeitung derselben Pakete oder Reports organisatorisch vermieden werden sollte, weil designer- und XML-lastige Dateien besonders konfliktanfällig sind.

# 1) Aktuellen dev-Stand holen und Feature abzweigen
git checkout dev
git pull --ff-only origin dev
git checkout -b feature/ABC-123-neuer-etl-lauf

# 2) Kleine, thematisch saubere Commits
git add src/Database/Sales/*.sql
git commit -m "ABC-123: Fact-Tabelle FactSalesDaily inkl. Index"

# 3) Regelmaessig mit dev synchronisieren (Konflikte frueh sehen)
git fetch origin
git rebase origin/dev        # lokale, noch nicht geteilte Historie glaetten
# Alternative bei bereits geteiltem Branch:
# git merge origin/dev       # Integrationshistorie bleibt erhalten

# 4) Branch veroeffentlichen und Pull Request nach dev oeffnen
git push -u origin feature/ABC-123-neuer-etl-lauf

Eintrittskriterien vor dem Pull Request

• Lokaler Build der betroffenen Solutions erfolgreich.
• Datenbankprojekte bauen zu DACPAC-Artefakten.^10 12
• Vorläufige Deploy-Validierung bzw. Script/DeployReport möglich.^10 11
• SSIS-Projekte bauen zu versionierbaren Artefakten.
• Der Branch ist aktuell gegenüber dev; Konflikte wurden im Feature-Branch gelöst, nicht erst im Zielbranch.
• Die Änderung ist fachlich sauber geschnitten und im Pull Request erklärbar.

Pull Request, Merge nach dev und Entwicklertest

Der Pull Request ist der formale Prüf- und Freigabeprozess. Er bündelt fachliche Beschreibung, Review, Build-Status und gegebenenfalls automatisierte Prüfungen vor der Integration in den Zielbranch.^1 2 3 Bitbucket erlaubt, Branch Restrictions und Merge Checks so zu konfigurieren, dass kein Direktpush und kein ungeprüfter Merge auf geschützte Branches möglich ist.^{1 2 3 4 13} Nach dem Merge nach dev wird automatisch oder halbautomatisch in die dev-Umgebung deployt – dabei werden DACPACs und gegebenenfalls SSIS-/SSRS-Artefakte veröffentlicht. Für Datenbanken sollte mindestens vorab ein Script oder DeployReport erzeugt werden, um Auswirkungen auf den Soll-/Ist-Abgleich sichtbar zu machen.^10 11 12

Merge, Rebase und Cherry-pick richtig einsetzen

Drei Git-Operationen bilden das Werkzeug, mit dem der gesamte Workflow funktioniert. Sie unterscheiden sich grundlegend in ihrer Wirkung auf die Historie.

Merge

Merge führt den aktuellen Stand eines Branches in einen anderen zusammen. Vorteil ist, dass die Integrationshistorie sichtbar bleibt und keine Commit-Historie umgeschrieben wird; Nachteil ist eine potenziell verzweigte, weniger lineare Historie.^2 6 7

Rebase

Rebase setzt die eigenen Commits eines Feature-Branches auf den neuesten dev-Stand neu auf. Vorteil ist eine lineare, saubere Historie; Nachteil ist, dass die Historie des Branches umgeschrieben wird. Atlassian beschreibt Rebase deshalb als Technik, die gezielt und mit Vorsicht eingesetzt werden sollte – insbesondere nicht auf bereits breit geteilten Branches.^6 7

Cherry-pick

Cherry-pick ist die gezielte Übernahme einzelner Commits in einen anderen Branch. Anders als beim Merge wird nicht der ganze Branch zusammengeführt, sondern nur die ausgewählte Änderung. Atlassian weist gleichzeitig darauf hin, dass Cherry-pick nützlich, aber kein genereller Ersatz für Merge oder Rebase ist, weil dadurch neue Commits mit neuer Historie entstehen und bei Übernutzung ein unübersichtlicher Verlauf entstehen kann.^8 9

Fast-forward, no-ff und Squash

Beim Mergen gibt es zusätzlich drei praktisch wichtige Varianten, die festlegen, wie der Zielbranch-Verlauf aussieht. Ein Fast-forward-Merge verschiebt den Branch-Zeiger lediglich nach vorn, wenn keine divergierenden Commits existieren – es entsteht kein eigener Merge-Commit, die Historie bleibt linear, aber die Information „hier wurde ein Feature integriert“ geht verloren. Ein no-ff-Merge (--no-ff) erzwingt dagegen immer einen Merge-Commit und macht so jede Integration als abgegrenzten Block sichtbar – das ist für die langlebigen Branches und für Release-Merges der empfohlene Weg, weil sich Releases dadurch später sauber identifizieren und bei Bedarf zurücknehmen lassen. Ein Squash-Merge fasst alle Commits eines Feature-Branches zu einem einzigen Commit zusammen; das hält die Historie des Zielbranches kompakt, erschwert aber späteres Cherry-picking einzelner Teiländerungen. Bitbucket erlaubt, die zulässigen Merge-Strategien pro Repository und pro Ziel-Branch vorzugeben.^1 2

# MERGE: dev in den Feature-Branch zusammenfuehren (Historie bleibt sichtbar)
git checkout feature/ABC-123
git merge origin/dev

# REBASE: eigene Commits auf neuen dev-Stand neu aufsetzen (lineare Historie)
git checkout feature/ABC-123
git rebase origin/dev
# Achtung: niemals einen bereits breit geteilten Branch rebasen!

# CHERRY-PICK: genau einen freigegebenen Commit in release/* uebernehmen
git checkout release/2026.05
git cherry-pick 9f3a1c2        # nur dieser eine Commit, nicht der ganze Branch

Damit Cherry-pick sauber funktioniert, muss jedes Feature in seiner Commit-Historie diszipliniert umgesetzt sein. Mischcommits, die gleichzeitig mehrere Features, Refactorings und Hotfixes enthalten, zerstören die Selektionsfähigkeit.

Selektiver Release bei mehreren parallelen Features

Genau hier liegt der entscheidende Punkt: dev ist Integrationsfläche, aber kein direkter Release-Container. Wenn mehrere Features parallel existieren und nur ein Teil davon nach test oder Produktion soll, muss der Release-Inhalt separat zusammengesetzt werden.⁵

Feature A, B und C liegen parallel in dev. Für einen Release wird von test ein release/*-Branch erstellt, in den nur Feature A übernommen wird. Nur A erreicht test und main; B und C bleiben in dev.

Der Grundmechanismus ist immer gleich: Es existiert ein stabiler test-Stand als Baseline. Für einen neuen Release wird von test ein Branch release/<version> erstellt. In diesen Release-Branch werden nur die Features übernommen, die tatsächlich freigegeben werden sollen. Danach wird der Release-Branch in test gemergt und auf die Testumgebung deployt; nach erfolgreicher Abnahme wird derselbe Release-Branch nach main gemergt und auf Produktion deployt.^2 5

# 1) Release-Branch vom stabilen test-Stand erzeugen
git checkout test
git pull --ff-only origin test
git checkout -b release/2026.05

# 2) NUR Feature A uebernehmen -- per Cherry-pick der freigegebenen Commits ...
git cherry-pick 9f3a1c2 a17b8e4
# ... oder per Merge eines sauber isolierten Port-Branches, der nur A enthaelt:
# git merge --no-ff feature/ABC-123-portA

# 3) Release nach test foerdern und abnehmen lassen
git checkout test
git merge --no-ff release/2026.05
git push origin test

# 4) Nach Abnahme: derselbe Release-Branch nach main + Produktions-Tag
git checkout main
git merge --no-ff release/2026.05
git tag -a v2026.05 -m "Release 2026.05: Feature A"
git push origin main --tags

Ausführlicher Ablauf mit drei parallelen Features

Angenommen, es gibt drei Features: Feature A ist fertig und soll bald nach Produktion; Feature B ist in test vorgesehen, aber noch nicht produktionsreif; Feature C ist noch in Entwicklung und soll vorerst nur auf dev bleiben.

• Phase 1 – Start von dev: feature/A, feature/B und feature/C werden jeweils von dev erstellt. Alle drei Entwickler arbeiten parallel, jeder Branch wird regelmäßig mit dev synchronisiert.⁵
• Phase 2 – Integration in dev: Alle drei werden per Pull Request nach dev übernommen, sobald sie für den Entwicklertest reif sind – ohne damit automatisch Teil eines Releases zu werden.^1 2
• Phase 3 – Release-Branch für test: Vom aktuellen test-Stand wird release/2026.05 erstellt. Hinein kommt nur Feature A – per Cherry-pick der A-Commits oder per Merge eines sauberen Port-Branches.^5 8
• Phase 4 – Release nach Produktion: Ist A auf test abgenommen, wird derselbe Release-Branch nach main gemergt. main und Produktion enthalten nun A, während B und C ausschließlich in dev verbleiben.^2 5
• Phase 5 – nächster Release: Später entsteht release/2026.06 von test (das nun bereits A enthält). In diesen Branch wird Feature B übernommen; Feature C bleibt weiter nur in dev, bis es freigegeben ist.⁵

Diese Vorgehensweise löst genau den Zielkonflikt „ein Feature noch in dev, eines in test, ein anderes auf Produktion“: Die langlebigen Branches bilden die Umgebungs-Baselines ab, während die release/*-Branches die selektiven Promotions kapseln.

Voraussetzung: saubere Commit-Disziplin

Die selektive Promotion steht und fällt mit der Qualität der Commit-Historie. Damit sich Feature A überhaupt sauber aus dev herauslösen lässt, müssen seine Commits thematisch eindeutig diesem Feature zugeordnet sein. Sobald ein einzelner Commit gleichzeitig Teile von A, ein Refactoring und einen Nebenfix enthält, lässt er sich nicht mehr isoliert übernehmen, ohne ungewollte Änderungen mitzuziehen. In der Praxis bedeutet das: ein Commit pro logischer Teiländerung, sprechende Commit-Messages mit Ticket-ID und das konsequente Vermeiden von „Sammelcommits“ am Tagesende. Wo eine Historie bereits unsauber ist, hilft ein vorgelagerter Aufräum-Schritt: Das Feature wird zunächst in einen frischen, nur A enthaltenden Port-Branch konsolidiert, der dann als Ganzes per --no-ff in den Release-Branch gemergt wird. So bleibt der Release-Inhalt exakt und nachvollziehbar.

Was passiert mit nicht freigegebenen Features?

Eine häufige Sorge lautet: „Wenn nur Feature A released wird – gehen B und C dann verloren?“ Nein. B und C bleiben unverändert in dev erhalten und entwickeln sich dort weiter. Sie warten lediglich auf ihren eigenen Release-Zug. Sobald sie freigegeben sind, werden sie über einen späteren release/*-Branch genauso selektiv gefördert. Der entscheidende Punkt ist, dass die Entscheidung „was wird ausgeliefert“ bewusst und zu einem definierten Zeitpunkt getroffen wird – und nicht implizit dadurch, dass zufällig gerade alles in dev integriert war, als jemand nach test gemergt hat.

Der Release-Branch im Detail

Der Release-Branch ist das Herzstück der kontrollierten Auslieferung. Er entsteht aus dem stabilen test-Stand, nimmt ausschließlich freigegebene Inhalte auf, wird in test abgenommen und erst dann nach main gefördert – begleitet von einem Versions-Tag.

release/* wird aus test bzw. dem freigegebenen dev-Stand erzeugt, in der Stabilisierungsphase um gezielte Fixes ergänzt, in test abgenommen und schließlich mit Versions-Tag nach main ausgeliefert.

Während ein Release-Branch offen ist, dürfen dort nur noch stabilisierende Korrekturen einfließen – keine neuen Features. Jeder Fix, der hier entsteht, muss anschließend zurück nach dev portiert werden, damit die Entwicklungslinie den Fehler nicht erneut einschleppt. Genau dieses kontrollierte Zurückführen eines bereits validierten Fixes nennt man Rückport (Port-back) und erfolgt technisch häufig per Cherry-pick.^5 8

Bugfixes und Hotfixes – je nach Fehlerort

Wo ein Fehler behoben wird, hängt davon ab, wo er auftritt. Drei Fälle sind zu unterscheiden.

Ein Produktionsfehler wird über hotfix/* von main behoben, per Versions-Tag (z. B. v1.1.1) ausgeliefert und anschließend verpflichtend nach test und dev zurückportiert, damit die Korrektur nicht verloren geht.

Bugfix in dev

Ein Fehler, der nur im Entwicklungs- oder Integrationsstand auftritt, wird über bugfix/* von dev behoben – etwa bugfix/ABC-456-falscher-join – gegen dev entwickelt und per Pull Request wieder nach dev gemergt.⁵ Der Fix läuft anschließend ganz normal mit künftigen Releases weiter.

Bugfix in test

Ein Fehler, der erst in test entdeckt wird, betrifft in der Regel einen konkreten Release-Kandidaten. Deshalb wird der Fix nicht als normale Weiterentwicklung auf dev erstellt, sondern auf dem betroffenen Release-Stand – in release/* oder notfalls auf test, falls noch kein dedizierter Release-Branch existiert.⁵ Anschließend wird der validierte Fix kontrolliert nach dev portiert, denn würde er nur in test bleiben, brächte dev später denselben Fehler zurück. Rückportierung nach dev ist daher Pflicht.

Hotfix in Produktion

Ein produktiver Fehler wird immer auf Basis von main behoben. Dafür wird ein hotfix/*-Branch von main erstellt, der Fix implementiert, per Pull Request zurück nach main gemergt und sofort oder beschleunigt nach Produktion deployt.^2 5 Danach muss der Hotfix rückwärts portiert werden: in den aktuell offenen release/*-Branch oder nach test sowie anschließend nach dev. Cherry-pick ist hier oft der sauberste Weg, weil nur genau der Hotfix übertragen werden soll – ein pauschales Mergen von main nach dev könnte ungewollte release-spezifische Unterschiede mitnehmen.^5 8

# 1) Hotfix-Branch direkt von main
git checkout main
git pull --ff-only origin main
git checkout -b hotfix/ABC-789-prod-fehler

# 2) Fix umsetzen, PR nach main, Produktions-Tag
git commit -am "ABC-789: NULL-Behandlung in dbo.usp_LoadFacts korrigiert"
git checkout main
git merge --no-ff hotfix/ABC-789-prod-fehler
git tag -a v2026.05.1 -m "Hotfix ABC-789"
git push origin main --tags

# 3) RUECKPORT (Pflicht): genau diesen Fix nach test und dev portieren
git checkout test  && git cherry-pick <hotfix-sha> && git push origin test
git checkout dev   && git cherry-pick <hotfix-sha> && git push origin dev

Regeln für Merges zwischen dev, test und main

• Regel 1 – Kein direktes Dauer-Merging von dev nach test. Ein pauschaler Vollmerge dev → test würde jedes bereits integrierte, aber noch nicht freigegebene Feature mitnehmen und genau das gewünschte Trennen von A, B und C unmöglich machen. Stattdessen gilt: dev ist Integrationsfläche, release/* ist Selektionsfläche.⁵
• Regel 2 – test nur aus Release-Ständen aktualisieren. test wird nur durch Merge eines freigegebenen release/*-Branches aktualisiert. So bleibt jederzeit nachvollziehbar, welcher Release-Kandidat in test liegt und welche Features er enthält.^2 5
• Regel 3 – main nur aus test-abgenommenen Release-Ständen oder Hotfixes. main erhält nur einen aus test erfolgreich abgenommenen release/*-Branch oder einen produktiven hotfix/*-Branch. Damit bleibt main der produktive Wahrheitsstand und wird nicht mit laufender Entwicklung kontaminiert.^2 5

Pull-Request- und Merge-Standards in Bitbucket

Bitbucket sollte so konfiguriert werden, dass Branch Restrictions und Merge Checks für dev, test und main aktiv sind. Atlassian dokumentiert dafür branchbezogene Push-/Merge-Einschränkungen, Standard-Reviewer und Merge-Einstellungen.^{1 2 3 4 13} Branch Permissions kontrollieren Schreib- und Merge-Rechte für bestimmte Branches oder Branch-Muster; Merge Checks erlauben zusätzlich, Bedingungen wie erfolgreiche Builds oder erforderliche Reviews vor einem Merge vorzuschreiben.^3 4 13

• Kein Direktpush auf dev, test, main – PR-Pflicht für alle Merges.
• Mindestens ein fachlicher und ein technischer Reviewer für DB-/ETL-/Report-relevante Änderungen.
• Erfolgreicher CI-Build als Merge-Voraussetzung.
• Source-Branch nach Merge automatisch schließen.
• Merge nach test nur durch Release-Verantwortliche, Merge nach main nur durch Release-Manager/Admingruppe – restriktiver als für dev.⁴
• Dokumentierte Checkliste für Deployment, Rollback, Smoke-Test und Datenbankauswirkungen.

CI/CD-ready Zielarchitektur für SSDT, SSIS und SSRS

Eine CI/CD-fähige Zielarchitektur lässt sich direkt auf diesem Workflow aufbauen. Für Datenbanken ist der Standardpfad: Build der .sqlproj-Projekte, DACPAC-Erzeugung, DeployReport oder Script, Testdeployment und danach Publish mit SqlPackage.^10 11 12 Branches repräsentieren dabei klare Umgebungsstände, mehrere Entwickler arbeiten parallel, und Releases werden trotzdem gezielt und reproduzierbar ausgeliefert.

# 1) Datenbankprojekt bauen -> DACPAC
dotnet build .\src\Database\Sales\Sales.sqlproj -c Release

# 2) Aenderungsvorschau VOR dem Deploy (DeployReport, kein Schreibzugriff)
SqlPackage /Action:DeployReport `
  /SourceFile:".\bin\Release\Sales.dacpac" `
  /TargetConnectionString:"Server=sql-test;Database=Sales;Integrated Security=true" `
  /OutputPath:".\artifacts\Sales.DeployReport.xml"

# 3) Idempotentes Upgrade-Script erzeugen (Review im Pull Request)
SqlPackage /Action:Script `
  /SourceFile:".\bin\Release\Sales.dacpac" `
  /TargetConnectionString:"Server=sql-test;Database=Sales;Integrated Security=true" `
  /OutputPath:".\artifacts\Sales.Upgrade.sql"

# 4) Erst nach Freigabe: Publish in die Zielumgebung
SqlPackage /Action:Publish `
  /SourceFile:".\bin\Release\Sales.dacpac" `
  /TargetConnectionString:"Server=sql-test;Database=Sales;Integrated Security=true" `
  /p:BlockOnPossibleDataLoss=true

Build und Deployment werden sauber getrennt: Einmal gebaute DACPAC-Artefakte werden unverändert in mehreren Umgebungen verwendet, während Umgebungsunterschiede über Publish-Profile, Variablen oder Pipeline-Parameter gesteuert werden.

SSIS und SSRS in der Pipeline

Für SSIS verläuft der Pfad analog: Das Projekt wird zu einer versionierbaren ISPAC-Datei gebaut und über das Projektdeployment-Modell in den Integration Services Catalog (SSISDB) der Zielumgebung deployt. Umgebungsabhängige Werte – Verbindungszeichenfolgen, Pfade, Schwellwerte – werden nicht im Paket hart kodiert, sondern über SSIS-Umgebungen und -Parameter zur Deploy-Zeit gesetzt. So bleibt dasselbe gebaute ISPAC in dev, test und Produktion identisch, während nur die Konfiguration variiert – exakt das gleiche Prinzip wie beim DACPAC.

Für SSRS werden Berichtsdefinitionen (.rdl) und gemeinsame Datenquellen vollständig versioniert und über die Reporting-Services-Schnittstelle bzw. ein Deployment-Skript in die Zielumgebung veröffentlicht. Entscheidend ist hier die Disziplin, niemals direkt im Report-Portal zu editieren: Jede manuelle Änderung im Zielsystem läuft sonst dem versionierten Stand davon und geht beim nächsten Deployment verloren oder überschreibt unbeabsichtigt eine andere Korrektur.

Pipeline-Trigger entlang der Branches

Die obige Tabelle lässt sich direkt in Pipeline-Trigger übersetzen: Auf jeden Pull Request gegen dev läuft ein reiner Build- und Prüf-Lauf ohne Deployment; auf jeden Merge nach dev folgt ein automatisches Deployment in die dev-Umgebung; ein Push auf release/* erzeugt einen Release-Build samt DeployReport zur Prüfung; der Merge nach test löst das Test-Deployment aus, der Merge nach main das Produktions-Deployment mit anschließendem Smoke-Test und Versions-Tag. Weil jeder langlebige Branch genau einer Umgebung entspricht, ist die Zuordnung „welcher Merge löst welches Deployment aus“ eindeutig und benötigt keine zusätzliche Logik.

End-to-End: der komplette Workflow auf einen Blick

Die folgende Gesamtübersicht verbindet alle Bausteine zu einem durchgehenden Bild: ein Feature durchläuft mehrere Iterationen auf dev, wird über einen Release-Branch selektiv stabilisiert, in test abgenommen, nach main ausgeliefert – und ein parallel auftretender Produktionsfehler wird über einen Hotfix behoben und zurückportiert.

Der vollständige Lebenszyklus: dev integriert laufende Entwicklung, release/* selektiert den Release-Inhalt, test nimmt ab, main ist produktiv (v1.0 → v1.1). Ein Hotfix von main (v1.1.1) wird verpflichtend nach dev zurückportiert.

Dieses Zusammenspiel ist der eigentliche Mehrwert: Branches bilden Umgebungs-Sollstände ab statt beliebiger Zwischenstände, die selektive Promotion entkoppelt Integration von Auslieferung, und jeder Fix findet seinen Weg zurück in die Entwicklungslinie. Für Datenbank- und ETL-Projekte entsteht so ein reproduzierbarer, prüfbarer und auditierbarer Auslieferungsprozess.

Konflikte vermeiden im SSDT-/SSIS-/SSRS-Stack

Merge-Konflikte lassen sich in diesem Stack nicht vollständig eliminieren, aber deutlich reduzieren. Die wichtigsten Hebel sind kleine Branches, kleine Pull Requests, frühes Integrieren in dev und klare Zuständigkeiten für konfliktanfällige SSIS- und SSRS-Artefakte.

• Verbindliche Datei- und Ordnerkonventionen für DB-Objekte, SSIS-Packages und SSRS-Reports.
• Pull Requests klein halten, ideal unter einem fachlichen Thema.
• Frühes Integrieren in dev statt wochenlangem Sammeln auf Feature-Branches.
• „One developer owns one artifact“ für konfliktanfällige SSIS-/SSRS-Dateien während einer Story.
• Refactorings an Datenbankobjekten zeitlich bündeln, nicht parallel zu vielen Features.
• Keine Mischcommits über mehrere Features hinweg – damit Cherry-pick und Rückport sauber möglich bleiben.^8 9

Besonderheiten der drei Artefakttypen

SSDT eignet sich gut, weil Database Projects deklarativ den Sollzustand beschreiben und sich als DACPAC bauen lassen; SqlPackage unterstützt Publish, Script und Reporting.^10 11 12 SSIS erzeugt versionierbare Build-Artefakte; weil designer-generierte Dateien konfliktanfällig sind, sollte Ownership pro Package während eines Tickets eindeutig sein. SSRS sollte vollständig source-controlled und release-gesteuert behandelt werden – Reports und Shared Data Sources dürfen nicht manuell in Zielumgebungen gepflegt werden, sonst laufen Branch- und Umgebungszustand auseinander.

Ein praktischer Sonderfall verdient Beachtung: Datenbank-Refactorings wie das Umbenennen einer Spalte oder das Aufteilen einer Tabelle erzeugen besonders gern Konflikte und potenziellen Datenverlust. SSDT bietet dafür Refactoring-Logs, die solche Umbenennungen als bewusste Operation festhalten, statt sie als „Spalte gelöscht, neue Spalte angelegt“ zu interpretieren. Wer diese Logs versioniert und SqlPackage mit BlockOnPossibleDataLoss betreibt, vermeidet, dass ein scheinbar harmloses Refactoring in Produktion stillschweigend Daten verwirft. Solche strukturellen Änderungen sollten zeitlich gebündelt und nicht parallel zu vielen kleinen Features laufen, damit die selektive Promotion überschaubar bleibt.

Konkrete Handlungsanweisung für das Team

• Jedes normale Feature startet von dev und merged zuerst nach dev.
• dev dient nur der Integration, nicht der direkten Promotion nach test.
• Für jeden geplanten Release wird von test ein release/*-Branch erstellt.
• In den Release-Branch kommen nur freigegebene Features – per Cherry-pick oder gezieltem Merge isolierter Branches.
• release/* geht nach erfolgreicher Prüfung nach test; derselbe Branch geht nach Abnahme nach main.
• Bugs in dev werden auf dev behoben, Bugs in test auf dem betroffenen release/*-Stand, Bugs in Produktion als hotfix/* von main.
• Jeder Fix aus test oder Produktion wird kontrolliert zurück nach dev portiert.
• Pull Requests, Branch Permissions und Merge Checks sind für die langlebigen Branches verbindlich zu konfigurieren.^1 3 4 13

Vorgehen in der Zusammenarbeit

Ein Branching-Modell entfaltet seinen Nutzen erst dann, wenn das gesamte Team es versteht, mitträgt und im Alltag konsequent anwendet. Ich bringe die Workflow-Erfahrung, die Automatisierung und die Bitbucket-Konfiguration mit; das Projektteam bringt das Wissen über die bestehende Codebasis, die Releasezyklen und die organisatorischen Rahmenbedingungen. Aus dieser Kombination entsteht ein Prozess, der technisch sauber und im Betrieb tatsächlich gelebt wird – statt eines Dokuments, das nach zwei Wochen niemand mehr beachtet.

Typischer Projekteinstieg

In der Regel beginne ich mit einer Bestandsaufnahme: Wie sehen die aktuellen Branches aus, wie wird heute gemerged, welche Umgebungen (dev, test, main) existieren und wie werden sie beliefert? Ich prüfe die bestehende Bitbucket- oder Azure-DevOps-Konfiguration, die Merge-Checks, die Branch Permissions und die vorhandenen Build-Pipelines. Das Ergebnis ist eine klare Standortbestimmung mit konkreten, priorisierten Verbesserungen – vom fehlenden Rückport bis zur ungeschützten main. Dieser erste Schritt dauert typischerweise ein bis drei Tage und schafft die gemeinsame Grundlage, bevor größere änderungen am Workflow vorgenommen werden.

Iterative Umsetzung

Die Einführung erfolgt schrittweise und ohne Big-Bang. Zuerst werden die langlebigen Branches abgesichert und die Merge-Regeln verbindlich gemacht; danach folgen der Feature-, Bugfix- und Hotfix-Prozess sowie der selektive Release über release/*. Jede Stufe wird mit dem Team abgestimmt, dokumentiert und an einem realen Release erprobt, bevor die nächste Stufe kommt. So bleibt der Betrieb jederzeit handlungsfähig.

• Bestandsaufnahme von Branches, Merges, Umgebungen und Pipelines
• Schrittweise Absicherung der langlebigen Branches (dev, test, main)
• Verbindliche Merge-Checks, Branch Permissions und Pull-Request-Regeln
• Erprobung an einem echten Release statt rein theoretischer Einführung
• Wissenstransfer, Cheat-Sheets und kurze Hands-on-Sessions für das Team

Wichtig ist mir, dass der Workflow zur Organisation passt und nicht umgekehrt. Ein kleines Team mit einem Release pro Quartal braucht andere Regeln als ein Team mit wöchentlichen Auslieferungen. Ich passe das Modell an die reale Releasefrequenz, die Anzahl paralleler Vorhaben und die regulatorischen Anforderungen an.

Typische Leistungen rund um Git und Gitflow

Je nach Ausgangslage und Projektziel übernehme ich unterschiedliche Aufgaben – von der einmaligen Einführung eines Branching-Modells bis zur dauerhaften Betreuung der Pull-Request- und CI/CD-Prozesse einer SQL-, SSIS- und SSRS-Landschaft.

• Entwurf eines Branching-Modells mit dev, test und main, passend zur Releasefrequenz
• Einführung von Feature-, Bugfix-, Hotfix- und Release-Branches mit klaren Regeln
• Selektive Promotion einzelner Features über release/* per Merge oder Cherry-pick
• Definition und Umsetzung des kontrollierten Rückports von Fixes nach dev
• Bitbucket-Konfiguration: Branch Permissions, Merge Checks, verpflichtende Reviewer
• Pull-Request-Standards, Commit-Konventionen und Review-Richtlinien
• Merge-, Rebase- und Cherry-pick-Strategie inklusive Schulung des Teams
• Konfliktvermeidung durch kleine, häufige Integrationen und klare Verantwortlichkeiten
• CI/CD für SSDT-Datenbankprojekte: Build zu DACPAC, DeployReport und Publish mit SqlPackage
• Build- und Deployment-Pipelines für SSIS-Pakete und SSRS-Berichte
• Automatisierte Tests und Quality Gates als Merge-Voraussetzung
• Dokumentation, Runbooks und Wissenstransfer für Entwicklungs- und Betriebsteams

Viele Probleme im Versionsmanagement sind nicht isoliert: Häufige Merge-Konflikte sind oft Symptom zu langlebiger Feature-Branches, ungewollt ausgelieferte Features ein Symptom fehlender selektiver Promotion und wiederkehrende Produktionsfehler ein Symptom fehlender Rückports. Ich betrachte den Workflow deshalb immer im Zusammenhang mit der CI/CD-Strecke und der Deployment-Realität.

Ob als einmaliges Einführungsprojekt, als Review eines bestehenden Workflows oder als laufende Begleitung – der Umfang richtet sich nach Ihrem Bedarf. Auch ein klar abgegrenztes Mandat, etwa „main absichern und CI/CD für SSDT aufsetzen“, ist ein sinnvoller Einstieg.

Ausgewählte Referenzprojekte

Begriffe kurz erklärt

Die folgenden Begriffe tauchen im gesamten Workflow auf und werden hier kompakt definiert, damit alle Beteiligten dasselbe darunter verstehen:

• Langlebiger Branch: ein dauerhaft existierender Branch (dev, test, main), der einen Umgebungs-Sollstand abbildet und niemals gelöscht wird.
• Kurzlebiger Branch: ein Arbeits-Branch (feature/*, bugfix/*, hotfix/*, release/*), der für einen bestimmten Zweck erstellt und nach dem Merge wieder geschlossen wird.
• Integration: das Zusammenführen mehrerer Entwicklungsstände auf dev, damit Inkompatibilitäten früh sichtbar werden – ohne damit eine Freigabe auszusprechen.
• Promotion: das bewusste Weiterreichen eines geprüften Standes in die nächsthöhere Umgebung (dev → test → main), gesteuert über release/*-Branches.
• Selektive Promotion: die gezielte Auswahl einzelner Features für einen Release, statt pauschal „alles, was gerade in dev liegt“ auszuliefern.
• Rückport (Port-back): das kontrollierte Zurückführen eines bereits validierten Fixes aus test, release/* oder main zurück nach dev, damit der Fehler nicht erneut auftaucht.
• DACPAC: das gebaute, deklarative Artefakt eines SSDT-Datenbankprojekts, das den Sollzustand der Datenbank beschreibt und mit SqlPackage veröffentlicht wird.^10 11
• DeployReport: eine Vorab-Analyse von SqlPackage, die ohne Schreibzugriff zeigt, welche Änderungen ein Deployment auslösen würde.^10 11
• Merge Check / Branch Permission: in Bitbucket konfigurierbare Bedingungen (grüner Build, Mindest-Reviewer, Push-Verbot), die einen Merge auf geschützte Branches erst nach Erfüllung erlauben.^3 4

Häufige Fragen

Warum nicht einfach dev nach test und test nach main durchmergen?

Weil dann jeder noch nicht freigegebene Feature-Stand automatisch mit ausgeliefert würde. Sobald mehrere Features parallel laufen und nur ein Teil released werden soll, ist die selektive Promotion über release/* unverzichtbar.⁵

Wann Cherry-pick und wann Merge eines Branches?

Ist ein Feature-Branch sauber isoliert, ist ein Merge in release/* gut nachvollziehbar. Steckt das Feature bereits zusammen mit anderen in dev, wählt man die freigegebenen Commits per Cherry-pick exakt aus.^8 9

Muss ein Hotfix wirklich zurück nach dev?

Ja. Bliebe der Fix nur in main oder test, brächte die Entwicklungslinie den Fehler beim nächsten Release zurück. Der Rückport – meist per Cherry-pick – ist deshalb Pflicht.^5 8

Eignet sich das Modell für reine SSDT-Datenbankprojekte?

Besonders gut. SQL Database Projects beschreiben deklarativ den Sollzustand und werden als DACPAC gebaut; SqlPackage erzeugt DeployReport, Script und Publish – ideal für die kontrollierte Promotion zwischen dev, test und main.^10 11 12

Quellenverzeichnis

Die folgenden Quellen wurden für Branching-Empfehlungen, Bitbucket-Regeln, Begriffsdefinitionen und den SQL-/CI/CD-Bezug herangezogen:

1. ¹ Atlassian Support – Pull request and merge settings – https://support.atlassian.com/bitbucket-cloud/docs/pull-request-and-merge-settings/
2. ² Atlassian Support – Merge a pull request – https://support.atlassian.com/bitbucket-cloud/docs/merge-a-pull-request/
3. ³ Atlassian Support – Suggest or require checks before a merge – https://support.atlassian.com/bitbucket-cloud/docs/suggest-or-require-checks-before-a-merge/
4. ⁴ Atlassian Support – Use branch permissions – https://support.atlassian.com/bitbucket-cloud/docs/use-branch-permissions/
5. ⁵ Microsoft Learn – Git branching guidance – https://learn.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops
6. ⁶ Atlassian – Merging vs. Rebasing – https://www.atlassian.com/git/tutorials/merging-vs-rebasing
7. ⁷ Atlassian Community – Alternatives to Git merge: Rebase and Cherry-pick – https://community.atlassian.com/forums/Bitbucket-articles/Alternatives-to-Git-merge-Git-s-Rebase-and-Cherry-pick/ba-p/2482241
8. ⁸ Microsoft Learn – Copy changes to a branch with cherry-pick – https://learn.microsoft.com/en-us/azure/devops/repos/git/cherry-pick?view=azure-devops
9. ⁹ Atlassian – Git Cherry Pick Tutorial – https://www.atlassian.com/git/tutorials/cherry-pick
10. ¹⁰ Microsoft Learn – SqlPackage in Development Pipelines – https://learn.microsoft.com/en-us/sql/tools/sqlpackage/sqlpackage-pipelines?view=sql-server-ver17
11. ¹¹ Microsoft Learn – SqlPackage – https://learn.microsoft.com/en-us/sql/tools/sqlpackage/sqlpackage?view=sql-server-ver17
12. ¹² Microsoft Learn – Automatisierung von SQL-Projekten – https://learn.microsoft.com/de-de/sql/tools/sql-database-projects/sql-projects-automation?view=sql-server-ver17
13. ¹³ Bitbucket – Features / Merge checks – https://bitbucket.org/product/en/features