Ich treffe regelmäßig auf Projekte, bei denen der Code auf einem FTP-Server lebt. Änderungen werden ermittelt, indem man zwei Ordner miteinander vergleicht. Ein Rollback bedeutet, die alte Version hochzuladen – sofern man sie noch hat. Das klingt nach einer Ausnahme. Es ist keine.

Warum es diese Projekte gibt

Ich mache niemandem daraus einen Vorwurf. Diese Projekte sind oft so entstanden: Ein Entwickler hat damals schnell etwas gebaut. Kein Team, keine Infrastruktur, kein Prozess. Git war vielleicht bekannt, aber der Aufwand schien nicht gerechtfertigt. Mit der Zeit ist das Projekt gewachsen – und die fehlende Versionskontrolle ist einfach mitgewachsen. Das ist keine Faulheit, das ist ein Prozess-Problem.

Schritt 1: git init – und nicht mehr

Der erste Schritt ist klein und soll es bleiben. Kein Umstrukturieren, kein Aufräumen, kein "wir machen das jetzt richtig". Nur das hier: 

cd /pfad/zum/projekt
git init

Danach kommt eine .gitignore. Die ist wichtig – und zwar bevor irgendein Commit gemacht wird. In Legacy-Projekten liegen Passwörter häufig in Konfigurationsdateien direkt im Projektordner. Außerdem gibt es oft einen uploads/-Ordner mit Kundendaten, der nichts im Repository zu suchen hat. 

# .gitignore
config/database.php
uploads/
*.log
*.bak

Schritt 2: Erster Commit

Der erste Commit enthält den aktuellen Stand – nicht mehr, nicht weniger. Keine Refactorings, keine Umbenennungen, kein "kurz noch schnell". Der Wert dieses Commits ist, dass ab jetzt jede Änderung nachvollziehbar ist. 

git add .
git commit -m "Initial commit: aktueller Projektstand"

Schritt 3: Team einführen – mit einem einfachen Workflow

Das ist der schwierigste Schritt – nicht technisch, sondern menschlich. Ein Team, das jahrelang ohne Git gearbeitet hat, braucht keinen komplexen Branching-Workflow am ersten Tag. Was funktioniert: eine einzige Regel, bevor jemand Änderungen macht. 

git commit -m "Vor Änderung: Stand sichern"

Das reicht für den Anfang. Kein Feature-Branching, kein Pull-Request-Prozess. Nur: Commit vor jeder Änderung, Commit nach jeder Änderung. Konventionen für Commit-Messages, Branching-Strategien, Code-Reviews – das kommt später, wenn das Team angekommen ist.

Schritt 4: Remote-Repository als Backup

Sobald der erste Workflow sitzt, lohnt sich ein Remote-Repository auf GitHub oder GitLab. Nicht als Collaboration-Plattform – zunächst nur als Backup. 

git remote add origin https://github.com/meinprojekt/repo.git
git push -u origin main
Der häufigste Fehler bei der Git-Einführung: zu viele Konventionen auf einmal. Wer einem Team gleichzeitig Git, Commit-Message-Regeln, Branching-Strategie und Pull Requests erklärt, verliert das Team. Erst ankommen lassen. Dann verfeinern.

Fazit

Git einzuführen ist kein technisches Problem. Es ist ein Gewohnheitsproblem. Der technische Teil dauert zehn Minuten. Der Rest ist Geduld und Konsequenz. Wenn nach zwei Wochen jeder im Team vor einer Änderung committed, hat man gewonnen – egal wie die Commit-Messages aussehen.