Git-Buch

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 nahezu druckreif.

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 erscheint Ende August 2020 beim Rheinwerk Verlag.

Hier finden Sie weitere Informationen samt einer längeren Inhaltsbeschreibung, Errata, Beispieldateien etc.

2 Gedanken zu „Git-Buch“

  1. 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?

    1. 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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Wenn Sie hier einen Kommentar absenden, erklären Sie sich mit der folgenden Datenschutzerklärung einverstanden.