Ist Git ein SCM oder VCS? Der Unterschied klar erklärt

Ist Git ein SCM oder VCS?

Die Frage klingt nach einem Entweder-oder, ist aber keins. Git ist ein verteiltes Versionskontrollsystem (VCS) und gleichzeitig ein SCM-Werkzeug (Source Code Management). Die beiden Begriffe schließen sich nicht aus, sondern beschreiben Git aus zwei Blickwinkeln: VCS meint die technische Funktion, SCM die übergeordnete Disziplin, zu der diese Funktion gehört. Wo die Grenze verläuft und warum sie in der Praxis kaum ins Gewicht fällt, zeigen die folgenden Abschnitte — inklusive der Abgrenzung zu GitHub und zum klassischen Konfigurationsmanagement.

Die kurze Antwort

VCS ist eine Teilmenge von SCM. Ein Versionskontrollsystem kümmert sich um das Kernproblem: Änderungen an Dateien über die Zeit festhalten, vergleichen und zurücknehmen. SCM umfasst das und noch mehr — Verzweigungsstrategien, Zusammenarbeit im Team, Zugriffsrechte, Release-Verwaltung. Git deckt beides ab. Nicht ohne Grund heißt die offizielle Website git-scm.com: Das „SCM” steht dort für Source Code Management.

Was ist ein Versionskontrollsystem (VCS)?

Ein VCS (deutsch: Versionsverwaltung oder Versionskontrolle) protokolliert jede Änderung an Ihren Dateien. Statt Ordner wie projekt_final, projekt_final_2, projekt_wirklich_final anzulegen, halten Sie den Stand in sauberen, benannten Versionen fest. Ein VCS erlaubt Ihnen:

• jede Änderung mit Autor, Zeitstempel und Beschreibung nachzuvollziehen,
• zu einem früheren Stand zurückzukehren, wenn etwas kaputtgeht,
• parallele Entwicklungslinien (Branches) anzulegen und wieder zusammenzuführen,
• im Team an derselben Codebasis zu arbeiten, ohne sich gegenseitig zu überschreiben.

Zentral oder verteilt: der entscheidende Unterschied

VCS gibt es in zwei Bauarten. Zentrale Systeme wie Subversion (SVN) oder das ältere CVS speichern die gesamte Historie auf einem Server; jeder Entwickler holt sich nur die aktuelle Arbeitskopie. Ist der Server offline, geht wenig.

Verteilte Systeme wie Git oder Mercurial funktionieren anders: Jeder Klon eines Repositorys enthält die komplette Historie. Sie können committen, branchen und die Geschichte durchsuchen, während Sie offline sind — synchronisiert wird erst später mit git push und git fetch. Diese Bauart heißt DVCS (Distributed Version Control System), und Git ist ihr bekanntester Vertreter. Wie das Nachladen vom Server genau abläuft, lesen Sie unter Was macht git fetch?.

Was bedeutet SCM?

Beim Kürzel SCM lauern zwei Auflösungen, die man leicht verwechselt:

1. Source Code Management (Quellcode-Verwaltung): der praktische Umgang mit Quellcode im Team — Versionierung, Branches, Merges, Code-Reviews, Zugriffskontrolle. In diesem Sinn nutzt Git den Begriff auf git-scm.com.
2. Software Configuration Management (Software-Konfigurationsmanagement): eine breitere Disziplin aus der klassischen Softwaretechnik, die zusätzlich Build-Konfigurationen, Auslieferungen, Baselines und Änderungsprozesse umfasst.

Im Entwickleralltag ist fast immer die erste Bedeutung gemeint. SCM in diesem Sinn ist der Oberbegriff, unter den die reine Versionskontrolle fällt — plus alles, was Zusammenarbeit an einer Codebasis organisiert. Verwechseln Sie SCM in diesem Kontext nicht mit einem „SCM-Portal”: Was damit gemeint ist, klärt der Beitrag Was ist ein SCM-Portal?.

Warum Git in beide Kategorien fällt

Git liefert die technische Grundlage (das VCS) und zugleich die Werkzeuge, die Source Code Management ausmachen:

• Branching und Merging sind in Git bewusst leichtgewichtig — ein Branch ist im Kern nur ein Verweis auf einen Commit. Das macht Feature-Branches und Verzweigungsstrategien praktikabel.
• Commit-Historie mit Metadaten dokumentiert, wer was wann und warum geändert hat.
• Verteilte Repositorys erlauben Zusammenarbeit ohne zentrale Sperren.
• Aufsätze wie Pull Requests, Code-Reviews und Zugriffsrechte kommen über Plattformen wie GitHub oder GitLab dazu — sie erweitern das SCM, ersetzen Git aber nicht.

Kurz: Git ist die Engine. Ob Sie das „Versionskontrolle” oder „Source Code Management” nennen, hängt nur davon ab, wie weit Sie den Rahmen ziehen.

Was Git konkret macht — mit Befehlen

Ein paar Befehle zeigen die Funktion greifbarer als jede Definition. Ein typischer Einstieg:

git init                 # neues Repository im aktuellen Ordner anlegen
git add datei.txt        # Änderung für den nächsten Commit vormerken (Staging)
git commit -m "Erste Version"   # den vorgemerkten Stand dauerhaft festhalten
git branch feature-x     # neue Entwicklungslinie erstellen
git checkout feature-x   # auf diese Linie wechseln (oder: git switch feature-x)
git merge feature-x      # die Linie wieder in den Hauptzweig einführen
git log --oneline --graph   # die Historie als Verlauf anzeigen

Zwei Details, die Git von manch anderem VCS abheben: Es gibt eine Staging-Area (auch Index genannt) zwischen Arbeitsverzeichnis und Historie — mit git add entscheiden Sie gezielt, welche Änderungen in den nächsten Commit wandern. Und Git speichert intern Snapshots des Projektzustands, nicht bloß Zeilendifferenzen; jeder Commit wird über eine Prüfsumme (historisch SHA-1, neuere Git-Versionen unterstützen zusätzlich SHA-256) eindeutig adressiert.

Wer den Hauptzweig nach einem Merge aufräumen will, findet die Schritte unter Wie lösche ich einen Git-Branch lokal und remote?.

Git ist nicht GitHub

Ein häufiger Denkfehler: Git und GitHub gleichzusetzen. Git ist das Werkzeug, das auf Ihrem Rechner läuft. GitHub (ebenso GitLab, Bitbucket, Codeberg) ist ein Hosting-Dienst, der Git-Repositorys im Netz bereitstellt und um Oberfläche, Rechteverwaltung, Issues und Pull Requests ergänzt. Sie können Git komplett ohne GitHub nutzen — und GitHub setzt Git voraus, nicht umgekehrt. Die Abgrenzung im Detail: Ist Git SCM dasselbe wie GitHub?.

Woher Git kommt — und was das erklärt

Git wurde 2005 von Linus Torvalds für die Entwicklung des Linux-Kernels geschrieben, nachdem das zuvor genutzte, kommerzielle BitKeeper seine kostenlose Nutzung für das Kernel-Projekt beendet hatte. Drei Ziele bestimmten das Design: hohe Geschwindigkeit auch bei riesigen Projekten, ein wirklich verteiltes Modell ohne zentrale Sperren und robuster Schutz gegen unbemerkte Datenmanipulation über Prüfsummen. Diese Prioritäten erklären, warum Git heute Standard ist — und warum es sowohl als reines VCS als auch als vollwertige SCM-Lösung durchgeht.

FAQ

Ist Git ein VCS oder ein SCM? Beides. Technisch ist Git ein verteiltes Versionskontrollsystem. Weil es zusätzlich Branching, Zusammenarbeit und Codeverwaltung im Team abdeckt, gilt es zugleich als Source-Code-Management-Werkzeug. VCS ist dabei der engere, SCM der umfassendere Begriff.

Wofür steht das „SCM” in git-scm.com? Für Source Code Management. Es ist die offizielle Projektwebsite von Git und betont, dass Git mehr leistet als bloße Versionierung — nämlich die gesamte Verwaltung von Quellcode.

Ist SVN auch ein SCM? Ja. Auch Subversion (SVN) ist ein Versionskontrollsystem und damit ein SCM-Werkzeug. Der Unterschied zu Git liegt nicht in der Kategorie, sondern in der Architektur: SVN arbeitet zentral, Git verteilt. Für die meisten neuen Projekte ist Git heute die naheliegende Wahl.