Als in den 1990er-Jahren Linux populär wurde, zählte ich zu den ersten deutschsprachigen Autoren, die dazu ein Buch verfassten. Insofern ist es ein wenig verwunderlich, dass ich mir mit einem Buch zu Linus Torvalds zweitem Meisterstück, der Versionsverwaltungs-Software Git, fast 15 Jahre Zeit ließ.
Dass das Git-Buch nun doch endlich zustande kam, ist vor allem der Hartnäckigkeit meines Lektors Christoph Meister zu verdanken. Schon vor mehr als einem Jahr setzten Bernd Öggl (mit dem ich zuletzt das Docker-Buch verfasst habe) und ich die Unterschrift auf den Vertrag. Verschiedene andere Projekte hielten das Buch mehrfach auf, aber jetzt ist es erschienen.
Bernd und ich haben das Gefühl, dass uns ein wirklich schönes Buch gelungen ist: Es beschreibt Git in seiner ganzen Breite, vom Einstieg in der Konsole oder mit Visual Studio Code bis hin zu fortgeschrittenen Themen wie Rebasing, CI-Pipelines oder LFS. Inhaltlich bleiben wir nicht bei der Git-Anwendung auf der Kommandoebene stehen, sondern gehen auch auf allgemeine Arbeitstechniken ein (z.B. Workflows) und zeigen, welche neuen Möglichkeiten sich im Zusammenspiel mit den großen Git-Plattformen ergeben (also GitHub, GitLab & Co.). Werfen Sie einen Blick in Vorwort und Inhaltsverzeichnis (PDF)!
Das Buch hat 416 Seiten und ist ab sofort beim Rheinwerk Verlag sowie in allen Buchhandlungen lieferbar.
Hier finden Sie weitere Informationen samt einer längeren Inhaltsbeschreibung, Errata, Beispieldateien etc.
Themen wie egit (Eclipse) und TortoiseGit wären schön. Es gibt Entwicker, welche mit egit Probleme haben und die git Konsole zu umständlich finden. Besonders merge Konflikte sind ein Problem, dabei passiert es, dass alte commits verloren gehen. Ein sauberes Konflikmanagement, welches effizient ist und zu keinen merge Fehlern führt, ist oft schwierig. Welches Tool ist hier gut? Oder wie unterscheiden sich hier die Tools? Wie kann man im Nachhinein feststellen, ob ein merge alte commits gekillt hat?
Auf TortoiseGit gehen wir ein, auf Eclipse nicht. Generell berücksichtigen wir zwar diverse Git-Oberflächen (VSCode, Emacs und vi, Visual Studio, IntelliJ, Xcode, GitHub Desktop etc.), aber der Schwerpunkt des Buchs liegt naturgemäß woanders: Wir erläutern ausführlich die Grundlagen und Anwendungstechniken von Git. Mit diesem Grundwissen können Sie dann jede Oberfläche für Git-Funktionen bedienen.
Der umgekehrte Ansatz, Git also ausgehend von IDEs wie Eclipse oder IntelliJ zu beschreiben, würde zu sehr viel Redundanz führen — und es gäbe immer einen Leser oder eine Leserin, der/die dann klagt, dass gerade ihre Oberfläche nicht berücksichtigt wird.
Vielleicht habe ich ein Brett vorm Kopf. Seite 33: Das clone sollte doch funktionieren, selbst wenn first-test.git privat ist, oder?
Nein. Ein privates Repository ist nur für dessen/deren Besitzer zugänglich. In diesem Fall habe ich das Repository privat für Testzwecke eingerichtet. Nur ich kann es verwenden. Ganz anders verhält sich ein öffentliches Repository (z.B. andere Beispiele zum Buch unter https://github.com/git-buch). Diese Repositories können Sie klonen und in der Folge nutzen. Sie können allerdings keine Änderungen hochladen (push). ‚Öffentlich‘ bedeutet also nur, dass Sie lesen dürfen (git clone/pull), nicht aber ändern (push). Ändern dürfen nur die Besitzer des Repositories.