Wer schon einmal Dateien wie Angebot_final_v3_NEU_WIRKLICHFINAL.docx an Kollegen weitergeleitet hat, kennt das Problem. Irgendwann weiß niemand mehr, welche Version gilt. Genau dieses Problem löst Git — das meistgenutzte Versionskontrollsystem der Welt. Und es ist längst kein reines Entwicklerwerkzeug mehr.
Inhalt:
Was ist Git überhaupt?
Git wurde 2005 von Linus Torvalds entwickelt — dem Gründer des Linux-Betriebssystems. Sein Ziel: ein System, das auch bei sehr großen Projekten mit vielen Beteiligten zuverlässig Änderungen nachverfolgt.
Das Ergebnis ist ein sogenanntes verteiltes Versionskontrollsystem. Das klingt technischer als es ist. Was es bedeutet: Jede Person im Team besitzt eine vollständige Kopie des Projekts — mit der gesamten Änderungshistorie. Wer hat was geändert, wann, und warum? Git speichert alles.
Was das für Sie bedeutet
Kein verlorenes Dokument mehr. Kein „Ich glaube, das war die Version vom Dienstag". Git ist das kollektive Gedächtnis Ihres Teams — zuverlässig, durchsuchbar, und ohne Mehraufwand.
Git vs. GitHub: Der Unterschied
Viele verwechseln Git und GitHub. Das eine ist das Werkzeug, das andere die Plattform.
Git — das Werkzeug
Git ist das Versionskontrollsystem — ein Programm, das lokal auf Ihrem Rechner läuft und Änderungen verfolgt.
GitHub — die Plattform
GitHub ist eine Plattform im Web, auf der Projekte gespeichert und geteilt werden. Hier kann ein Team an einer gemeinsamen Codebase arbeiten, Änderungen einreichen und diskutieren. Ähnliche Plattformen: GitLab, Bitbucket.
Die Analogie: Git ist die Zeiterfassung, GitHub ist das Büro, in dem alle zusammenarbeiten.
Was das für Sie bedeutet
Sie brauchen beides. Git als Handwerkszeug, GitHub als zentralen Ablageort für Ihr Team. GitHub bietet dazu Freigabeprozesse, Code-Reviews und eine komplette Projektverwaltung.
Die drei Bereiche, die Sie kennen müssen
Möchten Sie das konkret auf Ihren Betrieb anwenden?
Kostenlos Termin buchen
Justin Kollautz
KI Spezialist · Wurzelwerk
In Git gibt es drei Orte, an denen sich Ihre Arbeit befindet:
1. Arbeitsverzeichnis (Working Directory)
Hier arbeiten Sie — das sind die Dateien auf Ihrem Rechner, so wie Sie sie gerade sehen.
2. Staging-Bereich (Index)
Bevor Änderungen gespeichert werden, landen sie in der „Warteschlange". Sie entscheiden selbst, welche Änderungen zum nächsten Speicherpunkt gehören — und welche noch nicht.
3. Lokales Repository
Hier wird der Speicherpunkt (Commit) dauerhaft festgehalten. Die gesamte Projekthistorie lebt hier.
Das Besondere: Erst git push sendet diese Geschichte auf GitHub — und macht sie für das Team sichtbar.
Was das für Sie bedeutet
Dieser dreistufige Prozess klingt aufwendig, ist aber eine Stärke. Er zwingt zur Absicht: Was gehört zusammen? Was ist fertig? Was noch nicht? Das macht Arbeit nachvollziehbarer — auch für zukünftige Teammitglieder.
Branches: Parallel arbeiten ohne Chaos
Ein Branch ist ein separater Entwicklungszweig. Stellen Sie sich vor, jemand im Team entwickelt ein neues Feature, während ein anderer einen Fehler im bestehenden System behebt. Beide arbeiten gleichzeitig — aber an verschiedenen Branches — ohne sich gegenseitig zu behindern.
Ist eine Aufgabe abgeschlossen, wird der Branch mit dem Hauptstrang zusammengeführt (Merge). Git prüft automatisch, ob Konflikte entstehen — und zeigt diese klar an.
git checkout -b neues-feature # Neuen Branch erstellen und wechseln
git merge neues-feature # Branch wieder zusammenführenWas das für Sie bedeutet
Branches ermöglichen parallele Arbeit ohne das Risiko, stabile Teile des Projekts zu beschädigen. Gerade in wachsenden Teams ist das keine Nice-to-have-Funktion — es ist die Grundlage für professionelles Arbeiten.
Der typische Git-Workflow
Ein einfacher, vollständiger Zyklus sieht so aus:
# 1. Repository klonen (einmalig)
git clone git@github.com/mein-projekt
# 2. Branch erstellen
git checkout -b mein-feature
# 3. Änderungen vormerken
git add .
# 4. Änderung speichern
git commit -m "Funktion X hinzugefügt"
# 5. Änderungen hochladen
git push origin mein-featureDanach: Pull Request auf GitHub öffnen, Teammitglied prüft die Änderung, Merge auf den Hauptbranch.
Was das für Sie bedeutet
Dieser Ablauf ist lernbar — auch für Menschen ohne Programmierhintergrund. In einer halben Stunde Einführung kann jedes Teammitglied die Grundmechanik verstehen. Der Rest kommt mit der Übung.
Häufige Fragen
Muss ich Programmieren können, um Git zu nutzen?
Nein. Git ist ursprünglich für Code entwickelt worden, wird aber heute für alle Arten von Textdateien genutzt — Dokumentationen, Verträge, Konfigurationen, Marketingtexte. Wer mit der Kommandozeile nicht vertraut ist, kann auf grafische Oberflächen wie GitHub Desktop oder Tower zurückgreifen.
Was ist der Unterschied zwischen Reset und Revert?
git reset macht Commits rückgängig und löscht sie aus der Geschichte — sollte nur bei unveröffentlichten Änderungen genutzt werden. git revert erstellt einen neuen Commit, der die Änderungen zurücknimmt — sicher auch auf gemeinsam genutzten Branches.
Warum nicht einfach Dropbox oder SharePoint?
Diese Tools synchronisieren Dateien — aber sie verfolgen keine Änderungen auf Zeilenebene, ermöglichen keine Branches und bieten keinen strukturierten Review-Prozess. Für reine Ablage reicht Dropbox. Für kollaborative Entwicklungsarbeit braucht man Git.
Fazit: Struktur schlägt Zufall
Git und GitHub sind keine Entwickler-Spielzeuge. Sie sind Antworten auf ein universelles Problem: Wie arbeitet ein Team strukturiert an denselben Inhalten — ohne Chaos, ohne Datenverlust, ohne „welche Version ist jetzt die richtige?"
Die Lernkurve ist real, aber überschaubar. Die Alternative — dezentrale Dateiversionen, E-Mail-Anhänge, fehlende Nachvollziehbarkeit — kostet am Ende mehr Zeit und Nerven.
Nächster Schritt: Wenn Ihr Team heute noch keine Versionskontrolle nutzt, ist jetzt der richtige Zeitpunkt, das zu ändern. Sprechen Sie uns an — wir richten Ihnen eine saubere Git-Struktur ein, die zu Ihrem Workflow passt.