Git für Marketing-Teams – Warum euer AI-Stack Versionskontrolle braucht

In 30 Sekunden

Marketing-Teams, die ernsthaft mit KI arbeiten, stehen vor einem Problem, das Software-Teams vor Jahrzehnten gelöst haben: Wie verwaltet man dutzende Konfigurationsdateien, Prompts, Workflows und Kontextdokumente – im Team, mit Änderungsverlauf und ohne dass jemand versehentlich etwas kaputt macht?

Die Antwort ist dieselbe wie damals: Versionskontrolle mit Git.

Das Problem: Google Drive skaliert nicht

Die meisten Marketing-Teams starten ihre KI-Journey mit dem, was sie kennen: Google Drive. Prompts in Docs, Workflows in Sheets, Kontextdateien in Ordnern. Das funktioniert – bis es das nicht mehr tut.

Wann Google Drive an seine Grenzen stößt

Symptom	Was passiert
Keine echte Versionshistorie	Google Drive speichert Versionen, aber es fehlt die Möglichkeit, gezielt zu vergleichen: Was hat sich geändert? Wer hat es geändert? Warum?
Keine Reviews	Jemand ändert einen System-Prompt – niemand prüft die Änderung, bevor sie live geht
Kein Branching	Du willst eine neue Strategie testen, ohne die bestehende zu gefährden? Nicht möglich. Du kopierst Dateien und hoffst
KI-Agenten brauchen Dateizugriff	Tools wie Claude Code arbeiten nativ mit Git-Repositories. Google Drive ist für sie eine Sackgasse
Team-Größe	Ab 5+ Personen, die gleichzeitig an KI-Konfigurationen arbeiten, wird es chaotisch

Wir haben über sechs Monate lang alles auf Google Drive betrieben. Dutzende KI-Mitarbeiter, Kontextdateien, Skill-Definitionen. Es funktionierte – bis unser Team auf 7 Personen wuchs und niemand mehr wusste, welche Version die richtige war.

Was gehört in ein Git-Repository?

Nicht alles muss raus aus Google Drive. Hier ist eine klare Trennung:

✅ Ab nach Git

• System-Prompts und Persona-Definitionen eurer KI-Agenten
• Kontextdateien (Brand Voice, ICP-Beschreibungen, Styleguides)
• Workflow-Konfigurationen (Automatisierungen, Tool-Definitionen)
• Skill-Dateien (Was kann jeder KI-Agent?)
• Templates und wiederverwendbare Prompt-Bausteine

❌ Bleibt auf Google Drive (oder anderswo)

• Tagesgeschäft-Dokumente (Meeting Notes, Brainstorming)
• Große Mediendateien (Videos, Design-Assets)
• Kollaborative Arbeitsdokumente, die sich stündlich ändern
• Daten, die kein Mensch jemals reviewen muss

Die Faustregel: Wenn eine Datei das Verhalten eines KI-Agenten beeinflusst, gehört sie in Git.

Praxis-Guide: Die Ordnerstruktur

Eine bewährte Struktur für ein Marketing-AI-Repository:

marketing-ai/
├── agents/                    # KI-Mitarbeiter
│   ├── content-writer/
│   │   ├── system-prompt.md   # Persönlichkeit & Regeln
│   │   ├── skills/            # Einzelne Fähigkeiten
│   │   │   ├── blog-post.md
│   │   │   ├── social-media.md
│   │   │   └── email-sequence.md
│   │   └── examples/          # Referenz-Outputs
│   ├── seo-analyst/
│   └── campaign-manager/
├── context/                   # Geteiltes Wissen
│   ├── brand-voice.md         # Wie wir schreiben
│   ├── icp-profiles.md        # Unsere Zielkunden
│   ├── product-facts.md       # Was wir anbieten
│   └── competitors.md         # Wettbewerbsinfos
├── workflows/                 # Automatisierungen
│   ├── content-pipeline.yml
│   ├── lead-scoring.yml
│   └── reporting.yml
├── templates/                 # Wiederverwendbare Bausteine
│   ├── blog-brief.md
│   ├── case-study-template.md
│   └── campaign-brief.md
└── README.md                  # Übersicht für neue Teammitglieder

Warum diese Struktur funktioniert

• Agent-zentriert: Jeder KI-Mitarbeiter hat seinen eigenen Ordner mit allem, was er braucht
• Geteilter Kontext: Brand Voice und ICP-Definitionen liegen zentral und werden von allen Agents referenziert
• Klare Trennung: Workflows, Templates und Agent-Konfigurationen sind separate Concerns

Git-Workflows für Marketing-Teams

Der einfachste Workflow: Trunk-Based

Für den Anfang reicht ein simpler Workflow:

1. Alle arbeiten auf main
2. Änderungen per Pull Request – auch kleine
3. Mindestens ein Review vor dem Merge
4. Commit-Messages in Klartext: Content-Writer: Blog-Skill um FAQ-Sektion erweitert

Wenn das Team wächst: Feature Branches

main (produktive Konfiguration)
├── feature/new-email-skill     ← Neuer Skill für den Content-Writer
├── experiment/tone-shift       ← Brand Voice A/B-Test
└── fix/seo-prompt-hallucination ← Bug-Fix im SEO-Agenten

Der Vorteil: Ihr könnt neue Ansätze testen, ohne die bestehende Konfiguration zu gefährden. Wenn der Experiment-Branch nicht funktioniert, löscht ihr ihn einfach.

Pull Requests als Qualitätssicherung

Ein Pull Request für eine Prompt-Änderung sieht so aus:

## Was wurde geändert?
System-Prompt des Content-Writers: Neue Regel für Quellenangaben

## Warum?
Outputs hatten zu oft unbelegte Behauptungen

## Wie getestet?
5 Test-Outputs mit dem neuen Prompt generiert – alle mit Quellenverweisen

Das klingt nach Overhead. In Wahrheit spart es Zeit, weil Fehler vor dem Go-Live gefunden werden – nicht danach.

Die ersten 5 Schritte

1. GitHub-Account erstellen

Kostenlos unter github.com. Ein Account pro Person, eine Organisation für das Team.

2. Repository anlegen

Ein Repository pro Projekt oder für den gesamten Marketing-AI-Stack. Startet mit einem.

3. Ordnerstruktur aufsetzen

Nutzt die Vorlage oben oder passt sie an. Wichtig: README.md mit Übersicht für neue Teammitglieder.

4. Bestehende Dateien migrieren

Fangt mit einem Agenten an. Verschiebt dessen System-Prompt, Kontextdateien und Skills nach Git. Lasst den Rest vorerst auf Google Drive.

5. Team schulen

Die drei Befehle, die euer Team kennen muss:

Befehl	Was es tut
git pull	Neueste Änderungen holen
git add + commit + push	Eigene Änderungen hochladen
Pull Request erstellen	Änderung zur Review einreichen

Ihr braucht kein Terminal. GitHub Desktop oder die GitHub-Weboberfläche reicht für den Anfang völlig aus.

Häufige Einwände – und warum sie nicht greifen

„Git ist für Entwickler, nicht für Marketing"

Git ist für jeden, der Dateien versionieren und im Team bearbeiten muss. Die Lernkurve ist kürzer als ihr denkt – vor allem mit visuellen Tools wie GitHub Desktop.

„Das ist doch Overhead"

Der eigentliche Overhead ist, wenn jemand einen Prompt ändert, der eure KI-Pipeline zerstört, und niemand weiß, was die letzte funktionierende Version war.

„Unsere KI-Agenten laufen in Plattform X, nicht lokal"

Die meisten KI-Plattformen unterstützen Git-Integration oder File-Import. Und: Claude Code, Cursor und ähnliche Tools arbeiten nativ mit Git. Der Trend geht klar in Richtung Repository-basierter Workflows.

„Wir sind nur 3 Leute"

Fangt trotzdem an. Die Gewohnheit, Änderungen zu dokumentieren und zu reviewen, zahlt sich ab Tag 1 aus – unabhängig von der Teamgröße.

Was sich verändert, wenn ihr den Wechsel macht

• Rückverfolgbarkeit: Jede Änderung an jedem Prompt hat einen Autor, ein Datum und eine Begründung
• Qualität: Reviews fangen schlechte Prompt-Änderungen ab, bevor sie live gehen
• Experimente: Branches ermöglichen risikoloses Testen neuer Ansätze
• Onboarding: Neue Teammitglieder sehen die gesamte KI-Infrastruktur an einem Ort
• KI-Tooling: Claude Code und ähnliche Tools arbeiten direkt mit eurem Repository

Fazit

Marketing Operations werden zu Engineering Operations. Das klingt bedrohlich, ist aber befreiend: Die Werkzeuge, die Software-Teams seit Jahrzehnten nutzen, lösen exakt die Probleme, die Marketing-Teams jetzt haben.

Drei Dinge zum Mitnehmen:

1. Fangt mit einem Agenten an – migriert dessen Dateien nach Git und sammelt Erfahrung
2. Pull Requests sind euer Qualitäts-Gate – jede Prompt-Änderung wird gereviewed
3. Git ist kein Entwickler-Tool – es ist ein Kollaborations-Tool, das zufällig von Entwicklern erfunden wurde

→ Mehr über Agentic Engineering erfahren → Workshop buchen: KI-Workflows professionalisieren