← Alle Insights
7 Min. Lesezeit · Workflow · August 2029

Git-Workflows für Trader-Teams: was aus Software-Engineering hilft.

Trader sind selten Software-Entwickler, und das merkt man ihren Codebasen an: Backup-Dateien mit Namen wie strategy_final_v2_wirklich_final.py, kopierte Parameter zwischen Skripten, vergessene Änderungen am Wochenende, an die sich Montag niemand mehr erinnert. Git löst keine Strategie-Probleme — aber es löst etwa 80 % der operativen Probleme, die Trading-Teams bremsen. Selbst Solo-Trader profitieren.

Warum Git auch für Einzelne.

Drei Gründe, in dieser Reihenfolge:

Standard-Workflow: main, dev, feature.

Das einfachste Modell, das in der Praxis funktioniert — adaptiert vom klassischen GitFlow, aber bewusst leichter:

Der Workflow ist: feature-Branch → Pull-Request auf dev → Test in Paper-Trading-Setup → Merge auf main → Tag mit Datum/Version → Deploy. Wer alleine arbeitet, lässt Pull-Requests weg, taggt aber trotzdem jedes Production-Release.

Strategie-Code: ein Repo pro Strategie oder Monorepo.

Die Wahl hängt vom Team und der Strategie-Anzahl ab:

Mein Default für Mandanten: ein Repo pro Mandantenstrategie, plus ein gemeinsames trading-core-Repo, das als Git-Submodule oder als versioniertes Wheel eingebunden wird. Das gibt klare Trennlinien und erlaubt mir, einem Mandanten gezielt seinen Repo zu übergeben, wenn die Beratung endet.

Secrets gehören nicht ins Repo. Nie.

Die häufigste Katastrophe, die ich bei Mandanten sehe: API-Keys im Git-History. Einmal commited, einmal gepusht, einmal in irgendeinem Fork — und der Key ist kompromittiert. Ein minimaler .gitignore, der diese Klasse von Fehlern verhindert: 

# Secrets & Credentials
.env
.env.*
!.env.example
secrets/
*.key
*.pem
credentials.json
config/production.yml

# Trading-Output
logs/
data/raw/
data/processed/
backtest_results/
*.parquet
*.feather

# Python
__pycache__/
*.py[cod]
.venv/
.pytest_cache/

# IDE
.idea/
.vscode/
*.swp

Zusätzlich empfehle ich pre-commit mit dem detect-secrets-Hook — der scannt jede Änderung auf API-Key-Muster, bevor sie commited wird. Eine vergessene Datei wird so abgefangen.

Pre-Commit-Hooks: Lint, Tests, Secrets-Scan.

Pre-Commit-Hooks laufen automatisch vor jedem Commit. Ein Commit, der Linting bricht oder Tests nicht besteht, kommt erst gar nicht zustande. Eine pragmatische .pre-commit-config.yaml für ein Python-Trading-Repo: 

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: check-yaml
      - id: end-of-file-fixer
      - id: trailing-whitespace
      - id: check-added-large-files
        args: ['--maxkb=500']
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.5.0
    hooks:
      - id: ruff
      - id: ruff-format
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
  - repo: local
    hooks:
      - id: pytest-fast
        name: pytest (fast)
        entry: pytest tests/unit -q
        language: system
        pass_filenames: false
        stages: [commit]

Wichtig: nur schnelle Tests in den Pre-Commit-Hook. Tests, die mehr als 30 Sekunden laufen, gehören in die CI, nicht in den lokalen Commit-Workflow — sonst werden Hooks irgendwann mit --no-verify umgangen.

Production-Tagging vor jedem Deploy.

Eine Disziplin, die ich nie wieder aufgebe: jedes Production-Deployment bekommt einen Git-Tag. Standardisiert nach prod-YYYY-MM-DD-strategy oder Semantic-Versioning, je nach Setup: 

# Vor dem Deploy
git checkout main
git pull
git tag -a prod-2029-08-15-meanrev -m "Mean-Reversion v2.3, Param-Update"
git push origin prod-2029-08-15-meanrev

# Rollback bei Problem
git checkout prod-2029-08-12-meanrev
./deploy.sh

Vorteil: Wenn ein Bot am Donnerstag plötzlich verrückt spielt, sehen Sie in Sekunden, welche Version produktiv läuft — und können in 60 Sekunden auf die letzte funktionierende zurück. Ohne Tags suchen Sie in Logs nach Commit-Hashes.

GitHub Private vs. Self-Hosted.

Wo das Repo liegt, ist eine Entscheidung mit Compliance- und Vertrauenskomponente:

Wer auf einer eigenen Maschine hostet, sollte unbedingt automatisierte Off-Site-Backups haben — sonst war die Datenhoheit am Tag des Disk-Crashs umsonst.

Branching-Modell für Mandanten-Projekte.

Wie ich Mandantenarbeit organisiere — bewusst einfach, weil der Bottleneck selten die Branch-Strategie ist, sondern die Kommunikation:

Jedes Mandanten-Setup bekommt sein eigenes Repo — keine Vermischung. Wenn die Zusammenarbeit endet, übergebe ich vollständige Repo-Hoheit. Der Mandant hat damit nicht nur den Code, sondern die gesamte Historie aller Entscheidungen.

Sie haben Trading-Code, der über drei Rechner verteilt liegt, und niemand weiß, welche Version wirklich läuft? Erstgespräch buchen — wir bringen Ordnung in den Strategie-Code, ohne Sie zu Software-Engineers umzuschulen.