Beejs Git-Leitfaden

 (beej.us)
1 Punkte von GN⁺ 2025-02-06 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Leitfaden-Seite, die für Leser, die Git lernen oder nachschlagen möchten, HTML- und PDF-Ausgaben in mehreren Formaten bereitstellt
  • Der Leitfaden selbst geht davon aus, dass Fehler möglich sind; Korrekturvorschläge zu falschen Git-Inhalten werden per E-Mail entgegengenommen
  • Bei den HTML-Ausgaben kann je nach Leseumgebung zwischen geteilter Version, Einzelseite, Widescreen, ZIP und weiteren Varianten gewählt werden
  • PDFs können in Kombinationen aus US Letter und A4, einseitig und zweiseitig sowie mit Syntax-Highlighting oder in Schwarz-Weiß heruntergeladen werden
  • Übersetzer und Autoren können das gesamte Material von GitHub klonen und anschließend gemäß README daran arbeiten

Ausgabeformate zum Lesen

Korrekturvorschläge und Original-Arbeitsmaterial

  • Der Leitfaden lässt ausdrücklich die Möglichkeit offen, dass Fehler enthalten sein können; Korrekturvorschläge werden per E-Mail entgegengenommen
  • Übersetzer und Autoren können das GitHub-Repository klonen und dem README folgen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-06
Hacker-News-Kommentare

  • Wenn ihr Fehler findet, postet sie bitte. Ich werde sie selbst sammeln und korrigieren — Beej

    • Nicht falsch, aber wenn es im Git-Kontext um vim geht, wäre auch :cq erwähnenswert. Damit beendet man vim mit einem Exit-Status ungleich 0, sodass Git den Commit oder die Operation nicht abschließen kann.
    • Wirklich hervorragende Arbeit, und danke für diese umfassende Ressource. Ich habe nicht alles gelesen, aber die Formulierung in Abschnitt 5.1 ist mir aufgefallen.
      In https://beej.us/guide/bggit/html/split/branches-and-fast-for... heißt es, der „Standard-Branch ist main“ und „früher war es master, und ältere Repositories haben noch master“, aber das stimmt so nicht. Git verwendet weiterhin master als Standard und erlaubt lediglich, dies künftig für git init über git config --global init.defaultBranch zu ändern.
      Beleg: https://github.com/git/git/blob/bc204b742735ae06f65bb20291c9...
      Außerdem vermittelt die Formulierung „ältere Repositories“ die falsche Botschaft. GitHub hat diese Änderung beschlossen, andere sind gefolgt, und Git selbst hat die oben genannte Konfiguration ermöglicht; es geht also nicht wirklich um neue oder alte Repositories, sondern eher um Präferenz.
    • Ich war einer der vielen Studenten, die bei Lambda School von dir gelernt haben, und der Unterricht damals gehörte zu den eindrucksvollsten Momenten dort.
    • Als Teenager habe ich den C-Programmierleitfaden gelesen, und heute, als Firmware-Entwickler, fühle ich mich immer noch sehr in deiner Schuld.
    • Nicht falsch, aber git worktree wäre ebenfalls eine Erwähnung wert. In meinem Workflow war es zentral, und viele wissen gar nicht, dass es existiert.
      Es ist eine gute Möglichkeit, Branches voneinander entwirrt zu halten, ohne sich mit stash herumschlagen zu müssen.

  • Beej's Guide to Network Programming und Beej's Guide to Unix IPC, die ich als Teenager gelesen habe, waren zugänglich und zugleich tiefgehend und haben stark beeinflusst, was für ein Programmierer ich später wurde.
    [0] https://beej.us/guide/bgnet/
    [1] https://beej.us/guide/bggit/

    • [1] ist https://beej.us/guide/bgipc/.
    • Bei mir ähnlich. Ich war Mitte der 90er ein Teenager und fasziniert von IRCd-Servercode und Bots.
      Ich kaufte gebraucht „Slackware Linux Unleashed“ mit CD-ROM; darin gab es C-Networking-Beispiele, und weil mich dieser Code verwirrte, fand ich Beejs Networking-Website. Von dort bin ich immer tiefer in den Kaninchenbau geraten und bin durch verschiedene Buchhandlungen gezogen, um Programmierbücher zu suchen.
      Nachdem ich Richard Stevens’ ausgezeichnetes Nachschlagewerk gekauft hatte, gab es kein Zurück mehr, und ich bin Beej bis heute dankbar, dass er diese Leidenschaft ermöglicht hat.
    • Ich erinnere mich daran, wie ich den Umgang mit select lernte und Beejs Netzwerk-Guide ins Italienische übersetzte, weil ich irgendeinen Portscanner (vielleicht „grabb“?) schneller machen wollte. Schöne Zeiten.
    • Ich kam her, um zu prüfen, ob es dieselbe Person ist, und beim alten Webdesign, bei dem jede Seite noch Charakter hatte, war ich mir fast sicher.
      Das war die Zeit, in der ich Seiten speicherte, um sie offline zu lesen, damit mein Vater sich nicht über die Telefonrechnung aufregte; und wenn der Code funktionierte, fühlte es sich an wie eine Bestätigung, die frühere Misserfolge und Zurückweisungen im Leben überwog. Die Freude, eine Nachricht von einem Computer zu einem anderen zu schicken, war riesig.

  • Als ich „Alter Befehl: git checkout“ sah, wusste ich nicht einmal, dass es git switch gibt, und auch nicht, dass git checkout als alte Alternative gilt. Ich fühle mich alt.
    Gut, ich habe vor fast 10 Jahren angefangen, Git zu lernen, aber es ist seltsam, dass jemand, der heute Git lernt, verwirrt sein könnte, warum ich git checkout benutze. Es fühlt sich an, als würde man eine altmodische Ausdrucksweise verwenden.
    Zurück zum Text: Wenn es diesen Guide gegeben hätte, als ich gelernt habe, wäre er wirklich nützlich gewesen. Er ist leicht nachzuvollziehen und behandelt häufige Fragen gut.
    Ich habe auch gute Erinnerungen daran, wie ich nach meinem ersten Merge-Konflikt erschrocken aufgehört habe und danach Umwege suchte, um Konflikte zu vermeiden.

    • git switch ist ein ziemlich neuer Befehl und wurde erstmals 2019 veröffentlicht.
      Es gibt dazu Diskussionen von 2021 und von vor ein paar Wochen; in letzterer wird auch erwähnt, dass git switch in der Dokumentation noch als experimentelle Funktion gilt.
      https://news.ycombinator.com/item?id=28024972
      https://news.ycombinator.com/item?id=42649858
    • Ich sehe nicht, dass git checkout schon als „alte Alternative“ gilt. Als ich zuletzt nachgesehen habe, war switch immer noch experimentell, und ich habe gar nicht vor, von dem Workflow und den Befehlen abzuweichen, die ich vor etwa 15 Jahren beim Git-Lernen verinnerlicht habe.
      Alles, was ich tun will, funktioniert weiterhin genauso, git checkout macht weiterhin dasselbe wie früher, und es gibt keine Probleme bei der Zusammenarbeit mit anderen über Git – warum sollte ich also meinen Workflow ändern?

  • Dass es überhaupt einen Leitfaden mit mehr als 30 Teilen braucht, um die Nutzung von Git zu erklären, lässt Git so wirken, als hätte es das große Ganze verfehlt

    • Ich verstehe nicht, warum Programmierer sich so heftig darüber aufregen, dass ein komplexes Tool, das komplexe Dinge mit komplexen Datenstrukturen tut, eben eine gewisse Komplexität hat
    • Wenn die Leute nur die Hälfte der Mühe, die sie ins Klagen über Git stecken, ins Lernen von Git gesteckt hätten, bräuchte man wohl keinen Leitfaden mit über 30 Teilen, um Dinge zu erklären, die man in den Manpages findet
      Ein Commit ist ein Snapshot eines Baums und hat eine Liste von Vorfahren. Normalerweise einen, aber nicht immer. Ein Tag ist ein unveränderliches Namensschild für einen Commit, ein Branch ist ein veränderliches Namensschild für einen Commit. Der Index ist ein kleiner Proto-Commit in Arbeit, den man vor dem Committen mit add befüllt
      Das ist Git. Wenn du mehr wissen willst, lies keinen Leitfaden, sondern suche nach Dingen wie „zu einem bestimmten Git-Commit wechseln, ohne den Baum zu beeinflussen“, „nur einen Teil der geänderten Dateien committen“ oder „Commits von anderswo in den aktuellen Baum kopieren“
      Die grundlegenden Abstraktionen sind minimalistisch und einfach. Was man mit diesen Abstraktionen tun will, ist anspruchsvoll und komplex. Ersteres lernt man, Letzteres schlägt man nach; dafür muss man keinen Leitfaden lesen
    • Die Nutzung von Git lässt sich auch in fünf Zeilen HN-Kommentar erklären: git clone, git checkout, git pull, git add + commit + push, git reset / rebase
    • Trotzdem kann man sich damit selbst ins Knie schießen
    • Ja und nein. Die benutzerorientierten Befehle von Git sind für vermutlich 95 % der Nutzer gut genug
      Bei rebase -i stehen Hinweise dabei, welcher Befehl was macht, und wie man die Ausgabe von git log nach Geschmack und Kompromissen formatiert, lässt sich in ein paar Absätzen erklären. Zu den üblichen benutzerorientierten Befehlen zählt man meist auch ziemlich gemischtes Zeug wie git gc, git fsck oder git rev-parse
      Die Low-Level-Befehle sind definitiv obskurer, und sie tun von sich aus vieles, was mit den auf gängige Use Cases optimierten Benutzerbefehlen nicht immer leicht zu erledigen ist
      Kurz gesagt: Git ist groß, sogar riesig, aber für die meisten Entwickler liegt ein beträchtlicher Teil seines Funktionsumfangs weit abseits des Mainstream-Pfads

  • Beängstigend ist, dass der Leitfaden so lang ist
    Ich weiß, dass Beejs Guides im Allgemeinen umfassend sind, aber wie enorm die vielen Feinheiten von Git sind, war mir erst beim Anblick dieses Umfangs richtig klar
    Bei Jujutsu wäre es wohl ein deutlich dünnerer Leitfaden, oder zumindest einer, mit dem Menschen leichter durch Entdecken lernen können

    • Ich versuche, meine Guides größtenteils so zu schreiben, dass man aufhören kann zu lesen, sobald man das Gefühl hat, genug zu wissen. Man muss nicht alles lesen
      Ich habe das Gefühl, dieser Guide deckt nur etwa 10 % von Git ab, hoffe aber, dass er 90 % der üblichen Nutzung abdeckt
    • Dieser Guide ist eher umfassend; am anderen Ende des Spektrums gibt es ein einseitiges Blatt mit 90 % der Git-Befehle, die man künftig brauchen wird: https://wizardzines.com/git-cheat-sheet.pdf
    • Für mich wirkt das wie ein Zeichen dafür, dass Git für die Mehrheit nicht das richtige Tool ist, sich aber irgendwie als Standard verfestigt hat

  • Bei der Arbeit halte ich ein- bis zweimal im Jahr einen zweistündigen Einstieg in das Git-Datenmodell
    Wir gehen tatsächlich in das .git-Verzeichnis hinein, entpacken Dateien und zeigen, dass alles nur eine Klartext-Repräsentation der grundlegenden Datenstrukturen ist. Es ist wirklich großartig zu sehen, wie es bei den Leuten im Kopf Klick macht
    Wir teilen ein grundlegendes Git-Kochrezept-Dokument, damit neue Mitarbeitende anfangen können, Code zu committen, aber die meisten folgen ihm einfach, ohne zu verstehen, was passiert
    Wer dagegen den Kurs besucht hat, kennt zwar nicht alle Befehle gut, hat aber ein ziemlich vernünftiges Arbeitsverständnis davon, was in Git tatsächlich passiert. Befehle lassen sich leicht nachschlagen; wenn das mentale Modell stimmt, sind die Befehle selbst kein großes Problem. Trotzdem drehen sich fast alle Git-Diskussionen auf HN um die Kommandozeile
    Interessanterweise klingt dieser Kurs ähnlich wie der Alt-Text von https://xkcd.com/1597/. Der Unterschied ist, dass das für ein technisches Publikum tatsächlich die richtige Art ist, Git beizubringen, und dass man, sobald man es verstanden hat, ein grundlegendes Verständnis gewinnt, das man nicht wieder vergisst
    Ehrlich gesagt ist der Return on Time hier so hoch, dass es seltsam wäre, es nicht zu machen

    • Ich habe das auch einmal gemacht, und es war wirklich gut; die anschließende Diskussion war ebenfalls hervorragend
      Auf die letzte Folie der Präsentation habe ich Fragen gesetzt, die Kolleginnen und Kollegen auf Basis des Git-Datenmodells beantworten sollten. Zum Beispiel: „Kann man einen Commit in einen anderen Branch verschieben?“ oder „Was garantiert, dass der Commit-Graph keine Zyklen hat?“
      Es war wirklich befriedigend, dass die Leute nicht nur Git benutzt haben, sondern angefangen haben, in Git zu denken
    • „Wenn nur das mentale Modell stimmt, sind die Befehle kein großes Problem“ hätte für mich anfangs vermutlich nach der Art Argument geklungen, die man in den 90ern oft hörte: „Linux ist leicht zu benutzen, wenn man alle Schichten und alle Teile von Linux versteht.“ Theoretisch richtig, aber für die meisten praktisch unmöglich
      Zum Glück habe ich früh ein Video gesehen, das Teile des internen Git-Modells erklärte, und festgestellt, dass in der Praxis schon gar nicht so viel oder tiefes internes Wissen nötig ist, um einen großen Unterschied zu machen. Schon ungefähr 5 % davon zu wissen, wie Git funktioniert, hat mir viel besser verständlich gemacht, was die Befehle tun und wie man sie verwenden sollte
    • Ich würde gern wissen, ob du die Unterlagen oder eine Aufzeichnung dieses zweistündigen Kurses teilen kannst, sofern es keine proprietären Informationen oder Einschränkungen gibt, die eine Veröffentlichung verhindern
      Falls er auf öffentlich zugänglichem Material basiert, das knapp genug ist, um in zwei Stunden zu passen, wäre es schön, wenn du es in diesem Thread oder im HN-Beitrag teilst. Ich glaube, je mehr Lernmaterialien zum selben Thema es gibt, mit unterschiedlichen Voraussetzungen, Analogien und Schwerpunkten, desto besser
    • Ich würde gern wissen, ob es eine Kopie der Präsentation oder ein Video gibt, oder ob du ähnliches Material empfehlen kannst
    • Bitte teile das Video

  • Ich komme mit dem normalen Git-Flow, Merges, Rebases usw. einigermaßen zurecht, überlege aber ernsthaft, lieber zu jujutsu zu wechseln, statt besser in Git werden zu wollen. jj ist mit Git kompatibel, und ich kann es allein nutzen, während meine Kolleginnen und Kollegen einfach Git verwenden

  • Ich habe das Gefühl, dass es einen Trick gibt, den viele Guides und die meisten Git-GUIs übersehen. Eine Ausnahme ist magit, das damit gut umgeht.
    Man setzt den Upstream-Branch nicht auf origin/feature/foo von feature/foo, sondern auf das Ziel, in das man mergen will, also den Integrations-Branch master oder origin/master.
    Dadurch wird vieles einfacher. Wenn man git status ausführt, zeigt es an, wie weit man vom Integrations-Branch abgewichen ist, was nützlich ist; und wenn man git rebase ohne Argumente ausführt, wird direkt auf den Upstream rebased.
    origin/feature/foo als Upstream zu verwenden, ist weniger nützlich. Entwickler „besitzen“ ihren Remote-Branch in der Regel ebenfalls, daher ist es nicht besonders aussagekräftig, wie weit man davon abgewichen ist, und man möchte auch nicht dorthin rebasen.
    Wenn man push.default auf "current" setzt, pusht git push wie erwartet feature/foo nach origin/feature/foo.
    Ich frage mich, warum diese Einstellung nicht verbreiteter ist.

  • Im Abschnitt zur Zusammenarbeit werden Feature-Branches überhaupt nicht behandelt. Ich denke, das ist eine ziemlich gängige Arbeitsweise.
    Ein Vergleich mit der im Guide beschriebenen Methode, bei der „alle ihren eigenen Branch verwenden“, wäre vermutlich hilfreich. Außerdem könnte Abschnitt 17 behandeln, ob man Branches für GitHub-Pull-Requests wiederverwendet oder für jeden PR einen neuen Branch erstellt.

  • Den Artikel habe ich noch nicht geprüft, aber er klingt vielversprechend. Eine weitere Empfehlung ist der Git-Kurs von boot.dev, der von Primeagen unterrichtet wird.
    Er ist interaktiv und geht so tief, dass man direkt Dateien im .git-Verzeichnis manipuliert. Nach diesem Kurs hatte ich ein völlig neues mentales Modell davon, wie Git funktioniert.