Git-Grundlagen

Warum ist Git für meine Arbeit wichtig?

Versionskontrolle: Den Überblick im Projektchaos behalten

Stell dir vor, du arbeitest an einem umfangreichen Softwareprojekt, einer komplexen Webseite oder auch nur an einer wichtigen Präsentation mit vielen Überarbeitungsstufen. Du fügst neue Funktionen hinzu, änderst bestehende Teile, korrigierst Fehler und entfernst vielleicht auch wieder Code oder Inhalte. Wie behältst du da den Überblick? Was passiert, wenn du merkst, dass eine Änderung vor drei Tagen doch nicht so gut war und du zu einem früheren Stand zurückkehren möchtest? Genau hier kommt die Versionskontrolle ins Spiel. Sie ist wie ein detailliertes Logbuch für dein Projekt:

• Nachverfolgbarkeit: Jede Änderung wird erfasst. Du kannst sehen, wer was wann geändert hat.
• Wiederherstellbarkeit: Du kannst jederzeit zu einer früheren, funktionierenden Version deines Projekts zurückspringen.
• Zusammenarbeit: Mehrere Personen können gleichzeitig am selben Projekt arbeiten, ohne sich gegenseitig die Änderungen zu überschreiben.

Ohne Versionskontrolle enden Projekte oft in einem Chaos aus unzähligen Dateikopien wie projekt_final_v2_korrigiert.docx oder skript_alt_funktioniert_noch.py.

Git: Dein leistungsstarkes Werkzeug für Versionskontrolle

Git ist eines der weltweit am weitesten verbreiteten und leistungsfähigsten Systeme zur Versionskontrolle. Es wurde ursprünglich für die Entwicklung des Linux-Kernels konzipiert und wird heute von einzelnen Entwickelnden bis hin zu riesigen Unternehmen für Softwareprojekte jeder Größe eingesetzt. Git speichert nicht nur Dateien, sondern den gesamten Verlauf eines Projekts mit all seinen Änderungen. Es ist wie ein Zeitreise-Werkzeug für deinen Code oder deine Projektdaten, das dir erlaubt, sicher zu experimentieren und effizient im Team zu arbeiten.

Wie funktioniert Git im Kern?

Repository: Das Herz deines Projekts

Ein Repository (oft kurz "Repo" genannt) ist der zentrale Speicherort für dein gesamtes Projekt. Stell dir dein Projekt – zum Beispiel eine App, die du programmierst, oder eine Webseite, die du gestaltest – wie eine Sammlung von Bauplänen, Notizen und fertigen Teilen vor. Das Repository ist dann der spezielle Ordner auf deinem Computer (oder einem Server), der nicht nur all diese Dateien und Verzeichnisse sicher aufbewahrt, sondern auch jede einzelne Veränderung daran protokolliert. Wenn du ein neues Projekt beginnst, initialisierst du ein neues Repository mit dem Befehl git init im Projektordner. Wenn du an einem bestehenden Projekt mitarbeiten möchtest, das bereits auf einem Server liegt, klonst (kopierst) du das Repository mit git clone <url-des-remote-repository>.

Commit: Eine Momentaufnahme deiner Arbeit sichern

Ein Commit ist wie ein Schnappschuss oder ein Speicherpunkt deines Projekts zu einem bestimmten Zeitpunkt. Nachdem du sinnvolle Änderungen an deinen Dateien vorgenommen hast (z.B. eine neue Funktion implementiert oder einen Fehler behoben), bereitest du diese Änderungen für den Commit vor, indem du sie zur "Staging Area" hinzufügst. Das machst du mit git add <dateiname> für einzelne Dateien oder git add . für alle geänderten Dateien im aktuellen Verzeichnis und dessen Unterverzeichnissen. Jeder Commit erhält eine eindeutige Identifikationsnummer (einen "Hash") und wird mit einer Commit-Nachricht versehen, in der du kurz beschreibst, welche Änderungen du vorgenommen hast, zum Beispiel git commit -m "✨ Erste Version der Startseite abgeschlossen".

Branch: Sicher in parallelen Welten entwickeln

Ein Branch (deutsch: Zweig) ermöglicht es dir, von der Hauptentwicklungslinie deines Projekts (oft "main" oder "master" genannt) abzuweichen und in einem isolierten Bereich weiterzuarbeiten. Das ist extrem nützlich, um neue Funktionen zu entwickeln, Fehler zu beheben oder zu experimentieren, ohne den stabilen Hauptzweig zu gefährden. Einen neuen Branch erstellst du mit git branch <branchname>, zum Beispiel git branch feature/kontaktformular. Um dann in diesem neuen Branch zu arbeiten, wechselst du mit git checkout <branchname> oder dem neueren Befehl git switch <branchname> in diesen Zweig.

Merge: Zweige wieder zusammenführen

Wenn die Arbeit in einem Branch abgeschlossen und getestet ist (z.B. das Kontaktformular im Branch 'feature/kontaktformular' funktioniert einwandfrei), kannst du diesen Branch wieder mit einem anderen Branch (meist dem Hauptzweig) zusammenführen. Dieser Vorgang wird Merge genannt. Dazu wechselst du zuerst in den Ziel-Branch (z.B. git checkout main) und führst dann git merge <branchname-des-feature-branches> aus, also beispielsweise git merge feature/kontaktformular. Git versucht dabei, die Änderungen aus beiden Branches intelligent zu kombinieren.

Remote Repository: Gemeinsam im Team und online arbeiten

Ein Remote Repository ist eine Kopie deines Repositories, die auf einem Server im Internet gehostet wird (z.B. bei Diensten wie GitHub, GitLab oder Bitbucket). Es dient als zentraler Anlaufpunkt für die Zusammenarbeit im Team. Um dein lokales Repository mit einem solchen Online-Speicherort zu verbinden, verwendest du einmalig git remote add origin <url-des-remote-repository>. Danach können Teammitglieder ihre lokalen Änderungen (Commits) mit git push in das Remote Repository hochladen und mit git pull die neuesten Änderungen von anderen herunterladen, um ihre lokale Arbeitskopie zu aktualisieren. Es dient auch als Backup deines Projekts. Den aktuellen Zustand deines Arbeitsverzeichnisses und welche Dateien für einen Commit vorgemerkt sind, kannst du jederzeit mit git status überprüfen.

Was gehört nicht in die Versionskontrolle?

Warum bestimmte Dateien und Ordner ignorieren?

Nicht jede Datei, die sich in deinem Projektordner befindet, sollte auch von Git versioniert, also in die Historie aufgenommen werden. Es gibt gute Gründe, bestimmte Dateien oder ganze Ordner von der Versionskontrolle auszuschließen:

• Sensible Informationen: Konfigurationsdateien, die Passwörter, API-Schlüssel oder andere geheime Zugangsdaten enthalten (z.B. config.local.php, .env-Dateien).
• Generierte Dateien: Dateien, die automatisch von deinem Build-Prozess, Compiler oder deiner IDE erzeugt werden (z.B. kompilierter Code wie .class-Dateien in Java, Log-Dateien, temporäre Dateien, Abhängigkeiten, die über einen Paketmanager wie node_modules/ installiert werden).
• Betriebssystem- oder Editor-spezifische Dateien: Versteckte Dateien, die dein Betriebssystem (z.B. .DS_Store unter macOS, Thumbs.db unter Windows) oder dein Code-Editor (z.B. der Ordner .vscode/) anlegt.
• Große Binärdateien: Obwohl Git sie verwalten kann, ist es oft nicht ideal für sehr große Binärdateien (wie Videos oder hochauflösende Design-Entwürfe), da dies das Repository stark vergrößern kann. Hierfür gibt es spezielle Erweiterungen wie Git LFS (Large File Storage).

Um Git mitzuteilen, welche Dateien und Ordner es ignorieren soll, verwendest du eine spezielle Datei namens .gitignore.

Die Syntax der `.gitignore`-Datei

Die .gitignore-Datei ist eine einfache Textdatei, die du im Hauptverzeichnis deines Repositories anlegst. Jede Zeile in dieser Datei enthält ein Muster, das angibt, welche Dateien oder Verzeichnisse ignoriert werden sollen.

• Kommentare: Zeilen, die mit einem # beginnen, sind Kommentare und werden ignoriert.
• Dateinamen: Ein einfacher Dateiname (z.B. geheim.txt) ignoriert alle Dateien mit diesem Namen im gesamten Projekt.
• Verzeichnisse: Um ein ganzes Verzeichnis zu ignorieren, fügst du einen Schrägstrich am Ende hinzu (z.B. build/ ignoriert den Ordner build und seinen gesamten Inhalt).
• Wildcards: Du kannst Platzhalter verwenden. * steht für eine beliebige Zeichenfolge (z.B. *.log ignoriert alle Dateien mit der Endung .log).
• Negation: Ein Ausrufezeichen ! am Anfang einer Zeile hebt eine vorherige Ignorierregel für ein spezifischeres Muster auf.

Beispiel einer vereinfachten .gitignore-Datei:

# Ignoriere Betriebssystem-spezifische Dateien
.DS_Store
Thumbs.db

# Ignoriere alle Log-Dateien und Log-Verzeichnisse
*.log
logs/

# Ignoriere temporäre Dateien und Ordner
*.tmp
temp/

# Ignoriere lokale Konfigurationsdateien mit sensiblen Daten
config.local.*
.env

# Ignoriere von Build-Prozessen erzeugte Ordner
build/
dist/

# Ignoriere kompilierte Dateien (Beispiele)
*.o
*.class

Lernziele

• die Verwendung der .gitignore-Datei erklären, indem die Notwendigkeit des Ausschlusses bestimmter Dateien (z. B. Konfigurationsdateien mit Passwörtern, generierte Dateien) aus der Versionskontrolle und die Syntax der .gitignore-Datei erläutert werden.
• die Bedeutung von Versionskontrollsystemen erklären, indem die Vorteile von Versionskontrolle für die Zusammenarbeit im Team, die Nachverfolgbarkeit von Änderungen und die Wiederherstellung früherer Zustände anhand konkreter Beispiele aus der Softwareentwicklung erläutert werden.
• die grundlegenden Konzepte von Git erklären, indem die Begriffe Repository, Commit, Branch, Merge und Remote Repository sowie deren Bedeutung für die Versionskontrolle und Zusammenarbeit im Team erläutert werden.
• die grundlegenden Git-Befehle auszuführen, indem ein neues Repository initialisiert, Änderungen verfolgt, Commits erstellt, Branches verwaltet und Änderungen zwischen lokalen und Remote-Repositories synchronisiert werden.