Was ist Git? Einfach erklärt, mit echten Messungen (2026)

Fast jeder, der anfängt zu programmieren, hat irgendwann einen Ordner, der so aussieht: website_final, website_final_2, website_final_WIRKLICH, website_alt_nicht_loeschen. Wir hatten den auch. Git ist die Antwort auf genau dieses Chaos.

Was ist Git? Git ist ein kostenloses Versionskontrollsystem, das jede Änderung an deinen Dateien als nachvollziehbaren Schnappschuss speichert. Du kannst jederzeit sehen, wer wann was geändert hat, zu jedem früheren Stand zurückspringen und gefahrlos an mehreren Ideen parallel arbeiten. Git läuft lokal auf deinem Rechner, braucht keinen Server und kein Konto, und es ist heute das Werkzeug, mit dem praktisch die gesamte Softwarebranche arbeitet.

In diesem Artikel erklären wir Git so, dass es auch ohne Vorwissen verständlich ist: was intern passiert, wenn du „speicherst“, was Commits und Branches wirklich sind, worin sich Git von GitHub unterscheidet und welche Fehler wir selbst schon gemacht haben. Alle Zahlen stammen aus eigenen Messungen vom 17. Oktober 2026 auf unserem Server mit Git 2.43.

Der Komplettkurs von Fabian Rappert (Data Science Institute, Mai 2026) ist der aktuellste deutschsprachige Einstieg, den wir gefunden haben. Er geht in der Praxis weiter als dieser Artikel. Wir konzentrieren uns hier auf das Verständnis: Wer weiß, was Git im Hintergrund tut, macht viel weniger Fehler.

Was ist Git — die kurze Antwort

Wenn du nur fünf Sätze lesen willst, dann diese:

1. Git ist ein Versionskontrollsystem. Es merkt sich die Geschichte eines Projekts, Datei für Datei, Änderung für Änderung.
2. Ein Commit ist ein Schnappschuss. Du sagst Git ausdrücklich: „Dieser Stand ist wichtig, merk ihn dir“, und schreibst eine kurze Nachricht dazu.
3. Ein Branch ist eine Abzweigung. Du kannst neben dem funktionierenden Stand an einer neuen Idee basteln, ohne ihn zu gefährden, und die Idee später zusammenführen (mergen) oder wegwerfen.
4. Git ist dezentral. Jede Kopie eines Projekts enthält die komplette Geschichte. Du arbeitest offline, und es gibt keinen Server, ohne den nichts geht.
5. Git ist nicht GitHub. Git ist das Programm auf deinem Rechner. GitHub, GitLab oder Codeberg sind Websites, auf denen man Git-Projekte ablegt und gemeinsam bearbeitet.

Der Rest dieses Artikels erklärt, warum das so ist und was daraus im Alltag folgt.

Wofür braucht man Git überhaupt?

Die ehrliche Antwort: Solange du allein an einer einzigen Datei arbeitest, brauchst du Git nicht. Sobald eines der folgenden Dinge zutrifft, wird es sehr schnell unverzichtbar:

• Du willst Änderungen rückgängig machen können, auch nach Tagen. Strg+Z endet, sobald du den Editor schließt. Git endet nie.
• Du willst wissen, warum etwas so ist. Zu jeder Zeile Code kann Git dir sagen, wann sie dazukam, von wem und mit welcher Begründung (git blame und git log).
• Du arbeitest mit anderen zusammen. Zwei Leute ändern dieselbe Datei? Git führt beide Änderungen zusammen und meldet sich nur, wenn beide dieselbe Zeile angefasst haben.
• Du willst etwas ausprobieren, ohne Angst. Ein Branch kostet nichts. Geht der Versuch schief, wirfst du ihn weg.
• Du willst deployen. Viele Hosting-Dienste (Vercel, Netlify, Cloudflare Pages, aber auch der eigene Server) holen sich den Code direkt aus einem Git-Repository. Wer das selbst bauen will, findet Hintergründe in unserem Artikel über eine Vercel-Alternative.

Git ist dabei nicht auf Code beschränkt. Alles, was aus Textdateien besteht, profitiert: Konfigurationsdateien, Dokumentation in Markdown, Übersetzungen, sogar Romane. Dieser Blog hier besteht aus MDX-Dateien. Bei großen Binärdateien wie Videos oder Photoshop-Dateien stößt Git dagegen an Grenzen, dazu später mehr.

Eine sehr kurze Geschichte von Git

Git ist kein Produkt einer Firma, sondern entstand aus einem Notfall. Bis 2005 nutzte die Entwicklung des Linux-Kernels ein kommerzielles Werkzeug namens BitKeeper, dessen Hersteller die kostenlose Nutzung für die Kernel-Entwickler im April 2005 beendete. Linus Torvalds, der Erfinder von Linux, schrieb daraufhin innerhalb weniger Tage ein eigenes System. Die Ziele waren klar: schnell, dezentral, und es sollte unmöglich sein, die Geschichte unbemerkt zu verfälschen.

Im Juli 2005 übergab Torvalds die Pflege an Junio Hamano, der Git bis heute betreut. Git steht unter der GPLv2, ist also freie Software und kostet nichts. Der Name ist britischer Slang für einen unangenehmen Menschen; Torvalds hat gewitzelt, er benenne alle seine Projekte nach sich selbst.

Ab 2008 machte GitHub Git für eine breite Masse zugänglich, 2018 kaufte Microsoft GitHub. Spätestens seit den 2010er-Jahren ist Git der Standard: In der Stack-Overflow-Entwicklerumfrage 2022 gaben über 90 Prozent der Befragten an, Git zu nutzen. Ältere Systeme wie Subversion (SVN) oder CVS findet man heute fast nur noch in Altprojekten.

Wie lange so eine Geschichte hält, zeigt unsere erste Messung. Wir haben das Repository des Web-Frameworks Express geklont:

git clone https://github.com/expressjs/express
cd express
git rev-list --count HEAD        # 6181
git log --reverse --format="%ad %an" --date=short | head -1
# 2009-06-26 visionmedia
git shortlog -sn HEAD | wc -l    # 398

6.181 Commits von 398 verschiedenen Autorinnen und Autoren, der erste vom 26. Juni 2009. Jeder einzelne davon ist in der Kopie auf unserem Server enthalten, und das gesamte Paket ist nur 12 MB groß. Siebzehn Jahre Entwicklungsgeschichte, kleiner als ein durchschnittliches Handyvideo.

Wie Git funktioniert: die drei Bereiche

Das Konzept, das Einsteiger am meisten verwirrt, ist gleichzeitig das wichtigste: Git kennt drei Orte, an denen eine Änderung sein kann.

1. Arbeitsverzeichnis (Working Directory): dein ganz normaler Projektordner. Hier bearbeitest du Dateien mit deinem Editor. Git schaut zu, speichert aber noch nichts.
2. Staging Area (auch Index): eine Art Packtisch. Mit git add legst du gezielt die Änderungen darauf, die in den nächsten Schnappschuss sollen.
3. Repository: das Archiv im versteckten Ordner .git. Mit git commit wird alles, was auf dem Packtisch liegt, zu einem dauerhaften Schnappschuss.

Warum der Zwischenschritt? Weil du selten genau eine Sache gleichzeitig änderst. Vielleicht hast du einen Fehler behoben und nebenbei einen Tippfehler in der README korrigiert. Mit der Staging Area kannst du daraus zwei saubere Commits machen, statt einen „hab mal einiges geändert“-Commit. Das wirkt am Anfang umständlich und ist später Gold wert, wenn du in der Geschichte nach der Ursache eines Fehlers suchst.

Der typische Ablauf sieht so aus:

git status                  # was hat sich geändert?
git add index.html          # diese Datei auf den Packtisch
git commit -m "Navigation auf Mobilgeräten repariert"
git log --oneline           # Geschichte ansehen

git status ist übrigens der Befehl, den wir am häufigsten tippen. Er kostet nichts: In unserem Express-Klon brauchte er 8 Millisekunden.

Was ist ein Commit wirklich? Ein Blick in den .git-Ordner

Hier wird es spannend, und hier versteht man, warum Git so robust ist. Wir haben ein leeres Testprojekt angelegt, eine Datei mit dem Inhalt „Hallo Welt“ geschrieben und committet. Danach haben wir Git gebeten, uns den Commit roh zu zeigen:

git cat-file -p HEAD
# tree 635ac6d4113233f71fd5507d6e287c26bd841ef0
# author Test <t@t> 1792220497 +0000
# committer Test <t@t> 1792220497 +0000
#
# init

git cat-file -p HEAD^{tree}
# 100644 blob 636af6605bfd946e3d245d5086cf565336ad6383   a.txt

Ein Commit ist also eine winzige Textnotiz: Sie verweist auf einen Tree (ein Verzeichnis), enthält Autor, Zeitpunkt und Nachricht und bei allen späteren Commits zusätzlich einen Verweis auf den Vorgänger (parent). Der Tree verweist auf Blobs, das sind die eigentlichen Dateiinhalte.

Jedes dieser Objekte hat als Namen eine Prüfsumme seines Inhalts. Das lässt sich direkt nachprüfen:

git hash-object a.txt
# 636af6605bfd946e3d245d5086cf565336ad6383

Dieselbe Zeichenkette wie oben. Daraus folgen drei Eigenschaften, die man kennen sollte:

• Gleicher Inhalt, gleiches Objekt. Git speichert identische Dateien nur einmal. Wir haben die Datei danach 1.000-mal kopiert und alle Kopien committet. Die Zahl der Objekte stieg von 3 auf genau 5: ein neuer Tree, ein neuer Commit, aber kein einziger neuer Blob. Der .git-Ordner wuchs von 172 auf 256 KB, und das lag fast nur an der längeren Dateiliste.
• Die Geschichte ist fälschungssicher. Weil jeder Commit die Prüfsumme seines Vorgängers enthält, würde jede nachträgliche Änderung alle folgenden Prüfsummen ändern. Unbemerkt manipulieren geht nicht.
• Git speichert Schnappschüsse, keine Differenzen. Gedanklich ist jeder Commit ein vollständiges Abbild des Projekts. Platz spart Git trotzdem, durch die Wiederverwendung unveränderter Blobs und durch Komprimierung in sogenannten Packfiles.

Git verwendet für diese Prüfsummen traditionell SHA-1. Seit Version 2.29 (2020) gibt es optional SHA-256, und der Umstieg ist als langfristiger Standard geplant. Für deine tägliche Arbeit spielt das keine Rolle.

Was ist ein Branch? Ein Zettel mit 41 Byte

Branches haben in älteren Systemen wie SVN eine ganze Kopie des Projekts erzeugt. In Git ist ein Branch etwas fast Lächerliches: eine Datei mit einer einzigen Commit-ID.

cat .git/refs/heads/b1
# 27263e8e7e16b0aea861b2d35bb9fd962ea0933d
wc -c .git/refs/heads/b1
# 41 .git/refs/heads/b1

41 Byte: 40 Zeichen Prüfsumme plus Zeilenumbruch. Mehr ist ein Branch nicht. Wir haben in einer Schleife 100 Branches angelegt, das dauerte 0,22 Sekunden insgesamt. Deshalb ist es in Git völlig normal, für jede Kleinigkeit einen eigenen Branch zu machen.

Der übliche Ablauf:

git switch -c neue-startseite   # Branch anlegen und wechseln
# ... arbeiten, committen ...
git switch main                 # zurück zum Hauptstand
git merge neue-startseite       # Arbeit zusammenführen
git branch -d neue-startseite   # Zettel wegwerfen

main (früher meist master) ist dabei nur eine Konvention, kein besonderer Branch. Neue Repositories bekommen den Namen, den du in init.defaultBranch einstellst.

Was passiert bei einem Merge-Konflikt?

Konflikte klingen bedrohlich und sind es selten. Sie entstehen nur, wenn zwei Branches dieselbe Zeile unterschiedlich geändert haben. Wir haben das nachgestellt: Auf main stand „Preis: 9 Euro“, auf einem Feature-Branch „Preis: 12 Euro“. Beim Merge sagte Git:

Auto-merging p.txt
CONFLICT (content): Merge conflict in p.txt
Automatic merge failed; fix conflicts and then commit the result.

Und in der Datei standen beide Varianten nebeneinander:

<<<<<<< HEAD
Preis: 9 Euro
=======
Preis: 12 Euro
>>>>>>> feature

Git rät nicht. Es hält an und überlässt dir die Entscheidung. Du löschst die Markierungen, behältst die richtige Variante, und schließt mit git add und git commit ab. Wer kalte Füße bekommt, bricht mit git merge --abort ab, und alles ist wie vorher. Das haben wir getestet: kein Datenverlust, kein Rest.

Git ist dezentral — und warum das wichtig ist

Bei alten Systemen gab es einen zentralen Server, auf dem die Geschichte lag. Fiel er aus, konnte niemand committen. Bei Git hat jede Kopie die komplette Geschichte. Dein Laptop, der Laptop deiner Kollegin, der Server, GitHub: Alle sind gleichwertig. Ein „Remote“ ist einfach eine andere Kopie, mit der du Commits austauschst.

Die Befehle dafür:

git clone <url>   # vollständige Kopie holen
git pull          # neue Commits vom Remote holen und einbauen
git push          # eigene Commits zum Remote schicken

Der Austausch läuft meist über HTTPS oder SSH. Für GitHub und den eigenen Server empfehlen wir SSH mit Schlüssel statt Passwort; wie das geht, steht in unserer Anleitung SSH-Key erstellen.

Weil alles lokal liegt, ist Git sehr schnell. git log über alle 6.181 Express-Commits dauerte bei uns 44 Millisekunden. Und wer die Geschichte gar nicht braucht, kann flach klonen:

Der flache Klon ist rund 30-mal kleiner. Für CI-Pipelines oder ein schnelles Deployment ist das ideal, für die tägliche Arbeit willst du dagegen die volle Geschichte.

Git vs. GitHub: der Unterschied

Das ist die häufigste Verwechslung überhaupt, deshalb ganz klar:

Du kannst Git ein Leben lang ohne GitHub benutzen. Umgekehrt geht es nicht: GitHub ist im Kern ein Hosting-Dienst für Git-Repositories mit sehr viel Zusammenarbeitswerkzeugen obendrauf. Das wichtigste davon ist der Pull Request (bei GitLab „Merge Request“): Jemand schlägt vor, einen Branch zu mergen, andere lesen den Code, kommentieren und geben frei.

Wer seine Projekte lieber nicht bei einem US-Konzern ablegt, hat gute Alternativen. Codeberg ist ein gemeinnütziger Verein aus Berlin, der auf der Software Forgejo läuft. Forgejo und Gitea kann man auch selbst hosten, zum Beispiel per Docker auf dem eigenen Server. Und für ganz kleine Fälle reicht ein nacktes Repository auf einem Server, auf den du per SSH zugreifst. Mehr braucht Git nicht.

Ein zweiter deutscher Einstieg (September 2025), der den Weg von Git zu GitHub Schritt für Schritt vorführt.

Git installieren und die ersten fünf Minuten

Git ist auf macOS (über die Xcode-Kommandozeilentools) und auf den meisten Linux-Systemen schon da oder mit einem Befehl installiert:

# Debian / Ubuntu
sudo apt install git
# Fedora
sudo dnf install git
# macOS
xcode-select --install
# Windows: Installer von git-scm.com, oder
winget install --id Git.Git

Danach einmalig sagen, wer du bist. Diese Angaben landen in jedem Commit:

git config --global user.name "Dein Name"
git config --global user.email "du@example.com"
git config --global init.defaultBranch main

Und dann dein erstes Repository:

mkdir mein-projekt && cd mein-projekt
git init
echo "# Mein Projekt" > README.md
git add README.md
git commit -m "Erster Commit"
git log

Das war es. Du hast jetzt ein vollwertiges Repository, ohne Konto, ohne Server, ohne Internet. Ob du die Befehle in der Kommandozeile tippst oder eine grafische Oberfläche nimmst (VS Code hat Git eingebaut, dazu gibt es GitHub Desktop, GitKraken, Sourcetree oder lazygit im Terminal), ist Geschmackssache. Wir empfehlen, die Grundbefehle einmal im Terminal zu lernen, weil dann jede Oberfläche verständlich wird.

Die .gitignore-Datei

Nicht alles gehört ins Repository. Abhängigkeiten (node_modules), Build-Ergebnisse (dist), Logdateien und vor allem Zugangsdaten (.env) schließt du mit einer Datei namens .gitignore aus:

node_modules/
dist/
*.log
.env

Das ist keine Kür. Warum, zeigt der nächste Abschnitt.

Fehler, die wir selbst gemacht haben

Git ist nachsichtig, aber nicht allwissend. Diese drei Dinge haben wir in der Praxis gelernt, teils schmerzhaft.

1. „Gelöscht“ heißt in Git nicht gelöscht

Wir haben im Test absichtlich eine .env-Datei mit einem Schlüssel committet und im nächsten Commit wieder entfernt. Im Projektordner war sie weg. In der Geschichte nicht:

git log --all -p -S geheim123 --format="%h %s"
# 9ebcff1 env weg
# -API_KEY=geheim123
# de822ef env
# +API_KEY=geheim123

Jeder, der das Repository klont, kann den Schlüssel mit genau diesem einen Befehl finden. Automatisierte Scanner durchsuchen öffentliche Repositories rund um die Uhr nach solchen Funden. Ein einmal gepushtes Passwort gilt als verbrannt. Der einzige sichere Weg: Schlüssel sofort beim Anbieter widerrufen und neu erzeugen. Die Geschichte nachträglich zu säubern (mit git filter-repo) ist zusätzlich möglich, ersetzt den Widerruf aber nicht, weil Kopien längst irgendwo liegen können.

2. Git ist kein Backup

Weil jede Kopie die ganze Geschichte enthält, liegt der Gedanke nahe, Git sei schon ein Backup. Das stimmt nur halb. Git sichert, was du committest, nicht was in .gitignore steht, keine Datenbanken, keine hochgeladenen Bilder, keine Serverkonfiguration außerhalb des Repositories. Und ein git push --force kann auf dem Remote Geschichte überschreiben. Für echte Sicherung brauchst du eine eigene Strategie, etwa nach der 3-2-1-Backup-Regel. Git ist ein Baustein davon, nicht der Ersatz.

3. Fast nichts ist wirklich verloren: das Reflog

Die gute Nachricht zum Schluss: Lokal ist es in Git sehr schwer, committete Arbeit zu verlieren. Wir haben in unserem Test mit git reset --hard HEAD~1 den letzten Commit „weggeworfen“. Die Datei zeigte wieder den alten Preis. Aber Git führt ein Tagebuch über jede Bewegung:

git reflog
# b2e6791 HEAD@{0}: reset: moving to HEAD~1
# bd4565e HEAD@{1}: reset: moving to HEAD
# bd4565e HEAD@{2}: commit: c
git reset --hard HEAD@{1}

Danach war der „verlorene“ Commit wieder da. Das Reflog bewahrt solche Einträge standardmäßig mindestens 30 Tage auf. Was nie committet wurde, kann Git allerdings auch nicht retten. Deshalb lieber zu oft committen als zu selten.

Wo Git an Grenzen stößt

Git ist großartig für Text und mittelmäßig für alles andere.

• Große Binärdateien. Videos, 3D-Modelle oder große Bilder lassen sich nicht sinnvoll zeilenweise vergleichen. Jede neue Version wird komplett gespeichert, und das Repository bläht sich auf. Für Spiele, Design und Medien gibt es Git LFS (Large File Storage), das große Dateien auslagert, oder spezialisierte Systeme wie Perforce.
• Die Lernkurve. Die Grundbefehle lernt man in einem Nachmittag. Rebase, Cherry-Pick, Submodule und das Aufräumen verkorkster Geschichte dauern länger. Die Befehlsnamen sind historisch gewachsen und nicht immer logisch; git checkout macht zum Beispiel ganz verschiedene Dinge, weshalb es inzwischen die klareren git switch und git restore gibt.
• Riesige Monorepos. Bei Projekten mit Millionen Dateien wird auch Git langsam. Firmen wie Microsoft haben dafür Erweiterungen entwickelt (Scalar ist inzwischen Teil von Git). Für normale Projekte spielt das keine Rolle; unsere eigenen Repositories mit ein paar Hundert Dateien haben .git-Ordner im einstelligen Megabyte-Bereich.

Git vs. andere Versionskontrollsysteme

Wenn du neu anfängst, gibt es eigentlich keine Entscheidung zu treffen: Lern Git. Fast jede Stellenanzeige, jedes Tutorial, jedes Tool und jede Hosting-Plattform setzt es voraus.

Ein Workflow, der für die meisten reicht

Es gibt dicke Bücher über Git-Workflows. Für Einzelpersonen und kleine Teams reicht dieser:

1. main ist immer lauffähig. Was dort liegt, kann live gehen.
2. Jede Aufgabe bekommt einen eigenen Branch, z. B. fix/login-button oder feature/newsletter.
3. Kleine Commits mit klaren Nachrichten. Faustregel: Die Nachricht beschreibt, was der Commit tut, im Imperativ: „Login-Button auf Mobilgeräten vergrößern“, nicht „Änderungen“.
4. Vor dem Mergen anschauen lassen (Pull Request), wenn ihr mehrere seid. Wenn du allein bist: wenigstens selbst git diff main lesen.
5. Mergen, Branch löschen, deployen.

So arbeiten wir auch. Dieser Blog, unser Analytics-Projekt und die meisten unserer Server-Dienste liegen in Git-Repositories, und das Deployment ist in vielen Fällen nichts anderes als ein git pull auf dem Server, gefolgt von einem Neustart. Wie man einen eigenen Server dafür vorbereitet, beschreiben wir in Linux-Server einrichten.

Fazit: Was ist Git — und lohnt es sich zu lernen?

Git ist das Gedächtnis eines Projekts. Es speichert jeden bewussten Zwischenstand als unveränderlichen Schnappschuss, lässt dich gefahrlos ausprobieren und macht Zusammenarbeit überhaupt erst praktikabel. Unsere Messungen zeigen, wie leichtgewichtig das ist: 17 Jahre Geschichte von fast 400 Menschen in 12 MB, ein Branch in 41 Byte, git status in 8 Millisekunden.

Wer programmiert, Webseiten baut oder Server betreut, kommt an Git nicht vorbei, und das ist gut so. Die Grundlagen (init, add, commit, log, switch, merge, push, pull) sind an einem Nachmittag gelernt. Merk dir dazu drei Sätze: Git ist nicht GitHub. Git ist kein Backup. Und was einmal committet wurde, bleibt in der Geschichte. Damit bist du vor den häufigsten Fehlern geschützt.

Häufige Fragen zu Git

Was ist Git einfach erklärt?

Git ist ein Programm, das sich jede gespeicherte Version deiner Projektdateien merkt. Du kannst jederzeit sehen, was sich wann geändert hat, zu einem alten Stand zurückkehren und parallel an verschiedenen Ideen arbeiten. Man kann es sich wie eine sehr gründliche „Rückgängig“-Funktion vorstellen, die nie vergisst und auch im Team funktioniert.

Was ist der Unterschied zwischen Git und GitHub?

Git ist die Software auf deinem Rechner, die Versionen verwaltet. GitHub ist eine Website, auf der man Git-Repositories ablegt, teilt und gemeinsam bearbeitet, mit Extras wie Pull Requests und Issues. Git funktioniert komplett ohne GitHub; GitHub funktioniert nicht ohne Git. Alternativen zu GitHub sind GitLab, Codeberg oder ein selbst gehostetes Forgejo.

Ist Git kostenlos?

Ja. Git ist freie Software unter der GPLv2 und kostet nichts, auch nicht für kommerzielle Nutzung. Kosten können nur bei Hosting-Plattformen entstehen, etwa für private Team-Funktionen bei GitHub oder GitLab. Ein eigenes Repository auf deinem Rechner oder Server ist immer gratis.

Wer hat Git erfunden?

Linus Torvalds, der Erfinder von Linux, hat Git im April 2005 geschrieben, nachdem die Kernel-Entwickler das bisher genutzte Werkzeug BitKeeper nicht mehr kostenlos verwenden durften. Seit Juli 2005 wird Git von Junio Hamano gepflegt und von einer großen Open-Source-Community weiterentwickelt.

Was ist ein Repository?

Ein Repository (kurz „Repo“) ist ein Projektordner, den Git verwaltet. Technisch ist das dein normaler Ordner plus ein versteckter Unterordner .git, in dem die gesamte Geschichte liegt: alle Commits, Branches und Dateiversionen. Löschst du .git, bleibt nur der aktuelle Stand der Dateien übrig.

Was ist ein Commit?

Ein Commit ist ein gespeicherter Schnappschuss deines Projekts mit Autor, Zeitpunkt und einer kurzen Beschreibung. Jeder Commit verweist auf seinen Vorgänger, so entsteht eine lückenlose Kette. Erkennbar ist er an einer eindeutigen Prüfsumme wie bd4565e, mit der du jederzeit zu genau diesem Stand zurückkehren kannst.

Was ist ein Branch in Git?

Ein Branch ist eine Abzweigung in der Geschichte, auf der du arbeiten kannst, ohne den Hauptstand zu verändern. Technisch ist er nur ein Verweis auf einen Commit, in unserer Messung eine Datei von 41 Byte. Deshalb sind Branches in Git billig und schnell, und man legt für jede Aufgabe einen eigenen an.

Braucht man Git, wenn man allein programmiert?

Ja, wir würden es immer empfehlen. Auch allein willst du alte Stände wiederherstellen, Experimente gefahrlos ausprobieren und nachvollziehen, warum du etwas vor drei Monaten so gebaut hast. Dazu kommt das Deployment: Viele Hosting-Dienste setzen ein Git-Repository voraus. Der Aufwand ist minimal, ein git init reicht für den Anfang.

Ist Git ein Backup?

Nur teilweise. Git sichert die Dateien, die du committest, und jede geklonte Kopie enthält die gesamte Geschichte. Es sichert aber keine Datenbanken, keine ignorierten Dateien und keine Server-Konfiguration, und ein Force-Push kann Geschichte auf dem Remote überschreiben. Git ist ein Baustein einer Backup-Strategie, ersetzt sie aber nicht.

Wie lange dauert es, Git zu lernen?

Die Grundbefehle für den Alltag (init, add, commit, status, log, switch, merge, push, pull) lernt man an einem Nachmittag. Sicher im Umgang mit Konflikten, Rebase und dem Reparieren von Fehlern wird man über einige Wochen echter Projektarbeit. Wichtiger als jeder Kurs ist, Git ab sofort in jedem eigenen Projekt zu nutzen.

Kann ich mit Git auch Word- oder Bilddateien verwalten?

Technisch ja, sinnvoll ist es aber vor allem für Textdateien. Bei Binärdateien wie Word-Dokumenten, Bildern oder Videos kann Git keine Unterschiede anzeigen und speichert jede Version vollständig, wodurch das Repository schnell wächst. Für große Mediendateien gibt es die Erweiterung Git LFS.