1. Das Problem ohne Versionskontrolle: warum einfach Dateien zu kopieren eine schlechte Idee ist
Fangen wir mit einer Alltagssituation an. Stell dir vor, du arbeitest an deinem C#-Projekt. Alles läuft gut, bis der Moment der "Experimente" kommt. Du entscheidest dich, etwas zu ändern, hast aber Angst, die funktionierende Version kaputt zu machen. Was tun? Natürlich das Projekt kopieren!
Am Ende liegen auf deiner Festplatte solche Meisterwerke:
MyProject/
├── Main.cs
├── Main_backup.cs
├── Main_final.cs
├── Main_final2.cs
├── Main_tochno_final.cs
├── Main_tochno_tochno_final.cs
Kommt dir das bekannt vor? Und jetzt stell dir vor, ein Kollege steigt ins Projekt ein. Er kopiert Dateien auch — nur auf seine Weise. Wie findet man heraus, welche Version die aktuellste und funktionierende ist? Wie erkennt man, wer was geändert hat? Wie stellt man alles wieder her, wenn das Experiment schiefgeht?
Ohne Versionskontrolle:
- Es ist leicht, funktionierenden Code zu verlieren oder zu verwechseln.
- Man kann nicht zu einer älteren Version "zurückrollen".
- Es ist schwer, zu zweit oder zu dritt zusammenzuarbeiten.
- Chaos und Angst vor Experimenten.
Genau diese Probleme lösen Versionskontrollsysteme — zum Beispiel Git.
2. Warum braucht ein Entwickler Git?
Git — ist ein mächtiges Versionsverwaltungssystem, das verwendet wird, um Änderungen im Quellcode während der Softwareentwicklung zu verfolgen. Es ermöglicht Entwicklern, verschiedene Versionen von Dateien zu speichern und die Arbeit mehrerer Personen an einem gemeinsamen Projekt zu koordinieren.
Wichtige Konzepte in Git:
Repository
Ein Repository (oder "repo") ist der Ort, an dem die gesamte Geschichte des Projekts gespeichert wird, einschließlich aller Änderungen und Versionen der Dateien.
Commits
commit — das ist der gespeicherte Zustand des Projekts. Jeder Commit in Git enthält Informationen darüber, welche Änderungen am Projekt vorgenommen wurden, von wem und wann. Commits bilden die Historie des Projekts und erlauben es, zu jeder früheren Version zurückzukehren.
gitGraph
commit id: "1"
commit id: "2"
commit id: "3"
commit id: "4"
commit id: "5"
commit id: "6"
Jeder Commit ist ein "Snapshot" des Projekts, der dem vorherigen folgt und so eine sequenzielle Änderungshistorie bildet.
Branches
branch — das ist eine unabhängige Entwicklungsline. Standardmäßig erstellt Git den Branch main. Du kannst neue Branches anlegen, um neue Features oder Fixes zu entwickeln und sie dann wieder in den Hauptbranch zu mergen.
gitGraph
commit id: "1"
commit id: "2"
branch develop
commit id: "3"
commit id: "4"
commit id: "5"
checkout main
commit id: "6"
commit id: "7"
merge develop
commit id: "8"
commit id: "9"
Vom Hauptbranch main wird der Branch develop abgespalten, um parallel zu entwickeln. Nach Abschluss werden die Änderungen aus develop zurück in main gemerged.
3. Grundlegende Git-Befehle (was unter der Haube passiert)
Unten steht eine Liste der grundlegenden Befehle für die Arbeit mit Git im Terminal. Es ist wichtig zu verstehen, welche Befehle die Basis aller Operationen bilden. Allerdings werden wir den GUI-Ansatz verfolgen und lernen, all diese Aktionen mit der grafischen Oberfläche von IntelliJ IDEA durchzuführen. Betrachte diese Befehle als das, was "unter der Haube" passiert.
| Befehl | Beschreibung |
|---|---|
git init |
Initialisiert ein neues Git-Repository im aktuellen Verzeichnis. |
git clone |
Klont ein Repository von einer URL in ein neues Verzeichnis. |
git add |
Fügt Dateien zum Staging-Bereich für den nächsten Commit hinzu. |
git commit |
Schreibt die vorbereiteten Änderungen in das Repository. |
git push |
Sendet Änderungen vom lokalen Repository zum Remote-Repository. |
git pull |
Aktualisiert den aktuellen Branch mit der neuesten Version aus dem Remote-Repository. |
git branch |
Zeigt Branches an, erstellt oder löscht Branches. |
git merge |
Führt die Änderungen des angegebenen Branches in den aktuellen Branch zusammen. |
Diese Befehle sind die grundlegenden Werkzeuge in Git und erlauben es, Änderungen am Code, Branches und Merges in Projekten jeder Größe zu verwalten.
sequenceDiagram
participant Arbeitsverzeichnis
participant Staging_Bereich
participant Lokales_Repository
participant Remote_Repository
Arbeitsverzeichnis ->> Staging_Bereich: git add (Vorbereiten)
Staging_Bereich ->> Lokales_Repository: git commit (Lokal speichern)
Lokales_Repository ->> Remote_Repository: git push (Auf Server schicken)
Remote_Repository ->> Arbeitsverzeichnis: git pull (Updates runterladen)
4. Drei Orte, an denen Code gespeichert wird
Wenn du ein Versionskontrollsystem für deinen Code benutzt, wird er grob gesagt an drei Orten gespeichert:
1. Remote-Repository
Das ist der zentralisierte Ort zur Aufbewahrung deines Codes, normalerweise gehostet auf Diensten wie GitHub, GitLab oder Bitbucket. Sie bieten zentrales Code-Hosting und sind die Grundlage für Zusammenarbeit. Das Remote-Repository dient als Integrationspunkt für Automatisierungsprozesse wie Build, Test und Deployment von Anwendungen.
2. Lokales Repository
Das lokale Repository ist deine persönliche Kopie des Codes auf deinem Computer. In diesem Repository kannst du alle Git-Operationen durchführen (Commits, Branching, Merging) ohne Internetverbindung.
3. Arbeitsverzeichnis
Das Arbeitsverzeichnis auf deinem Rechner enthält die aktuellen Projektdateien, an denen du gerade arbeitest. Hier kannst du Dateien sehen und ändern, neue Features hinzufügen oder Bugs fixen.
Diese Komponenten zusammen bieten eine leistungsfähige Infrastruktur zur Verwaltung von Quellcode und ermöglichen Entwicklern, die Projektgeschichte zu kontrollieren und zusammenzuarbeiten.
5. GitHub — dein Portfolio
GitHub — ist die führende Webplattform zum Hosten von Quellcode, die das Versionskontrollsystem Git verwendet. Gegründet 2008, wurde es schnell zu einem der wichtigsten Tools für Entwickler weltweit.
GitHub ermöglicht es Nutzern, Repositories zur Verwaltung von Projekten zu erstellen, Änderungen im Code zu kontrollieren und mit anderen Entwicklern zusammenzuarbeiten. Für einen modernen Entwickler ist ein Profil auf GitHub ein wichtiger Teil des Portfolios, das man potenziellen Arbeitgebern zeigen kann.
6. Erstellung deines ersten Repositories auf GitHub
Schritt 1. Gehe zu https://github.com und registriere dich.
Schritt 2. Klicke auf die Schaltfläche New repository, um ein neues Repository zu erstellen.
Schritt 3. Stelle die Parameter für das Repository ein:
- Name des Repositories: denk dir einen aussagekräftigen Namen aus.
- Öffentlich oder privat: für Lernprojekte ist es besser, "Public" zu wählen, damit andere es sehen können.
- Add a README file: setze dieses Häkchen unbedingt. README ist das "Gesicht" deines Projekts.
- Add .gitignore: öffne das Dropdown und wähle ein Template für deine Programmiersprache.
- Choose a license: kannst du überspringen.
- Klicke auf
Create repository.
Schritt 4. Glückwunsch, dein erstes Remote-Repository wurde erstellt!
7. Installation und Einrichtung von Git
Obwohl man die Grundlagen von Git über die Konsolenbefehle lernen kann (wie im Video gezeigt), nutzen in der täglichen Arbeit 99% der Entwickler die bequemen Tools, die in die IDE integriert sind. Unser Ziel ist es, dir beizubringen, so zu arbeiten, wie es Profis tun.
Die Git-Oberfläche in allen modernen JetBrains-IDEs — sei es IntelliJ IDEA für Java/Kotlin, Rider für C# oder PyCharm für Python — ist praktisch identisch. Das bedeutet, wenn du lernst, Git in einer Umgebung zu benutzen, kannst du die gleichen Skills in jeder anderen IDE anwenden. Deshalb verwenden wir IntelliJ IDEA als universelles Beispiel. Alles, was du hier siehst, wird genauso aussehen und funktionieren in deiner Lieblings-IDE.
Um Git auf deinem Rechner zu nutzen, muss Git zuerst installiert sein. Wenn du IntelliJ IDEA verwendest, wird dir die IDE wahrscheinlich vorschlagen, Git automatisch zu installieren, falls es nicht im System gefunden wird. Wir empfehlen, diesem Vorschlag zuzustimmen — das ist der einfachste Weg.
Schließe das aktuelle Projekt, indem du File > Close Project wählst, und klicke auf Clone Repository.
Wenn du es manuell installieren möchtest, besuche die offizielle Seite: https://git-scm.com/downloads.
8. Ein bisschen Geschichte: main vs master
Früher hieß der Standardbranch in Git master. Im Jahr 2020 stieg die Entwickler-Community und große Plattformen, einschließlich GitHub, auf den neutraleren Begriff main um.
Das ist wichtig zu wissen, denn in einigen älteren Artikeln oder Projekten kannst du noch Erwähnungen des Branches master finden. In unseren Vorlesungen und in modernen Projekten heißt der Hauptbranch immer main.
Mehr über den Wechsel zu main kannst du unter folgenden Links erfahren:
GO TO FULL VERSION