Für die Prüfung ist der Unterschied zwischen zentraler und dezentraler Versionsverwaltung relevant.

Zentrale Versionsverwaltung (z. B. SVN)

Bei einem zentralen System gibt es genau ein Repository auf einem Server. Alle Beteiligten laden sich Dateien von diesem Server herunter, bearbeiten sie und laden Änderungen wieder hoch. Fällt der Server aus, kann niemand Änderungen speichern oder die Historie einsehen.

Dezentrale Versionsverwaltung (z. B. Git)

Bei Git besitzt jeder Entwickler eine vollständige Kopie des Repositorys auf seinem Rechner. Änderungen werden lokal gespeichert (committet) und erst im nächsten Schritt mit einem Remote-Repository synchronisiert. Fällt ein Server aus, kann lokal weitergearbeitet werden. Die Daten sind durch die Verteilung auf mehrere Rechner besser gegen Verlust geschützt.

Bevor es an die Befehle geht, müssen die zentralen Begriffe sitzen.

• Repository (Repo): Ein Verzeichnis, das alle Projektdateien und die komplette Änderungshistorie enthält. Es gibt lokale Repositories (auf dem eigenen Rechner) und Remote-Repositories (z. B. auf GitHub oder GitLab).
• Commit: Ein Snapshot des Projekts zu einem bestimmten Zeitpunkt. Jeder Commit hat eine eindeutige ID (SHA-1-Hash), einen Autor, ein Datum und eine Nachricht, die beschreibt, was geändert wurde.
• Branch: Eine eigenständige Entwicklungslinie. Branches ermöglichen paralleles Arbeiten an verschiedenen Features, ohne den Hauptcode zu beeinflussen. Der Standard-Branch heißt in der Regel main (früher master).
• Merge: Das Zusammenführen zweier Branches. Änderungen aus einem Feature-Branch werden in den Hauptbranch integriert.
• Staging Area (Index): Ein Zwischenbereich zwischen dem Arbeitsverzeichnis und dem Repository. Hier werden Änderungen gesammelt, bevor sie per Commit gespeichert werden.
• Remote: Ein entferntes Repository, z. B. auf GitHub, GitLab oder Bitbucket. Dient als zentrale Anlaufstelle für die Zusammenarbeit im Team.

Git unterscheidet drei Zustände für Dateien:

1. Modified: Die Datei wurde geändert, aber die Änderung ist noch nicht in der Staging Area.
2. Staged: Die Änderung wurde mit git add in die Staging Area aufgenommen und ist bereit für den nächsten Commit.
3. Committed: Die Änderung ist im lokalen Repository gespeichert.

Der typische Workflow ist: Datei ändern → git add → git commit. Erst mit git push landet die Änderung im Remote-Repository.

Schauen wir uns einmal die wichtigsten Git-Befehle an:

Repository erstellen und konfigurieren

bash

# Neues Repository initialisieren

git init
 

# Bestehendes Repository klonen

git clone https://github.com/benutzer/projekt.git

# Benutzername und E-Mail konfigurieren

git config --global user.name "Max Mustermann"

git config --global user.email "max@beispiel.de"

git init erstellt ein neues, leeres Repository im aktuellen Verzeichnis. git clone kopiert ein bestehendes Remote-Repository auf den eigenen Rechner, inklusive der gesamten Historie.

Änderungen verwalten

bash

# Status des Repositories anzeigen

git status

# Einzelne Datei zur Staging Area hinzufügen

git add dateiname.txt

# Alle geänderten Dateien zur Staging Area hinzufügen

git add .

# Commit erstellen mit Nachricht

git commit -m “Login-Formular implementiert”

# Änderungen im Arbeitsverzeichnis anzeigen

git diff

git status zeigt den aktuellen Zustand: welche Dateien geändert, gestaged oder ungetrackt sind. Das ist der Befehl, der in der Praxis am häufigsten genutzt wird, um den Überblick zu behalten.

Mit Branches arbeiten

bash

# Alle Branches anzeigen

git branch

# Neuen Branch erstellen

git branch feature-login

# Zu einem Branch wechseln

git checkout feature-login
 

# Branch erstellen und direkt wechseln (Kurzform)

git checkout -b feature-login
 

# Branch zusammenführen (von main aus)

git merge feature-login
 

# Branch löschen (nach erfolgreichem Merge)

git branch -d feature-login

Ein typischer Workflow: Neuen Branch für ein Feature erstellen, dort entwickeln, testen, und anschließend per Merge in den Hauptbranch integrieren. So bleibt der main-Branch stabil.

Mit Remote-Repositories arbeiten

bash

# Remote-Repository hinzufügen

git remote add origin https://github.com/benutzer/projekt.git
 

# Lokale Commits zum Remote-Repository hochladen

git push origin main

# Änderungen vom Remote-Repository herunterladen und mergen

git pull origin main

# Nur herunterladen, ohne zu mergen

git fetch origin

git push überträgt lokale Commits ins Remote-Repository. git pull holt Änderungen anderer Teammitglieder ab und führt sie mit dem lokalen Branch zusammen. git pull ist eine Kombination aus git fetch (herunterladen) und git merge (zusammenführen).

Historie einsehen

bash

# Commit-Historie anzeigen

git log
 

# Kompakte Ansicht der Historie

git log --oneline

# Grafische Darstellung der Branches

git log --oneline --graph

Wenn zwei Personen dieselbe Stelle in einer Datei ändern, entsteht ein Merge-Konflikt. Git kann dann nicht automatisch entscheiden, welche Version korrekt ist.

In der betroffenen Datei markiert Git die Konfliktstelle:

<<<<<<< HEAD

Zeile aus dem aktuellen Branch

=======

Zeile aus dem zu mergenden Branch

>>>>>>> feature-login

Die Lösung: Datei öffnen, die richtige Version manuell auswählen, die Konfliktmarkierungen entfernen und die Datei anschließend committen.

bash

# Nach dem manuellen Lösen des Konflikts

git add dateiname.txt

git commit -m "Merge-Konflikt in dateiname.txt gelöst"

Nicht jede Datei gehört ins Repository. Build-Artefakte, temporäre Dateien oder Konfigurationsdateien mit Zugangsdaten sollten ausgeschlossen werden. Dafür gibt es die Datei .gitignore im Stammverzeichnis des Projekts.

# Beispiel .gitignore

node_modules/

*.log

.env

build/

*.class

Jede Zeile definiert ein Muster. Dateien und Verzeichnisse, die auf das Muster passen, werden von Git ignoriert.

Der Ablauf in einem Team sieht in der Regel so aus:

1. Repository klonen: git clone
2. Neuen Feature-Branch erstellen: git checkout -b feature-xyz
3. Änderungen durchführen und regelmäßig committen: git add + git commit
4. Aktuelle Änderungen vom Remote holen: git pull origin main
5. Feature-Branch ins Remote-Repository pushen: git push origin feature-xyz
6. Merge (oder Pull Request) in den Hauptbranch

Pull Requests (bei GitHub) bzw. Merge Requests (bei GitLab) sind ein verbreiteter Mechanismus, um Codeänderungen vor dem Merge von anderen Teammitgliedern prüfen zu lassen.

Zusammenfassung

Die Grundlagen lassen sich auf wenige Punkte verdichten:

• Git ist ein dezentrales Versionskontrollsystem. Jeder Entwickler hat eine vollständige Kopie des Repositorys.
• Der Workflow besteht aus: ändern → stagen (git add) → committen (git commit) → pushen (git push).
• Branches ermöglichen paralleles Arbeiten. Merges führen Branches zusammen.
• Konflikte entstehen, wenn dieselbe Stelle von mehreren Personen geändert wird. Sie müssen manuell gelöst werden.
• Die .gitignore steuert, welche Dateien nicht ins Repository gehören.

Für die Prüfung gilt: Die Begriffe (Repository, Commit, Branch, Merge, Staging Area) solltest du sicher beherrschen und den grundlegenden Workflow mit den zugehörigen Befehlen kennen. Wenn du das drauf hast, bist du für die Fragen zur Versionsverwaltung vorbereitet.

In unseren Prüfungvorbereitungskursen wiederholen wir die Inhalte aus deiner Ausbildung intensiv und bereiten dich so optimal auf die Abschlussprüfung Teil 1 und 2 für Fachinformatiker Anwendungsentwicklung oder Systemintegration vor. 

P.S.: Mit dem Bildungsscheck 2.0 kannst du dir bis zu 50 % der Kursgebühr, maximal aber 500 € fördern lassen. 

Du hast Fragen zur Prüfungsvorbereitung? Dann melde dich gerne bei uns!