Git war noch nie dazu gedacht, dass du es einfach findest.

Du denkst, Git ist nur add, commit, push? Das bedeutet, du hast die ganze Zeit im “Einzelspielermodus” gespielt, hochstens LAN-Koop. Das ist nicht Git benutzen — das ist Git als manuell zu synchronisierende Baidu-Cloud-Festplatte verwenden.

Gits Komplexitat kommt von dem ultimativen Problem, das es lost: Wie kann eine Gruppe von Programmierern, die einander nicht vertrauen, gegensatzliche Arbeitszeiten haben und jederzeit abhauen konnten, am selben Projekt zusammenarbeiten, ohne dass alles im Chaos versinkt?

Sieh mal, clone und push kann jeder. Aber sobald du im Team arbeitest — du machst pull und alles ist voller Konflikte, der Bildschirm ubersat mit <<<<< HEAD und >>>>>> irgendein-zufalliger-hash — da beginnt der Albtraum.

Ich habe es selbst erlebt. Ein neuer Backend-Entwickler in unserem Team war talentiert, kam aber nicht mit Git klar. Einmal musste er einen dringenden Hotfix mergen, stundenlang kam er nicht weiter und kam zu mir. Ich sah mir seinen Branch-Graphen an — du meine Gute, das war ein Gewirr, wurdig der Tentakel von Cthulhu: Abzweigungen, Merges, weitere Abzweigungen, weitere Merges, dazwischen mehrere sinnlose merge branch 'master' into master Commits. Ich fragte ihn, was er getan hatte. Er sagte: “Ich konnte nicht pullen, also hab ich gefetched, dann rebased, rebase hat nicht geklappt, also hab ich gemerged, der Merge hatte immer noch Konflikte, also hab ich resettet…”

Mein Blutdruck schoss in die Hohe. Er behandelte Git wie einen Wunschbrunnen — welcher Befehl auch immer gut klang, warf er rein und hoffte, dass rohe Gewalt ein Wunder bewirken wurde. Spoiler: Es gab kein Wunder, aber wir hatten fast einen Grosunfall.

Und das ist nur die Spitze des Eisbergs. Tiefer drin stoat man auf die “verbotenen Techniken” der atomaren Geschichtsmanipulation: rebase -i, cherry-pick, filter-branch. Wozu sind die da? Einfach gesagt, sie sind die “Zeitmaschine” der Codewelt — sie lassen dich in die Vergangenheit reisen und die Geschichte andern. Aber wie wir aus den Filmen wissen, zerstoren neun von zehn Zeitreisenden das Universum. git reflog ist deine Pill für die Reue, aber meistens weit du nicht einmal, wann du dich “vergiftet” hast.

Gits Design-Philosophie ist, keiner zentralen Autoritat zu vertrauen. Sie betrachtet den Computer jedes Entwicklers als vollstandiges “Paralleluniversum” (repository). Jeder Commit, den du machst, erschafft eine neue historische Momentaufnahme in diesem Universum. Branches lassen dich nach Belieben unzahlige Paralleluniversen erschaffen. Merge und rebase sind Versuche, zwei verschiedene “Zeitlinien” zu vereinen — uberleg mal, wie kompliziert das ist. Nicht einmal Physiker haben das verstanden!

Die Staging-Area existiert, damit du prazise kontrollieren kannst, was committed wird. Branches isolieren deine Arbeit, damit du andere nicht stost. Merge handhabt das unvermeidliche Produkt der Zusammenarbeit: Abweichungen. Alles dient einem grossen “verteilten” Ziel. Git gibt dir unendliche Freiheit — und unendliche Moglichkeiten, Dinge zu ruinieren.

Also die Frage: Ist Git hoffnungslos? Konnen normale Leute es nie lernen?

Nicht wirklich. Das Problem ist nicht Git — es ist die Art, wie wir es lernen. Die meisten Tutorials sind entweder worterbuchartige Befehlslisten oder fragmentierte Szenario-Erklarungen. Die offizielle Dokumentation ist wie ein tausendseitiges Xinhua-Worterbuch — super zum Nachschlagen eines Wortes, aber man lernt nicht, Romane zu schreiben, indem man ein Worterbuch liest. Online-Guides sind uberall verstreut, wie ein Haufen loser Lego-Steine ohne Bauanleitung, die dir zeigt, wie man den Millennium Falcon baut.

Deshalb empfehle ich dringend Tutorials, die nicht alles abdecken wollen, sondern sich auf hautige, praxisnahe Szenarien konzentrieren. Ich finde das “Git-Praxis-Handbuch fur Einsteiger” vom Bytedance-Team ziemlich gut.

Es zeigt dir den Unterschied zwischen git pull und git pull --rebase und wann du welches verwenden solltest, anstatt dich stupide auswendig lernen zu lassen. Es fuhrt dich Schritt fur Schritt durch einen echten Konfliktfall und zeigt dir, wie du ihn elegant lost, anstatt einfach den Code anderer zu loschen. Es erklart, wenn dein Feature-Branch weit hinter dem Hauptzweig zuruckliegt, ob du merge oder rebase zur Synchronisierung verwenden solltest und welche Vor- und Nachteile beide Optionen haben.

Am Ende des Tages ist Gits Philosophie: “Gib dir unendliche Freiheit, und gib dir auch den Strick, um dich zu erhangen.” Ein guter Leitfaden lehrt dich, wie du diesen Strick benutzt, um ein Netz zu weben oder einen Felsen zu erklimmen — nicht, wie du dir versehentlich eine Schlinge um den Hals legst. Unser Ziel ist nicht, ein Git-Archaologe zu werden, der alle Befehle auswendig kann. Es ist, ein Git-Handwerker zu werden, der sich reibungslos im Team bewegt, seine Teamkollegen nie im Stich lasst und den Tag retten kann, wenn es darauf ankommt.