Was ist Git? Einführung in die Versionskontrolle

01Was ist ein Versionskontrollsystem?

Kommt es Ihnen bekannt vor, ein Dokument als “final”, “final-echt” und “final-wirklich-diesmal” zu kopieren und aufzuheben? Ein Versionskontrollsystem ist die geordnete und verlässliche Form dieses Durcheinanders. Es speichert jede Änderung samt Angabe, wer sie wann und warum vorgenommen hat.

In der Softwareentwicklung ist diese Aufzeichnung lebenswichtig. Wenn ein Feature, das gestern funktionierte, heute defekt ist, sehen Sie die Änderungen dazwischen Zeile für Zeile und können bei Bedarf zum alten Stand zurückkehren. Mit wachsendem Team ist die Arbeit ohne diese Ordnung kaum noch möglich.

Git entstand 2005 für die Entwicklung des Linux-Kernels und ist heute das weltweit am häufigsten genutzte Versionskontrollwerkzeug. Offizielle Dokumentation und Download-Links finden Sie auf git-scm.com.

02Wozu dient Git?

Der Wert von Git geht weit über das bloße Anlegen von Sicherungen hinaus. Richtig eingesetzt, ordnet es die Arbeitsweise eines Teams neu.

Schon für einen einzelnen Entwickler ist der Unterschied groß. Um eine neue Idee auszuprobieren, müssen Sie das Projekt nicht kopieren; Sie legen einen Branch an, probieren aus und löschen ihn, wenn er Ihnen nicht gefällt. Die Hauptversion bleibt stets sauber und lauffähig, die Kosten des Ausprobierens sinken auf nahezu null.

• Bewahrt die Historie: Jeder Speicherpunkt ist eine Momentaufnahme des Projekts.
• Erleichtert die Rückkehr: Eine fehlerhafte Änderung machen Sie mit einem Befehl rückgängig.
• Ermöglicht paralleles Arbeiten: Jeder arbeitet in seinem Branch und führt später zusammen.
• Macht Verantwortung sichtbar: Es ist klar, wer welche Zeile warum geändert hat.
• Ist verteilt aufgebaut: Auf dem Rechner jedes Entwicklers liegt eine vollständige Kopie des Projekts, man kann auch ohne Internet arbeiten.
• Lässt sich an den Release-Prozess anbinden: Test- und Live-Schritte können an bestimmte Branches gekoppelt und automatisiert werden.

03Grundbegriffe: Repository, Commit, Branch

Der kürzeste Weg, Git zu verstehen, ist, vier Begriffe zu verinnerlichen. Auf ihnen bauen die Befehle auf.

Repository

Ein Repository ist der Ordner, der die Dateien eines Projekts und die gesamte Änderungshistorie enthält. Ein versteckter .git-Ordner hält diese Historie. Das Repository auf Ihrem Computer nennt man lokales Repository, das auf einem Server wie GitHub oder GitLab Remote-Repository.

Was ist ein Commit?

Ein Commit ist die beschriebene Aufzeichnung der Änderungen zu einem bestimmten Zeitpunkt. Jeder Commit hat eine eindeutige ID. Ein guter Commit ist klein und hat einen einzigen Zweck; seine Nachricht beantwortet die Frage “Was hat sich geändert und warum?”.

Staging-Bereich

In Git werden Änderungen nicht direkt gespeichert, sondern zuerst dem Staging-Bereich hinzugefügt. So können Sie von zehn gleichzeitig geänderten Dateien nur die drei zugehörigen in einen einzigen Commit packen.

Branch und Merge

Ein Branch ist eine eigenständige Arbeitslinie, die vom Hauptcode abzweigt. Ein neues Feature entwickeln Sie in einem separaten Branch und führen es, sobald es fertig ist, per Merge in den Hauptbranch zusammen. So beschädigt unfertige Arbeit nicht die lauffähige Version.

04Die wichtigsten Git-Befehle

Nach der Installation von Git läuft der Großteil der täglichen Arbeit mit einer Handvoll Befehlen. Die Installationsschritte finden Sie in unserem Leitfaden Git installieren. Die folgenden Befehle funktionieren unter Windows, macOS und Linux auf die gleiche Weise.

git --version
git config --global user.name "Vorname Nachname"
git config --global user.email "eposta@ornek.com"
mkdir proje && cd proje
git init

git status
git add index.html
git add .
git commit -m "Überschrift der Startseite hinzugefügt"
git log --oneline

git switch -c iletisim-formu
# ... Änderungen vornehmen und committen ...
git switch main
git merge iletisim-formu
git branch -d iletisim-formu

git clone https://github.com/kullanici/proje.git
git pull
git push origin main

05Ein typischer Git-Workflow

Selbst in einem kleinen Team verhindert der folgende Ablauf weitgehend Chaos.

1. Aktuellen Code holen: Aktualisieren Sie vor Arbeitsbeginn den Hauptbranch mit git pull.
2. Neuen Branch anlegen: Erstellen Sie für jedes Feature oder jeden Fix einen eigenen Branch.
3. Kleine Commits machen: Speichern Sie jeden sinnvollen Schritt mit einer aussagekräftigen Nachricht.
4. Branch zum Remote-Repository senden: Teilen Sie Ihre Arbeit mit git push.
5. Review anfordern: Öffnen Sie auf GitHub einen Pull Request, auf GitLab einen Merge Request.
6. Nach der Freigabe zusammenführen: In den Hauptbranch gelangt nur geprüfter Code.

06Der Unterschied zwischen Git und GitHub

Das ist das am häufigsten verwechselte Thema. Git ist ein Werkzeug; es läuft auf Ihrem Computer und führt die Historie. Dienste wie GitHub, GitLab, Bitbucket sind dagegen Plattformen, die Git-Repositories im Internet hosten und Review, Aufgabenverwaltung und Automatisierung hinzufügen.

Sie können Git allein und ohne Anbindung an eine Plattform nutzen. Für Teamarbeit und Sicherung ist ein Remote-Repository jedoch in der Praxis zum Standard geworden.

07.gitignore und gute Commit-Nachrichten

Jedes Repository sollte eine .gitignore-Datei enthalten, die festlegt, was nicht verfolgt wird. Abhängigkeitsordner, Build-Ausgaben, Logdateien und Umgebungsvariablen gehören auf diese Liste. So bleibt das Repository klein, reproduzierbare Dateien blähen die Historie nicht auf, und geheime Informationen werden nicht versehentlich geteilt.

Eine Commit-Nachricht ist dagegen eine Notiz, die Sie in sechs Monaten lesen werden. Üblich ist, in der ersten Zeile eine kurze Zusammenfassung von etwa 50 Zeichen im Imperativ zu schreiben, zum Beispiel “Rundungsfehler bei der Warenkorbsumme beheben”. Erklären Sie bei Bedarf nach einer Leerzeile den Grund und die Wirkung.

Gute Nachrichten dienen nicht nur der Ordnung. Wenn Sie herausfinden möchten, mit welcher Änderung ein Fehler hereingekommen ist, weisen Ihnen die Befehle git log und git blame direkt den Weg; aussagekräftige Nachrichten verkürzen diese Suche auf Minuten. Ein im Team vereinbartes gemeinsames Nachrichtenformat beschleunigt auch das Code-Review.

node_modules/
dist/
.env
*.log
.DS_Store

08Häufige Anfängerfehler

Die meisten dieser Fehler verschwinden nach einigen Wochen Praxis von selbst. Wichtig ist, sich vom ersten Tag an an kleine, beschriebene Commits zu gewöhnen.

• Geheime Informationen committen: Passwörter und API-Schlüssel gehören nicht ins Repository; tragen Sie Dateien wie .env in die .gitignore ein.
• Riesige Commits: Eine Woche Arbeit in einen einzigen Commit zu packen, erschwert die Rückkehr zu einem früheren Stand.
• Sinnlose Nachrichten: Schreiben Sie statt “Fix” oder “asdf”, was sich geändert hat.
• Direkt im Hauptbranch arbeiten: Unfertige Arbeit kann die Live-Version beschädigen.
• Angst vor Konflikten: Ein Merge-Konflikt ist normal; Git zeigt deutlich, welche Zeilen kollidieren.
• Ordner wie node_modules hinzufügen: Legen Sie keine Dateien ins Repository, die sich neu erzeugen lassen.

09Wo sollten Sie mit Git anfangen?

Am wirksamsten ist es, ein kleines Projekt von Anfang bis Ende mit Git zu verwalten. Eine einfache HTML-Seite oder ein kleines Skript, wie wir es im Beitrag Was ist JavaScript beschreiben, genügt, um die Begriffe zu festigen.

Im nächsten Schritt können Sie ein Node.js-Projekt aufsetzen und Paketdateien, die .gitignore und Branches zusammen ausprobieren. Bei der Frage, ob Oberflächen- und Servercode im selben oder in getrennten Repositories liegen sollen, hilft unser Beitrag Frontend und Backend: der Unterschied weiter.

In professionellen Projekten ist Git das unsichtbare, aber unverzichtbare Rückgrat der Arbeit. Bei Aurora Yazılım werden sämtliche Projekte aus den Bereichen Webdesign, Unternehmenswebsite und Shopsystem mit Versionskontrolle umgesetzt; so bleibt jede Änderung nachvollziehbar und umkehrbar.