Quellcodeverwaltung

Quellcodeverwaltung (SCM) ist die Disziplin, jede Änderung am Quellcode eines Projekts über die Zeit zu verfolgen, aufzuzeichnen und zu koordinieren. Diese Seite erklärt, was SCM ist, warum jedes Team darauf angewiesen ist, wie Git dabei eine Rolle spielt, welchen Workflow es ermöglicht und welche Praktiken die Projekthistorie sauber halten.

Was ist Quellcodeverwaltung?

Quellcodeverwaltung ist die Praxis, Änderungen am Softwarecode zu verfolgen und zu verwalten. Sie wird fast immer mit einem Versionskontrollsystem (VCS) umgesetzt — einem Werkzeug, das jede Änderung an einem Repository aufzeichnet, sie einem Autor zuordnet, sie mit einem Zeitstempel versieht und es ermöglicht, in der Projekthistorie vor- und zurückzuspringen.

Git ist das heute am weitesten verbreitete VCS. Es ist verteilt, das heißt jeder Entwickler hält lokal eine vollständige Kopie der Projekthistorie vor, sodass Sie Commits erstellen, Branches anlegen und die Historie einsehen können, ohne eine Netzwerkverbindung zu benötigen. Es gibt auch andere Systeme (Subversion, Mercurial, Perforce), aber die Konzepte auf dieser Seite gelten für alle.

SCM und VCS werden oft gleichbedeutend verwendet. Streng genommen ist SCM die übergeordnete Praxis (Historie, Branching, Kollaborationsrichtlinien, Code-Review), und ein VCS wie Git ist das Werkzeug, das diese Praxis umsetzt.

Wenn Sie neu bei Git sind, beginnen Sie mit der Git-Einführung und erfahren Sie, wie Sie Ihr erstes Git-Repository erstellen.

Warum Quellcodeverwaltung wichtig ist

Ein VCS löst Probleme, die schmerzhaft werden, sobald mehr als eine Person — oder mehr als ein Arbeitstag — eine Codebasis berührt:

• Änderungen verfolgen – Jede Änderung wird automatisch aufgezeichnet, einem Autor zugeordnet und mit einer Commit-Nachricht dokumentiert, wodurch ein durchsuchbares historisches Protokoll entsteht.
• Synchronisierung – Teammitglieder holen den neuesten Code aus einem gemeinsamen Repository, sodass alle von derselben Basis aus arbeiten.
• Sicherung und Wiederherstellung – Da jeder Commit ein vollständiger Snapshot ist, kann jede Datei jederzeit in einen früheren Zustand wiederhergestellt werden.
• Rückgängig machen – Sie können zu jedem früheren Zustand zurückkehren, vom letzten Commit bis zu einer vor langer Zeit erstellten Version, ohne die Zwischenschritte zu verlieren.
• Branching und Merging – Die Arbeit findet auf isolierten Branches statt und wird nach Prüfung und Freigabe wieder zusammengeführt.
• Konflikterkennung – Wenn zwei Personen dieselben Zeilen ändern, überschreibt das VCS nicht stillschweigend eine Änderung mit der anderen; es meldet einen Merge-Konflikt, damit ein Mensch ihn lösen kann.

Ohne SCM greifen Teams auf das Komprimieren von Ordnern, den E-Mail-Versand von Dateien und das Benennen von Dingen wie final_v2_REALLY_final.js zurück — dabei geht die Historie verloren und man überschreibt gegenseitig die Arbeit.

Der grundlegende SCM-Workflow

Die meisten alltäglichen Arbeiten in Git folgen derselben Abfolge: Dateien ändern, stagen, einen Snapshot committen und die Historie einsehen. Das folgende Beispiel führt ein eigenständiges Repository aus, sodass Sie den Zyklus von Anfang bis Ende nachvollziehen können.

# Create and enter a fresh project
mkdir scm-demo && cd scm-demo

# 1. Turn the folder into a repository
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

# 2. Make a change
echo "console.log('hello');" > app.js

# 3. Stage the change, then record a snapshot (commit)
git add app.js
git commit -q -m "Add initial app"

# 4. Make a second change and commit it
echo "console.log('world');" >> app.js
git commit -q -am "Print world too"

# 5. Inspect the historical record
git log --oneline

Die Historie enthält jetzt zwei Snapshots, neuester zuerst (die kurzen Hashes auf der linken Seite werden pro Commit generiert und weichen daher bei Ihnen ab):

6524bb9 Print world too
88e2f34 Add initial app

Jedes git add verschiebt Änderungen in den Staging-Bereich, und jedes git commit friert den gestageten Inhalt in einen dauerhaften, benannten Snapshot ein. Die Ausgabe von git log ist das historische Protokoll, das SCM Ihnen liefert — hier zwei Zeilen, eine pro Commit, jeweils mit einem kurzen Hash und einer Nachricht. Jederzeit können Sie git status ausführen, um zu sehen, was geändert, gestaget oder nicht verfolgt ist.

Branching und Merging

Das Feature, das SCM für Teams mächtig macht, ist die Isolation durch Branches. Jeder Entwickler (oder jedes Feature) erhält eine eigene Entwicklungslinie; wenn die Arbeit überprüft und bereit ist, wird sie wieder in den Hauptbranch gemergt.

mkdir branch-demo && cd branch-demo
git init -q
git config user.email "[email protected]"
git config user.name "Dev"

echo "line 1" > notes.txt
git add notes.txt
git commit -q -m "Start notes"

# Remember the main branch name (main or master)
main=$(git branch --show-current)

# Create a branch, switch to it, add work there
git switch -c feature
echo "line 2 from feature" >> notes.txt
git commit -q -am "Add feature line"

# Go back to the main branch and merge the feature in
git switch -q "$main"
git merge -q feature

cat notes.txt

Nach dem Merge enthält notes.txt die Arbeit aus beiden Branches:

line 1
line 2 from feature

Der feature-Branch ermöglichte es, die neue Entwicklungslinie voranzutreiben, ohne main zu berühren, und git merge hat sie wieder zusammengeführt. Bei einem gemeinsam genutzten Projekt würden Sie außerdem das Repository mit git clone klonen und vor dem Start git pull ausführen, damit Sie auf dem neuesten Stand aufbauen.

Best Practices

• Häufig und in kleinen Einheiten committen. Ein Commit ist ein Snapshot; kleine, fokussierte Commits bieten viele sichere Rückkehrpunkte und machen die Historie leicht lesbar. Zusammengehörige Commits können später zusammengefasst werden, um das Protokoll sauber zu halten.
• Immer von der aktuellen Version ausgehen. Pullen oder fetchen Sie den gemeinsamen Code, bevor Sie beginnen, damit Sie auf dem aktuellen Stand aufbauen und Merge-Konflikte minimieren.
• Aussagekräftige Commit-Nachrichten schreiben. Eine klare Nachricht, die erklärt, was sich geändert hat und warum, wird unverzichtbar, wenn ein Projekt wächst und andere Personen (einschließlich Ihr zukünftiges Ich) das Protokoll lesen.
• Vor dem Commit überprüfen. Der Staging-Bereich ermöglicht es Ihnen, Bearbeitungen zu sammeln und zu prüfen, bevor sie in einen Snapshot umgewandelt werden — überprüfen Sie den Diff, damit jeder Commit bewusst gesetzt ist.
• Branches zur Isolation verwenden. Entwickeln Sie jedes Feature oder jeden Fix auf einem eigenen Branch und mergen Sie ihn erst nach einer Überprüfung, damit der Hauptbranch stabil bleibt.
• Einen gemeinsamen Workflow vereinbaren. Legen Sie Teamkonventionen für Branching, Review und Merging fest. Gängige Muster werden in Git-Workflows behandelt.

Übung