Git

Es sind manchmal die kleinen Dinge, die einem im Terminal noch glücklicher machen, für Probleme, die man vorher gar nicht hatte. Ein Beispiel ist etwa das Anzeigen von Unterschieden zwischen zwei Versionen mit einer Datei mit diff bzw. in diesem Fall ein einfaches git diff. Mit diff-so-fancy lässt sich das Git Diff spürbar aufhübschen, sodass es besser für den Menschen lesbar ist. Wie so häufig sagen Bilder mehr als viele Worte, weshalb hier ein Screenshot folgt, wo das Standard Diff verwendet wird: ...

Es sind manchmal viele Kleinigkeiten in einem Projekt in einer Gruppe, die Mitarbeiter ziemlich nerven können. Neben offensichtlichen Dingen wie Clean Code und einheitliche Bennung von Dateien, Klassen und Methoden, ist eine Sache die häufiger im Zusammenspiel zwischen Windows- und Linux-Nutzern stört: Der Zeilenumbruch. Im Windows-Universum besitzen Zeilenumbrüche ein CR LF und unter Linux LF. Näheres zu Zeilenumbrüchen findet sich im entsprechenden Wikipedia-Artikel zu Zeilenumbrüchen. Git Repositorys sollten immer nur LF als Zeilenendung enthalten, da gemischte Zeilenenden sich auf den Betriebssystemen unterschiedlich auswirken und einfach unschön in der Handhabung sind. Für Windows-Nutzer kann beim Auschecken automatisch LF durch CR LF ersetzt werden. Ebenso sollten immer die CR LF in LF umgewandelt werden, wenn man etwas in das Repository eincheckt. In der Git für Windows Standard-Installation wird nachgefragt, wie Zeilenumbrüche gehandhabt werden sollen. Im Standard wird die zuvor beschriebene automatische Umwandlung vorgeschlagen, die man akzeptieren sollte. ...

Dateitypen, die sich nicht effizient in Git-Repositories nutzen lassen, sind Binärdateien. Also genau die Dateien, die man nicht mit einem gängigen Texteditor öffnen kann. Mit Git LFS kann man Binärdateien effizienter verwalten, dabei ist Git LFS eine Erweiterung für den Git-Client, ein entsprechendes Gegenstück wird aber auch auf dem Server benötigt. Doch bevor man sich Git LFS anschaut, sollte man verstehen, wie Git Dateien intern abspeichert, um nachvollziehen zu können, warum man eine Lösung wie Git LFS braucht. ...

In der Regel klont man sich ein Git-Repository, in dem auch ein Arbeitsverzeichnis eines Branches ausgecheckt ist. Je nach Projektart kann es passieren, dass eine Arbeitskopie nicht reicht. Das ist etwa dann der Fall, wenn man ein Projekt kompilieren muss, was eine Zeit in Anspruch nimmt, in derselben Zeit aber auf einem anderen Branch weiterarbeiten möchte. Im Standard geht das so mit einem geklonten Repository nicht, da sich beim Wechsel des Branches das Arbeitsverzeichnis verändert und somit auch die Kompilierung nicht voll durchläuft bzw. es zu Fehlern kommt. ...

Um Git-Repositorys zu Hosten gibt es heutzutage sehr viele verschiedene Möglichkeiten. Die einfachste und wohl bekannteste Lösung für viele Open-Source-Projekte ist die Nutzung von GitHub. GitHub bietet auch das Hosten von privaten, nicht öffentlichen, Repositorys an, doch ist dies kostenpflichtig. GitHub ist zudem nicht Open Source und man kann es nicht selbst Hosten. Eine Alternative ist GitLab, welches sowohl als Service zum kostenfreien Nutzen verfügbar ist, als auch Open Source ist. Auf GitLab.com kann man im Gegensatz zu GitHub seinen Code in privaten Repositorys schieben, ohne bezahlen zu müssen. Da GitLab Open Source Software ist, lässt sich die Community Edition auch auf eigener Hardware selbst hosten. Allerdings ist GitLab vergleichsweise fett und braucht selbst mit wenigen Nutzern recht viel Arbeitsspeicher, hat dafür aber eine Vielzahl an Funktionen. Für Firmen und anderen Projekte dürfte GitLab wohl eine gute Wahl sein, doch ist es für das Hosten von privaten Repositorys für einzelne Personen eher fett, da man die meisten Features wohl eh nicht braucht. Eine weitere Alternative ist Gogs, bzw. dessen neuer Fork namens Gitea. Gitea ist ein recht neuer Fork von Gogs, was wiederum ein quasi-Klon von GitHub ist. Wobei sich der Ausdruck „Klon“ mehr auf das Aussehen und die grundlegenden Funktionen richtet und somit weniger auf den darunter liegenden Code. ...

Nach längerer Pause zum Thema Versionsverwaltung mit Git geht es an dieser Stelle ein wenig weiter. Git-Repositorys beinhalten bekanntlich ihre vollständige Historie, so dass alle Änderungen immer in der Historie verbleiben. Problematisch wird das aber, wenn Zugangsdaten im Repository gelandet sind. Ein bloßes Entfernen funktioniert da leider nicht, da die Historie ja vollständig da ist. Ein einfaches Beispiel sieht man etwa, wenn man bei GitHub nach „delete id_rsa“ sucht, was ein privater SSH-Key ist, der nicht eigentlich in ein Git-Repository landen sollte. Genauso findet man auf GitHub Commit-Messages mit dem Inhalt „remove password“. ...

Im Herbst 2014 bis Frühling 2015 veröffentlichte ich auf meinem Blog ein bisher vierteiliges Git-Tutorial. Die Reihe diente ungeplant als Vorlage und Basis für ein Git-Buch, welches ich im Verlaufe der letzten ~11 Monate geschrieben habe und im mitp-Verlag jetzt erschienen ist. Der Inhalt Insgesamt fasst das Buch mit allen drum und dran 272 Seiten. Aufgeteilt ist es in insgesamt 10 Kapitel. Einführung: Im ersten Kapitel geht es zunächst um den Einstieg in das Thema von Versionsverwaltung. Konkret also was eine Versionsverwaltung ist, wofür sie gut ist und welche Arten es gibt. ...

Im letzten Teil ging es um das Rebasen und das Einrichten und Nutzen von Remote-Repositorys. In diesem Teil wird es rein um GitHub und dessen Workflow gehen. Darunter fällt unter anderem das Erstellen eines Repositorys und wie man sich an Open-Source-Projekten auf GitHub beteiligen kann. Dieses Tutorium besteht aus vier Teilen. Wem das Tutorium gefällt und mehr über Git lernen möchte, der kann sich das Buch „Versionsverwaltung mit Git“ für 29,99€ bestellen. In diesem Buch, was ich geschrieben habe, werden die Themen rund um Git noch deutlich ausführlicher behandelt. ...