Netz - Rettung - Recht (Artikel mit Tag git)

FLOSS'n'net - Aktivitäten 09/2018

nospam@example.com (Thomas Hochstein) — Thu, 18 Oct 2018 16:50:00 +0000

Im September 2018 hatte ich mal wieder ein wenig Zeit gefunden, mich mit dem einen oder anderen Projekt rund um freie Software (FLOSS) oder das Netz zu beschäftigen.

Dabei habe ich folgendes beigetragen:

FAQs, Anleitungen und Tutorials

Installationsanleitung für git for Windows auf th-h.de

Serendipity (s9y)

Ein Großteil meiner Aktivität betraf das Blogsystem Serendipity, mit dem auch dieses Blog betrieben wird.

s9y-Kern

Im Core habe ich nur ein wenig sortiert und aufgeräumt:

Plugins

Ich habe einen Bug im Plugin serendipity_event_dsgvo_gdpr behoben, der in den meisten Fällen die Anzeige der durch Plugins verarbeiteten Daten verhindert hat.
Display plugin legal info.
Außerdem habe ich eine Formulierung im Cookie-Consent-Modul des Plugins der Rechtslage angepasst.
Cookie Consent: “understood”, not “accepted”.
Schon lange hat mich geärgert, dass serendipity_event_markdown keine Zitate in Kommentaren unterstützt, die in Markdown mit > eingeleitet werden. Bei näherer Betrachtung wurde mir bewusst, dass das an serendipity_event_unstrip_tags liegt, das HTML in Kommentaren als Text anzeigt und zu diesem Zweck < und > durch die entsprechenden Entities ersetzt. Das muss serendipity_event_markdown also rückgängig machen, aber nur dann, wenn es sich wirklich um ein Zitatzeichen handelt. Ich habe das mit einem regulären Ausdruck gelöst.
Make blockquotes in comments usable.
Die meisten s9y-Plugins werden über Spartacus installiert; einige wenige Plugins befinden sich im Core, werden also mit s9y zusammen installiert und auch nur mit s9y zusammen aktualisiert. Das gilt zum Beispiel für das Spartacus-Plugin; könnte man dieses nur über Spartacus installieren, wäre das ein Catch-22. Manche Plugins aber finden sich sowohl im Core als auch in Spartacus und sollten daher nur an einer Stelle - nämlich in Spartacus - aktualisiert und dann einfach in den Core kopiert werden. Das ist nicht immer beachtet worden, so dass sich im Core und in Spartacus teilweise unterschiedliche Versionen mit unterschiedlichen Änderungen befanden. Das habe ich behoben und die betroffenen Plugins synchronisiert sowie im Entwickler-Wiki dokumentiert.
Sync plugins in core and Spartacus.

Webseiten

Wir blenden auf der Startseite der s9y-Webseiten die aktuellsten Beiträge aus dem s9y-Blog ein. Das funktionierte nicht mehr. Nach stundenlangem Debugging weiß ich immer noch nicht genau, warum - aber der Wechsel vom RSS- auf dem Atom-Feed hat das Proble behoben (“gelöst” ist vielleicht das falsche Wort dafür).
Switch news feed from blog to atom feed.
Außerdem habe ich ein zwei Jahre altes Versprechen eingelöst und mich um eine Breadcrumb-Navigation in der s9y-Dokumentation gekümmert.
Add breadcrumb navigation to docs.
Add CSS for breadcrumbs.

Viel war’s nicht, aber ich bin immer froh, wenn ich wenigstens alle paar Monate einmal einige Stunden Zeit finde, mich durch Texte, Bugreports oder Code an der Weiterentwicklung freier Software (im weitesten Sinne: des Netzes) zu beteiligen.

Installationsanleitung für "git for Windows"

nospam@example.com (Thomas Hochstein) — Thu, 04 Oct 2018 05:56:00 +0000

git ist bekanntlich das von mir seit 2010 genutzte Versionsverwaltungssystem, über das ich auch hier im Blog schon verschiedentlich berichtet habe. Allerdings sind diese Einträge zumeist sieben oder acht Jahre alt und nicht mehr auf dem aktuellen Stand. Grund genug, ihre Inhalte allmählich in meine Webseiten zu überführen, wo sie eigentlich ja auch hingehören.

Angefangen habe ich jetzt mit einer - bebilderten - Installationsanleitung für git for Windows.

Github: alte TLS-Versionen und SSH-Algorithmen deaktiviert

nospam@example.com (Thomas Hochstein) — Tue, 03 Apr 2018 04:40:00 +0000

Github hat am 22.02.2018 Änderungen an der HTTPS-und SSH-Konfiguration vorgenommen und ältere und weniger sichere Zugriffsmöglichkeiten deaktiviert. Das betrifft sowohl TLS 1.0 und TLS 1.1 als auch - für den SSH-Schlüsselaustauch - diffie-hellman-group1-sha1 und *diffie-hellman-group14-sha1. Wenn die verwendete Client-Software nicht mindestens TLS 1.2 bzw. einen anderen Schlüsselaustausch-Algorithmus beherrscht, muss man mithin aktiv werden.

Wer - wie ich - Git for Windows zusammen mit PLink aus dem Putty-Paket als SSH-Client verwendet, bekommt sonst möglicherweise - wenn er Putty länger nicht mehr geupdatet hat - beim git pull oder git push eine Meldung dieser Art zu sehen:

FATAL ERROR: Couldn't agree a key exchange algorithm (available: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521)

Natürlich (?) hatte ich die Ankündigungen über die Änderungen bei Github nicht präsent, vermutete aber etwas in der Art - und Google führte mich nach einiger Zeit zu einem Issue im Github-Desktop-Projekt. Und siehe da - Putty kann erst ab Version 0.68 (21.02.2017) elliptische Kurven:

Support for elliptic-curve cryptography (the NIST curves and 25519), for host keys, user authentication keys, and key exchange.

Ein putty-Update später flutschte dann auch wieder alles.

(Ab dieser Version wird allerdings ggf. eine 64bit-Version von Putty installiert, die dann unter Windows nicht in C:\Program Files (x86) landet, sondern in C:\Program Files, so dass ggf. die Umgebungsvariable GIT_SSH angepasst werden muss.)

Zeitstempel von Dateien unter Versionsverwaltung

nospam@example.com (Thomas Hochstein) — Mon, 15 Jan 2018 06:15:00 +0000

Die Verwaltung von Dateien in einem Versionskontrollsystem (VCS) wie git hat einen Nachteil: der Zeitstempel im Dateisystem gibt nicht mehr den Zeitpunkt der letzten Änderung an dieser Datei wieder, sondern den Zeitpunkt, zu dem sie zuletzt (ggf. mit vielen anderen Dateien) ausgecheckt wurde.

Für Webseiten bedeutet das, dass man für die Ausgabe des Datums der letzten Änderung nicht mehr auf den Zeitstempel der entsprechenden Datei zurückgreifen kann. Das macht mir nichts aus, denn zum einen verwende ich mittlerweile weitgehend statische Webseiten, bei denen das ohnehin nicht ohne weiteres möglich wäre, und zum anderen bringt dieser Ansatz zwar den Vorteil der Automatisierung mit sich, aber zugleich den - aus meiner Sicht überwiegenden - Nachteil, dass jeder verbesserte Tippfehler, jede unsichtbare Änderung am Seitengerüst als “Update” vermerkt wird, obwohl der Inhalt möglicherweise weiterhin völlig veraltet ist. Ich ziehe es daher vor, selbst zu entscheiden, was als “Änderung” gilt, und dann das Datum der letzten Änderung selbst zu setzen.

So weit, so gut - aber wie sieht das mit Downloaddateien aus?

Zeitstempel von Downloadangeboten passend setzen

Jedenfalls dann, wenn man Downloadangebote nicht nur verlinkt, sondern den Downloadbereich auch als Dateiübersicht zugänglich macht - wie ich es auf meinen Webseiten tue -, ist es für den Nutzer gelinde gesagt verwirrend, wenn der angezeigte Zeitstempel der Dateien nichts mit der letzten Änderung derselben zu tun hat.

Dafür gibt es natürlich verschiedene einfache Lösungen: Zum einen könnte ich darauf verzichten, einen Downloadbereich in diesem Sinne anzuzeigen, und die Dateien einfach nur verlinken. Tatsächlich sind die meisten Downloadangebote irgendwo auf meinen Seiten verlinkt, und ich speichere für sie auch Metadaten wie bspw. das Datum der letzten Änderung, das bei dem Link angezeigt wird, wie bspw. bei meinen Downloads aus dem Bereich des Rettungswesens. Ich schätze es aber gerade, dass man in den Downloadangeboten auch “einfach so” stöbern kann. - Zum anderen könnte ich darauf verzichten, Downloads unter Versionskontrolle zu stellen, und sie in einem gesonderten Archiv speichern. Gerade für Software-Releases - und auch meine FAQs - wäre das vernünftig; beide werden ohnehin in gesonderten git-Repositories versioniert, so dass es nicht erforderlich ist, einzelne Releases nochmal im Repository meiner Webseiten zu speichern. Andererseits gibt es aber Downloads, die nicht selbst unter Versionskontrolle stehen, und - mir viel wichtiger - eine getrennte Speicherung der Downloadangebote würde bedeuten, dass ich meine Webseiten nicht “aus einem Guss” aus dem git-Repository erzeugen bzw. wiederherstellen kann; ich müsste dann den Downloadbereich getrennt sichern und einspielen.

Trotz allem denke ich regelmäßig darüber nach, die Downloadangebote aus der Versionskontrolle herauszunehmen (das ist ja ein wenig auch eine Frage der Größe des Repositories). Bis dahin wollte ich aber eine andere Lösung für das Problem der “falschen” Zeitstempel im Directory-Listing - und eigentlich kann das so schwierig ja nicht sein: immerhin habe ich Metadaten, aus denen sich für jede einzelne Datei im Downloadbereich das Datum der letzten (inhaltlichen) Änderung ergibt. Wie schwer kann es sein, den Zeitstempel - also das Datum der letzten Änderung der Datei im Dateisystem, die sog. modification time oder kurz mtime - passend zu setzen?

Wie sich herausstellt: nicht sehr schwer. Es genügt, ein paar Zeilen als postprocess-Block in der Nanoc-Konfiguration hinzuzufügen:

postprocess do
# iterate over all items starting with /archives/ or /net/usenet/faqs/ with kind “file” or “faq” that have “updated_at” set
items.select { |item| %r<^/(archives|net/usenet/faqs)/> =~ item.identifier && [ ‘file’, ‘faq’ ].include?(item[:kind]) && !item[:updated_at].nil? }.each do |item|
# prefer the “text” representation, if available (for FAQs)
unless item.reps[:text].nil?
path = item.path(rep: :text)
else
path = item.path
end
# use the output files, not the source
path = @config[:output_dir] + path
# change the mtime to “updated_at”
# “updated_at” is part Date (when set to 2017-10-01), part String (when set to ‘2017-10-01’),
# so it has to be converted to strings and parsed (instead of using .to_time)
FileUtils.touch path, :mtime => Time.parse(item[:updated_at].to_s)
end
end

Gut, die Zeitstempel sind jetzt immer noch auffällig, weil ich natürlich nur das Datum der letzten Änderung mitführe, nicht die Uhrzeit, und die Dateien daher scheinbar alle um Mitternacht erzeugt werden, aber damit lässt sich leben. Einziger Nachteil: Die unerwartet “alten” Dateien im Downloadbereich bringen das Dependency-Tracking von Nanoc durcheinander und werden daher bei jedem Durchlauf neu erzeugt, weil die Ausgabedateien (mit einem Zeitstempel von vor einigen Monaten oder Jahren) scheinbar älter sind als die Quelldateien (die frisch aus der Versionskontrolle ausgecheckt wurden und daher einen aktuellen Zeitstempel haben), aber damit lässt sich leben.

Symlinks erzeugen

Außerdem konnte ich so ein weiteres Problem lösen:

Die Downloads meiner Scripts (und anderer Software) tragen die Versionsnummer im Dateinamen, bspw. checkmail-0-6-1.tar.gz für die Version 0.6.1 von checkmail. Ich möchte aber zugleich immer die aktuellste Version unter dem generischen Namen checkmail.tar.gz anbieten. Nichts einfacher als das: checkmail.tar.gz muss ein Symlink auf den jeweils neuesten “versionierten” Dateinamen sein. Das lässt sich so auch in das gir-Repository einchecken … nur bearbeite ich meine Webseiten unter Windows - und da ist das Konzept von symbolic links eher nicht so bekannt. Dieses Problem hatte ich vorübergehend “gelöst”, indem ich einfach zwei identische Dateien gespeichert habe - aber das ist natürlich ein nerviger Hack, der doppelt Platz braucht und einfach nicht elegant ist.

Nachdem ich jetzt ohnehin die Dateien im Downloadbereich nach ihrer Generierung nachbehandle, lassen sich dabei auch direkt die Symlinks erzeugen - zwar immer noch aus einer Platzhalterdatei, aber dafür genügt dann eine leere Datei, die nur den passenden Namen trägt. Mein Ansatz dafür ist folgender (eingefügt in den oben bereits gezeigten Block):

postprocess do
[…]
# use the output files, not the source
path = @config[:output_dir] + path
# generate symlinks
if item[:kind] == ‘file’ && item[:current]
# remove placeholder and symlink generic name (‘myprog.tar.gz’)
# to current file (‘myprog-1-2-17.tar.gz’)
FileUtils.rm path
FileUtils.ln_s item[:current], path
# mtime shall be changed for the current file
path = File.dirname(path) + ‘/’ + item[:current]
end
# change the mtime to “updated_at”
[…]
end

Insgesamt fühlt sich das immer noch wie ein Hack an, aber immerhin nicht mehr ganz so krude.

git-commit-notifier

nospam@example.com (Thomas Hochstein) — Fri, 18 Aug 2017 06:05:00 +0000

Es gibt zwar nicht sehr viele “eigene” git-Repositories, an denen außer mir noch andere mitentwickeln, aber einige doch schon, zumindest potentiell; und ungeachtet dessen bereitet es mir auch als bloße Spielerei Freude, wenn ich zumindest die Möglichkeit anbieten kann, per Mail über neue Commits zu informieren.

Bisher habe ich das mit dem “eingebauten” - quasi im Lieferumfang befindlichen - Script post-receive-email gelöst, das allerdings optisch altbacken daherkommt und v.a. kein Diff mitliefert. Oft habe ich nach Alternativen geschaut und bin dabei immer wieder über git-commit-notifier gestolpert, das aber irgendwie[tm] bei mir nicht recht laufen wollte. Der - schon mehrmals erwähnte - Serverumzug, den auch meine öffentlichen git-Repositories mitgemacht haben, bot nun die Gelegenheit für einen neuen Anlauf - und was soll ich sagen? Es funktioniert!

Wenn Ruby vorhanden ist (apt install ruby rubygems), genügt ein gem install git-commit-notifier, und dann bedarf es nur noch eines Hooks (post-receive im hooks-Verzeichnis, ausführbar!) mit dem folgenden Inhalt:

#!/bin/sh
git-commit-notifier /path/to/git-notifier-config.yaml

… und einer Konfiguration in /path/to/git-notifier-config.yaml nach dem vorhandenen Muster, und schon gibt es schön bunte Benachrichtigungen, deren Adressaten und Inhalt sehr weitgehend konfigurierbar sind.

Screenshot einer durch git commit notifier generierten Benachrichtigung.

Git Aliases

nospam@example.com (Thomas Hochstein) — Fri, 19 May 2017 04:50:00 +0000

Git nutze ich jetzt mehr als sieben Jahre, kratze aber oft immer noch nur an der Oberfläche. Insbesondere habe ich lange Zeit die sehr nützlichen Aliase für Git-Kommandos nicht genutzt, die die Tipparbeit sehr vereinfachen können.

Pro Git sagt im Kapitel 2.7 “Git Aliases” eigentlich alles dazu, was man wissen mus: git config alias.NAME COMMAND macht git NAME zu einem Alias für git COMMAND. Ist COMMAND kein Git-Kommando, ist ihm ein ! voranzustellen. git config --global statt git config macht den Alias für alle Repositories des Benutzers verfügbar, git config --system tut das systemweit.

Zwei Beispiele will ich noch geben:

`git publish` für Webseiten

In meinem “Webseiten-Workflow” ist es regelmäßig erforderlich, Änderungen aus dem test-Zweig eines Repositorys in den master-Zweig zu übernehmen und diesen dann zu pushen. Dafür kann man jedes Mal git checkout master; git merge test; git push; git checkout test tippen, und so habe ich das auch lange Zeit gemacht. Man kann aber auch einen Alias publish definieren und dann schlicht (und gut merkbar) git publish verwenden, um die Änderungen aus dem test-Zweig zu “veröffentlichen”.

Der Alias lässt sich anlegen durch git config alias.publish '!git checkout master; git merge test; git push; git checkout test' oder durch Einfügen des folgenden Abschnitts in die config-Datei im .git-Verzeichnis des Repositorys:

[alias]
  publish = "!git checkout master; git merge test; git push; git checkout test\n"

`git refresh` zur Übernahme von Upstream-Änderungen

Wer in einem Github-Projekt mitarbeitet, wird regelmäßig das entsprechende Repository forken und dann Änderungen als Pull Requests zur Überprüfung stellen. Ich habe dann in meinem lokalen Repository jeweils zwei Remotes konfiguriert: origin ist mein eigenes Github-Repository, der Fork, und upstream das Repository des Projekts. Außerdem habe ich in meinem Repository einen upstream-Branch, der dem master-Branch des Projekt-Repositorys folgt.

Will ich Änderungen aus dem Projekt-Repository in meinen master-Zweig übernehmen, gehören dazu folgende Schritte:

den upstream-Zweig mit dem master-Zweig des Projekt-Repositorys zu aktualisieren
den upstream-Zweig in meinem geforkten Repository veröffentlichen
den upstream-Zweig in meinen master-Zweig mergen
meinen master-Zweig veröffentlichen

Das erfordert also folgende Kommandos:

git checkout upstream
git pull
git push origin
git checkout master
git merge upstream
git push origin
git remote prune origin

(Das letzte Kommando entfernt lokale Tracking-Branches, die in meinem Github-Repository schon nicht mehr existieren.)

Ein Alias dafür ist echt praktisch:

git config alias.refresh '!git checkout upstream; git pull; git push origin; git checkout master; git merge upstream; git push origin; git remote prune origin'

git refresh führt dann alle dargestellten Kommandos nacheinander aus.

Workflow für die Erstellung und Pflege von Webseiten

nospam@example.com (Thomas Hochstein) — Wed, 17 May 2017 05:20:00 +0000

Ich stelle die von mir betriebenen Webseiten, die nicht auf interaktive Funktionen angewiesen sind, Stück für Stück auf statisch generierte Seiten um, zuletzt meine Homepage. Dabei setze ich auf einen Workflow, der nanoc als static site generator und git als Versionsverwaltungssystem umfasst und dafür sorgt, dass Änderungen der Seiten automatisch eingespielt werden.

Entwicklung, Test und Veröffentlichung

Bei Verwendung eines static site generators werden die Webseiten zunächst aus Quelldateien erzeugt und müssen dann veröffentlicht, d.h. in das passende Verzeichnis des Webservers befördert werden, der sie anzeigen soll. Darüber hinaus ist es generell sinnvoll, “Code” im weitesten Sinne - und dazu gehören dann auch HTML- und CSS-Dateien bzw. die Quellen, aus denen diese erzeugt werden - in einem Versionsverwaltungssystem zu speichern, in dem Änderungen nachverfolgbar sind und wo jederzeit auf ältere Versionen zurückgegriffen werden kann. Nimmt man dies zusammen, unterscheiden sich Webseiten damit letztlich kaum mehr von Webapplikationen oder anderer Software: es gibt den Quellcode und das Kompilat (die fertigen Seiten, das ablauffähige Programm), Quellcode muss verwaltet und das Ergebnis getestet und schließlich veröffentlicht (deployed) werden.

Für die drei Schritte - entwickeln, testen, veröffentlichen - werden zumeist mehrere Rechner (Systeme, Umgebungen) benötigt, die unterschiedlichen Zwecken dienen:

Entwicklungsumgebung
Der Rechner, auf dem die Seiten entworfen, bearbeitet und ggf. auch getestet werden.
Git-Server
Git ist zwar ein verteiltes Versionsverwaltungssystem, aber es ist generell sinnvoll, das Repository nicht nur auf dem eigenen Arbeitsrechner vorzuhalten, sondern auch auf (mindestens) einem Server. Das schafft Redundanz und ermöglicht es, auf verschiedenen Rechner zu arbeiten und die Ergebnisse jeweils zu synchronisieren.
Testumgebung
Es ist sinnvoll, ein Testsystem vorzuhalten, dass dem Echtsystem weitgehend entspricht, um testen zu können, ob die Webseiten auch wirklich so aussehen und “funktionieren”, wie man sich das vorstellt.
Echtumgebung
Am Ende des Tages sollen die Webseiten auf einem Rechner im Netz liegen, der sie mithilfe eines Webservers weltweit abrufbar macht.

Grundsätzlich kann man das alles auf ein- und demselben Gerät betreiben: eine im Netz verfügbare Maschine, auf der man sich einloggt und entwickelt, auf der Git verfügbar ist und die zugleich Test- und Echtumgebung darstellt. Meistens wird man aber doch auf dem heimischen Desktoprechner oder dem Laptop arbeiten wollen und einen Webserver (oder auch nur Webspace) irgendwo angemietet haben. Letzteres gilt auch für mich.

Mein Workflow

Ich bearbeite die Quelldateien (den Sourcecode) meiner Webseiten auf meinem Desktoprechner oder dem Laptop unter Windows, zumeist mit Sublime Text, reine Markdown-Dateien manchmal auch mit MarkdownPad.

nanoc unterstützt einen sehr bequemen Testmodus mit eingebautem Webserver: nach dem Compilieren mit nanoc genügt ein nanoc view, um einen Webserver zu starten, der dann unter http://localhost:3000/ die Website zur Ansicht bereitstellt. Leider funktioniert das für mich noch nicht, denn zwar lässt sich nanoc grundsätzlich auch unter Windows installieren und betreiben, aber das für den LESS-Filter erforderliche Ruby-Gem leider nicht - jedenfalls ist mir das nicht gelungen. Daher arbeite ich weiterhin “nach alter Väter Sitte” und lade die geänderten Dateien per SCP bzw. SFTP entweder auf einen lokalen Linux-Server oder direkt auf den externen Webserver hoch bzw. sorge für eine automatische Synchronisierung mit WinSCP. Dort wird dann compiliert und im Browser das Ergebnis angeschaut.

Auch das Veröffentlichen der Seiten unterstützt nanoc mit dem Kommando nanoc deploy, das ein Deployment per git, per rsync oder mittels fog unterstützt. Das ist sicherlich sehr nützlich, wenn man die Webseiten auf dem Entwicklungsrechner testet und dann von dort auf den Webserver überspielt; nachdem nanoc aber auf meinen Windows-Rechnern nicht läuft, gehe ich einen anderen Weg und compiliere direkt auf dem Webserver. Ich lade also den Quellcode hoch, lasse nanoc auf dem Server laufen und das Ergebnis dann unmittelbar in das Webserver-Verzeichnis ausgeben (in der Regel durch ein passend gesetztes output_dir in der nanoc.yaml).

Ich halte regelmäßig neben der aktuellen Fassung meiner Webseiten auch eine Testfassung vor, die ich über eine passwortgeschützte URL aufrufen kann. Das hat den Vorteil, dass ich von überallher testen kann und zudem die Testumgebung und die Echtumgebung identisch sind, weil sie auf demselben Server (in zwei unterschiedlichen virtual hosts) laufen.

Das jeweilige Git-Repository für eine Website hat daher immer mindestens den master- und einen staging-Zweig; im letzteren wird getestet, der erstere enthält die aktuelle Echtversion. Wenn ich einen dieser Zweige per git push auf meinen Git-Server schiebe, wird er automatisch auf den Webserver kopiert (in das Quellverzeichnis für die Echtfassung oder dasjenige für die Testversion der Website), dort compiliert und bereitgestellt. Auch für dieses “Kopieren” oder generell das Aktualisieren einer Website über git gibt es eine Reihe von Möglichkeiten: man kann bspw. einfach das Git-Repository auf dem Webserver auschecken, oder aber man checkt via git archive wirklich nur den Inhalt des Repositorys aus. Ich habe mich für letzteres entschieden; einziger Nachteil ist, das aus dem Repository entfernte Dateien nicht automatisch gelöscht werden, ggf. also “Leichen” verbleiben. Dafür habe ich nicht das komplette Repository mit der ganzen History herumliegen.

Ein Beispiel

In der Praxis sieht das dann ungefähr so aus:

Ich aktualisiere mein lokales Git-Repository auf dem jeweiligen Arbeitsrechner, damit es auf dem aktuellen Stand ist.
Ich verändere oder ergänze meine Webseiten, indem ich die entsprechenden Dateien auf dem Arbeitsrechner bearbeite.
Wenn umfangreichere Tests erforderlich sind, lade ich die geänderten Dateien auf meinen Webserver in das Quellverzeichnis für die Test-Instanz der jeweiligen Website hoch und führe - auf dem Server - nanoc aus, so dass die Testinstanz der jeweiligen Webseiten aktualisiert wird. Im Browser kann ich dann die geänderten Seiten durch Aufruf von http://test.meine-website.example/ ansehen. Alternativ kann ich natürlich auch auf einem anderen Rechner im lokalen Netz testen.
Wenn ich mit dem Ergebnis zufrieden bin, aktualisiere ich den test-Zweig meines lokalen Git-Repositorys und schiebe ihn per git push auf den externen Git-Server.

Dort wird ein post-receive-Hook ausgeführt, der auf dem richtigen Webserver ein PHP-Script mit den passenden Paramtern aufruft. Das Script sorgt dann dafür, dass die Dateien aus dem Git-Repository ausgecheckt werden, und führt danach nanoc aus. Für den test-Zweig des Repositories websites/meine-website auf dem Server git.server.example mit dem Zielverzeichnis /var/www/sources/meine-website/ auf dem Webserver sähe das dann so aus:

$ git archive --format=tar --remote=ssh://git@git.server.example/websites/meine-website test | tar -C /var/www/sources/test.meine-website.example/ -xf -
$ cd /var/www/sources/test.meine-website.example/
$ nanoc

nanoc hat dann als output_dir bspw. /var/www/html/test.meine-website.example/ konfiguriert, was zugleich das DocumentRoot für den virtual host http://test.meine-website.example/ ist.

Will ich später die gesammelten Änderungen aus der Testinstanz auf die Echtinstanz übernehmen, geht das ebenfalls ganz einfach: ich bringe sie in den master-zweig meines Repositorys und veröffentliche diesen: git checkout master; git merge test; git push; git checkout test

Der post-receive-Hook wird das Deployment-Script mit anderen Parametern aufrufen, so dass nicht der test-Zweig, sondern der master-Zweig ausgecheckt und nicht nach /var/www/sources/test.meine-website.example/, sondern nach /var/www/sources/www.meine-website.example/ kopiert wird. Und das ist dementsprechend das DocumentRoot für http://www.meine-website.example/.

Die nanoc-Ausgaben gibt das Deployment-Script aus, so dass der Git-Server sie an den Git-Client übermittelt; sollte nanoc die Compilation also mit einer Fehlermeldung abbrechen, ist das erkennbar und ermöglicht ein manuelles Eingreifen. Ansonsten sind manuelle Eingriffe nur noch erforderlich, wenn eine bereits deployte Datei gelöscht werden muss; es liegt in der Natur der Sache, dass der gewählte Weg über git archive neue und geänderte Dateien (und Verzeichnisse) anlegt, alte Dateien aber nicht löscht.

Conclusio

Viele Wege führen nach Rom; dies ist meiner.

Er lässt sich fraglos vereinfachen; ein Hemmschuh ist insbesondere die Entwicklung unter Windows, die den Workflow erschwert.

Kommentare und Kritik nehme ich gerne entgegen, ebenso wie andere Wege zum selben Ziel.

Tips und Tricks für den Umgang mit git

nospam@example.com (Thomas Hochstein) — Wed, 12 Jan 2011 16:30:00 +0000

Bei meiner Arbeit mit git stehe ich immer wieder vor der Frage, ob man dieses oder jenes damit nicht einfach machen können müßte. Meistens lautet die Antwort auf diese Frage "ja", aber teilweise muß man schon etwas googeln, um diese Antwort zu finden. Daher möchte ich ab und an kleine ergoogelte Wissensschnippsel mit der Leserschaft teilen; vielleicht steht ja noch einmal jemand anderes vor demelben Problem (und überdies sind deutschsprachige Informationen zu git nicht so wirklich umfänglich vorhanden).

Git über SSH und mehrere SSH-Keys pro Host

Mehr eine allgemeine SSH-Frage, aber da sie sich mir im Zusammenhang mit git gestellt hat …

Ein beliebter Zugriffsweg auf Git-Repositories ist der über SSH, insbesondere, wenn es auch um einen schreibenden Zugang geht und man diesen authentifizieren will. Zu diesem Zweck kann man sich den passenden SSH-Schlüssel für den Zugriff auf das Git-Repository über die SSH-Konfiguration definieren, bspw. durch einen Eintrag in ~/.ssh/config wie den folgenden:

Host git.example.org
Port 2022
IdentityFile ~/.ssh/gitkey

SSH-Zugriffe auf den Server "git.example.org" erfolgen also auf Port 2022 (statt 22) und unter Verwendung des Schlüssels "gitkey". Der Git-Zugriff via SSH berücksichtigt diese Einstellungen dann automatisch.

Was aber tun, wenn man von demselben Client mit mehreren verschiedenen SSH-Schlüsseln auf denselben Server zugreifen muß, wie es insbesondere bei der Verwendung von Tools wie gitosis auf der Serverseite vorkommen kann? Dieselbe Frage stellt sich natürlich, wenn man sich neben dem Zugriff auf ein Git-Repository auch ganz normal per SSH auf dem Server einloggen können will. Auf die obige Art und Weise läßt sich nur ein Key für den Zugriff auf "git.example.org" vordefinieren - und will man wirklich immer einen abweichenden Schlüssel per Option angeben? Eine Lösung wäre die Vergabe von weiteren CNAMEs im DNS für git.example.org, aber das skaliert auf die Dauer auch nicht.

Die einfachste Lösung dafür bieten Aliase direkt in der SSH-Konfiguration, wie das Git-Wiki empfiehlt:

Host private.example.com
    User myname
    Hostname git.example.com
    IdentityFile ~/.ssh/private-identity
Host public.example.com
    User groupname
    Hostname git.example.com
    IdentityFile ~/.ssh/public-identity

Auf diese Art und Weise kann man denselben Server mit zwei verschiedenen Konfigurationen ansprechen.

Übernahme einer einzelnen Datei aus einem anderen Branch

Alle Änderungen aus einem anderen Entwicklungszweig zu übernehmen ist einfach und geht per merge; nur bestimmte Änderungen (commits) zu übernehmen funktioniert via cherry-pick. (Warum auch immer das Rosinenpicken der Deutschen dem Angelsachsen ein Picken nach Kirschen ist …) Aber wie kann man eine bestimmte Datei - also alle Änderungen, aber nur die in einer bestimmten Datei - aus einem anderen Branch übernehmen?

Zu dieser Frage hat Jason Rudolph die passende Antwort: das geht mit git-checkout, und zwar in der Form git checkout $branch $path. Nehmen wir an, ich möchte die Fassung der Datei "README" aus dem Branch "test" in meinen Branch "master" übernehmen, aber eben nur diese Datei in genau dem Zustand, den sie im "test"-Branch hat. Das geht dann folgendermaßen:

git checkout master
git checkout test README
git commit -m 'Imported README from test branch'

Genauso funktioniert das natürlich mit mehreren Dateien:

git checkout test README doc/explanation.txt doc/TODO

Voilà. Soviel für heute.

Mantis: Git-Integration - ein steiniger Weg

nospam@example.com (Thomas Hochstein) — Sat, 15 May 2010 08:46:00 +0000

Sehr praktisch ist es bei einem Bugtracker, wenn er mit dem verwendeten Versions-/Sourcecode-Verwaltungssystem (SCM-System, source code management) interagieren kann, Änderungen im Code, die - laut Kommentar (Commit-Message) - einen bestimmten Fehler beheben, also direkt auch dazu führen, daß der entsprechende Fehlerbericht (Bugreport) als erledigt gekennzeichnet wird. Man kennt dieses Verhalten - bspw. - vom Debian-Bugtracker.

Grundsätzlich ist das auch schon immer mit Mantis möglich; allerdings war die bisher vorhandene Unterstützung rudimentär und primär auf SVN abgestellt; sie wurde auch in der aktuellen Entwicklungsversion 1.3 entfernt. Seit Anfang 2009 gibt es nämlich von einem der Mantis-Entwickler, John Reese, ein Plugin namens Source Control Integration, das sich beim Bugtracker für Mantis selbst bereits seit Monaten im Echtbetrieb bewährt hat. Es liefert ein Framework für die Anbindung beliebiger Versionsverwaltungssysteme, und fertige Plugins für die Anbindung an git via GitHub oder GitWeb und an SVN via SourceForge oder WebSVN sind direkt dabei.

Leider ist auch hier die Dokumentation der schwache Punkt. Eine solche fehlt nämlich bisher völlig; einen Einstieg liefert einzig ein Blogbeitrag vom 07.01.2009, der die Vorgehensweise beschreibt. Weitere Blogbeiträge (von März und Oktober 2009) umreißen die technischen Grundlagen und beschreiben den Einsatz für Subversion, helfen aber ansonsten auch nicht wirklich weiter.

Ich habe mir die Vorgehensweise bisher folgendermaßen zusammengereimt:

Download der nötigen Plugins (Meta Programming, Source Control Integration und - in meinem Fall - Gitweb Integration). Fertige Lösungen scheint es dafür nicht zu geben, die Plugins sind offenbar aus dem Git-Repository des Entwicklers auszuchecken (dabei finden sich die vorgenannten Plugins für die Anbindung an git und SVN im selben Repository wie Source Control Integration). Danach gehören die entsprechenden Verzeichnisse ins Mantis-Plugin-Verzeichnis, das man in Mantis auch unter dem Punkt [Manage] (http://host.domain.example/mantis/manage_overview_page.php) angezeigt findet.
UPDATE vom 30.10.2012: Das Git-Repository des Entwicklers ist offenbar nicht mehr aktuell bzw. liegt jetzt bei Github: Source Control Integration
Das Plugin Meta Programming sollte bei Mantis 1.2.x bereits mit dabei sein und muss daher nicht mehr installiert werden..

Anschließend sind die Plugins - in der richtigen Reihenfolge - unter [Manage Plugins] (http://host.domain.example/mantis/manage_plugin_page.php) zu installieren.

Danach kann das Plugin, wie im genannten Blogbeitrag beschrieben, konfiguriert, ein Repository definiert und dieses dann eingelesen werden.

Letzteres hat bei mir auf Anhieb zu einer eleganten Fehlermeldung geführt:

APPLICATION ERROR #401

Database query failed. Error received from database was #1048: Column ‘author’ cannot be null for the query: INSERT INTO mantis_plugin_Source_changeset_table ( repo_id, revision, parent, branch, user_id,timestamp, author, message, info, ported, author_email, committer, committer_email, committer_id) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? ).

Deren Ursache liegt darin, daß das Plugin die Ausgabe von GitWeb nicht richtig parsen kann. In meinem Fall war der Übeltäter die in GitWeb aktivierte Avatar-Funktion; einen Patch dafür findet man im Bugtracker des Entwicklers.

UPDATE: Auch mit der GitWeb-Version 1.7.1 gibt es Schwierigkeiten, namentlich, wenn und weil jetzt die Möglichkeit der Suche nach Commits des jeweiligen Autors aktiviert ist. Wer einen Patch dazu sucht, findet diesen an der bereits genannten Stelle.

UPDATE vom 30.10.2012: Der Bugtracker des Entwicklers ist auf eine statische Archiv-Version zurückgesetzt und enthält den Patch daher nicht mehr. Er findet sich dafür hier in den Kommentaren. - Die aktuelle Version im Github-Repository des Entwicklers scheint ihn aber im wesentlichen bereits eingebaut zu haben.

Danach funktionierte der Import aber und lief wie am Schnürchen.

Jetzt möchte man das nur noch automatisieren; die entsprechende Angabe im genannten Blogbeitrag …

For Gitweb, SourceForge, or WebSVN integration, find your repository’s ID, and setup a cronjob (or something equivalent) to run "curl http://yoururl.xyz/mantisbt/plugin.php?page=Source/repo_import_latest&id=XX"

… ist aber leider unzutreffend, denn die entsprechende Seite kann nur durch einen - eingeloggten - Admin aufgerufen werden. Korrekt ist vielmehr der Aufruf von http://host.domain.example/mantis/plugin.php?page=Source/import&id=XX; das ist die vorgesehene API dafür. Der entsprechende Aufruf kann per Cronjob, aber sicherlich auch als Post-Update-Hook in git verwirklicht werden: curl 'http://host.domain.example/mantis/plugin.php?page=Source/import&id=XX' > /dev/null

Über weitere Erfahrungsberichte zu diesem Thema würde ich mich übrigens freuen.

msysgit mit PLink, Pageant und SSH

nospam@example.com (Thomas Hochstein) — Mon, 12 Apr 2010 21:02:00 +0000

Dieser Text ist überholt und nicht mehr aktuell. Eine aktuelle Anleitung für die Installation von git for Windows, dem Nachfolger von msysgit, zusammen mit plink aus dem Putty-Paket findet sich auf meinen Webseiten.

Systemeigenschaften -> Erweitert

Was mich bei meiner Nutzung von git unter Windows noch etwas störte war vor allem, daß ich für den Zugriff auf externe Repositories bisher auf TortoiseGit angewiesen war, weil Git on Windows (msysgit) nicht recht zur Kommunikation über SSH bereit war; angeblich wurde nie der passende Schlüssel gefunden, obwohl eigentlich PLink und Pageant aus dem Putty-Paket installiert waren und mit TortoiseGit ihre Arbeit auch prima taten. Die Google-Recherche führte mich dann allerdings zu einem passenden Beitrag, und nach einigem ausprobieren kann ich bestätigen, daß die dort genannte Lösung funktioniert:

Git on Windows (msysgit) installieren
Putty installieren (soweit erforderlich)
Pageant konfigurieren (soweit war ich schon)
Umgebungsvariable GIT_SSH auf PLink setzen
GitBash und/oder GitGui neu starten (!)

Danach funktionierte die Sache bei mir wunderbar.

Umgebungsvariablen

Die Umgebungsvariable GIT_SSH setzt man unter Windows XP in den "Systemeigenschaften" (Rechtsklick auf "Arbeitsplatz" oder "My Computer" und dann "Eigenschaften") auf der Registerkarte "Erweitert" unter dem Button "Umgebungsvariablen" unter "Systemvariablen". Ein beherzter Klick auf "Neu" fördert ein Eingabefeld zutage, in dem man nunmehr "GIT_SSH" und den kompletten Pfad zur Datei "PLink.exe" - bspw. "C:\Programme\PuTTY\plink.exe" - eingibt. Neustart von msysgit nicht vergessen!

Voilà! Bei mir funktionierte die SSH-Übertragung dann ohne jedes Problem.

Sprachauswahl bei Git on Windows (msysgit)

nospam@example.com (Thomas Hochstein) — Fri, 09 Apr 2010 05:21:00 +0000

Wie ich bereits im Februar beschrieben habe, benutze ich unter Windows msysgit bzw. "Git on Windows". Die GUI-Variante ermöglicht die meisten denkbaren Aktionen in sehr bequemer Weise durchzuführen; sie krankt allerdings - aus meiner Sicht - arg an ihrer Übersetzung, die sämtliche Menüeinträge und damit natürlich auch Fachbegriffe umfaßt und manchmal zu Rätselraten führt, was genau gemeint sein mag. "Zweig" ist ja noch klar, "Zusammenführen" für "Merge" auch, aber das "Version" für "Commit" steht erschließt sich nicht sofort. Und Menüpunkte unterhalb von "Zweig" wie "Erstellen", "Umstellen" oder "Zurücksetzen" sind auch alles andere als klar - "Erstellen" ist ohne Frage "Create", aber "Umstellen"? Gut, man kann vielleicht noch darauf kommen, daß das für "Checkout / Switch" steht … aber bedeutet "Zurücksetzen" jetzt "Reset" oder "Rebase"? Usw. usf. … Da wäre doch eine englische Bedienungsoberfläche eine tolle Sache, da weiß man wenigstens, welche Funktion jeweils gemeint ist, und kann die dann ggf. nachschlagen.

Es scheint leider derzeit noch keine Möglichkeit zur manuellen Auswahl einer Sprache zu geben, auch nicht durch Setzen von Environment-Variablen (zumindest hat Google sich insoweit ausgeschwiegen); es wird automatisch auf die Systemsprache abgehoben. Eine Lösung gibt es dennoch - wenn man dafür sorgt, daß die Programme ihre deutschen Sprachdateien nicht mehr finden, fallen sie auf den englischen Default zurück, und das ist ja genau das, was wir wollen.

Die Sprachdateien liegen in %ProgramFiles%\Git\share\git-gui\lib\msgs bzw. %ProgramFiles%\Git\share\gitk\lib\msgs; dort muß jeweils nur die Datei "de.msg" entfernt - oder umbenannt - werden, und alles wird gut (bzw. in diesem Fall englischsprachig). Nach Updates ist dieser Schritt natürlich erneut erforderlich.

git archive

nospam@example.com (Thomas Hochstein) — Sat, 27 Feb 2010 17:52:00 +0000

Ein weiteres nettes Feature von git sind die Möglichkeiten, die git archive bietet. So läßt sich der Inhalt eines git-Repositories leicht in ein tar-File packen, bspw. für ein Release.

Voraussetzung dafür ist beim Zugriff über git-daemon, daß der entsprechende Service aktiviert ist; für das Debian-Paket bedeutet das die Erweiterung des Aufrufs in /etc/sv/git-daemon/run um den Parameter "--enable=upload-archive".

Dann aber kann mit einem Aufruf wie

git archive --format=tar --remote=git://git.domain.example/$REPO.git --prefix=$PREFIX/ $TAG | gzip > $REPO.tar.gz

aus dem Repository $REPO.git dessen Inhalt bei Commit (oder an der Spitze des Branches, oder an dem Tag) $TAG in eine .tar.gz-Datei gepackt werden, wobei die Dateien ein $PREFIX vorangestellt bekommen.

git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-2.17/ 2.17 | gzip > myprog-2.17.tar.gz

erzeugt also aus dem Repository myprog.git in der mit "2.17" getaggten Version eine Datei myprog-2.17.tar.gz, die alle im Repository enthaltenen Dateien mit dem Verzeichnis-Präfix "myprog-2.17/" enthält.

Das ganze läßt sich noch etwas aufpeppen, wenn man bspw. bestimmte Dateien (.gitignore, ...) aus dem Repository nicht im Tarball haben möchte und/oder noch andere Änderungen vornehmen will, wie bspw. die Erzeugung eines README aus der eingebetteten POD-Dokumentation:

#! /bin/bash
# do a release of myprog
# $1: version number
# make tempdir
tempdir=`mktemp -td myprog-XXXXX`
git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-$1/ $1 | (cd $tempdir && tar xf -)
cd $tempdir/myprog-$1/
pod2text -l myprog.pl README
rm .gitignore
cd $tempdir
tar -czf /var/www/myprog/download/myprog-$1.tar.gz myprog-$1/
rm -r $tempdir

Und schließlich kann man auf diese Weise auch nur eine einzelne Datei aus dem Repository extrahieren:

git archive --format=tar --remote=git://git.domain.example/repository.git master beispiel.txt | tar xf -

extrahiert die Datei beispiel.txt aus der Spitze des Branches master des Repositorys repository.git.

Ich finde das alles ausgesprochen praktisch.

Was mir an git gefällt

nospam@example.com (Thomas Hochstein) — Wed, 24 Feb 2010 21:33:00 +0000

Nachdem ich mich jetzt bereits einige Wochen mit git auseinandersetze, ist es vielleicht einmal Zeit für ein Fazit. Ich mag mir kein fachkundiges Urteil über git erlauben; dazu fehlt mir der wirkliche Vergleich mit anderen Versionsverwaltungssystemen und die Erfahrung mit (gemeinsamer) Softwareentwicklung, und letztlich auch der wirklich "fortgeschrittene" Umgang mit git. Ich denke aber, daß ich - obschon ich git bisher "solo" nutze, also zu seinen Stärken und Schwächen bei der Zusammenarbeit selbst nichts sagen kann - durchaus einige Punkte benennen kann, die mir an git gut gefallen.

Da wäre auf den ersten Blick bereits die Verzeichnisstruktur: wo SVN mich mit trunk, tags und branches verwirrt, gibt es bei git ein Verzeichnis .git, und das war’s.

Auch zunächst eher eine Äußerlichkeit, aber sehr bequem, ist die Möglichkeit, mit git "offline" zu arbeiten. Bei git wird die Arbeitskopie nicht aus einem zentralen Repository ausgecheckt; vielmehr wird das zentrale Repository im Normalfall komplett kopiert und steht mir dann auch offline mit der gesamten Versionsgeschichte zur Verfügung. Das ermöglicht es überdies, neben einem "offiziellen" Repository - das im Netz steht - beliebig viele "inoffizielle" Repositories vorzuhalten. Änderungen kann ich so zunächst nur in meiner Kopie des Repositories vornehmen (und sie ggf. auf andere eigene Rechner spiegeln und auch mit anderen Entwicklern austauschen) und sie erst dann veröffentlichen, wenn ich sie für veröffentlichungsreif halte. So kann ich bspw. immer nur bestimmte Zweige meines Entwicklungsrepositories in ein öffentliches Repository übertragen und andere, an denen ich noch bastele, nicht veröffentlichen.

Das problemlose Anlegen von Kopien (Zweigen, branches) ist aus meiner Sicht ein weiterer Vorteil; ein Entwicklungszweig (branch) ist trivial und schnell angelegt und ebenso schnell auch wieder entfernt. Das ermöglich ein schmerzloses Ausprobieren von Änderungen jeder Art; man kann für jede Idee einfach einmal schnell einen neuen Zweig anlegen, sie ausprobieren und dann ggf. verwerfen oder auf Eis legen kann - oder in die "eigentliche" Entwicklungslinie übernehmen. Auch lassen sich so verschiedene Ideen einfach in verschiedenen Branches entwickeln und dann jederzeit direkt in den Hauptzweig übernehmen, oder man kann sie erst noch etwas "köcheln" lassen; daneben können verschiedene Entwicklungsstränge bspw. für eine geplante neue Version und für Bugfixes älterer Versionen nebeneinander laufen.

Ergänzend dazu fasziniert mich die Möglichkeit, meine Commits nachträglich nachzubessern und neu zu sortieren. Die Möglichkeit fraktionierter Commits hatte ich bereits angesprochen; außerdem kann ich jederzeit per interaktivem rebase einzelne Commits zusammenfassen. Oder ich setze einfach nur den Index auf eine alte Version zurück, so daß ich dann die Änderungen in der aktuellen Arbeitskopie gegenüber diesem alten Zustand neu einchecken kann, auch in einzelnen Teilen. In diese Reihe gehört auch die Möglichkeit, mein lokales Repository - oder einzelne Entwicklungszweige darin - immer wieder neu auf den aktuellen Stand des "offiziellen" Repositories - oder des Hauptentwicklungszweiges - aufsetzen zu lassen. All das ermöglicht es - auch zusammen mit dem leichten Anlegen neuer branches - auf der einen Seite, nahezu beliebig "herumzuspielen" und dabei dem Motto "Commit early, commit often" zu folgen, auf der anderern Seite aber später, wenn das Feature gereift ist, eine logische Abfolge von einzelnen Patches zu committen, die die ganzen Sackgassen und Fehlversuche auslässt und möglichst einfach nachzuvollziehen ist.

Um ein paar Beispiele für die Vorteile dieser Arbeitsweise zu nennen:

Ich kann zum Beispiel während der laufenden Entwicklung jeden Entwicklungszweig (branch) immer wieder periodisch neu auf den aktuellen Stand des Hauptzweigs (master branch) aufsetzen lassen (rebase); wenn die Entwicklung eines bestimmten Features dann reif ist, kann ich sie in den Hauptzweig übernehmen und habe dann nur genau diese Änderungen in der Versionsverwaltung stehen, und zwar ausgehend vom aktuellen Stand des Hauptzweigs. Statt rebase könnte ich natürlich auch merge benutzen, dann habe ich aber eine Unzahl von für das Verständnis überzähligen Commits in der Versionsgeschichte stehen.

Nehmen wir an, ich arbeite an einem bestimmten Feature und committe Änderungen oft und zeitnah (um sie ggf. wieder zurücknehmen zu können, wenn sich der Weg als Irrweg erweist). Irgendwann bin ich dann mit dem Sachstand zufrieden und halte das Feature für reif genug für das nächste Release. Jetzt könnte ich den Entwicklungszweig einfach in den Hauptzweig mergen; dann steht aber das gesamte hin und her in der Versionsgeschichte, was sie auf die Dauer eher unübersichtlich macht. Ich kann aber auch durch interaktives rebase und/oder durch ein reset zunächst den Entwicklungszweig neu zusammenstellen und entscheiden, in wie viele Commits in welcher Reihenfolge ich meine diversen Änderungen aufgeteilt haben möchte. Ich schreibe quasi rückblickend die Versionsgeschichte nachvollziehbar und ordentlich neu und merge dann eine logische Abfolge von einzelnen Schritten in den Hauptzweig. Das sieht nicht nur eleganter aus, es ist auch leichter verständlich.

Andersherum kann ich vorgenommene Änderungen auch sukzessive in mehreren Commits in die Versionsverwaltung schreiben. Angenommen, ich habe eine Website in einem git-Repository liegen und nehme umfangreiche Änderungen und Ergänzungen an einer Webseite vor. Bei dieser Gelegenheit fallen mir auch einige Rechtschreibfehler im bereits vorhandenen Text auf. Jetzt könnte ich entweder erst meine Änderungen und Ergänzungen abschließen, sie committen und dann in einem zweiten Schritt die Rechtschreibfehler beheben (wenn ich das nicht bis dahin vergessen habe). Oder ich behebe die Rechtschreibfehler nebenbei mit und committe sie zusammen mit den Änderungen; aber dann wird die commit message ein Gemischtwarenladen und ich kann v.a. meine Änderungen nicht isoliert reverten. Mit git kann ich die an der Arbeitskopie vorgenommenen Veränderungen stückchenweise committen: bspw. erst isoliert die Rechtschreibfehler, und dann - getrennt davon - die zeitgleich vorgenommenen Änderungen und Ergänzungen. Danach habe ich zwei getrennte Commits, die zwei logisch verschiedene Vorgänge getrennt wiedergeben und die auch getrennt zurückgenommen werden können.

Ich halte das - mit Vorsicht genutzt - für ein sehr interessantes Arbeitswerkzeug. "Mit Vorsicht genutzt" deshalb, weil es natürlich fatal ist, die Versionsgeschichte bereits veröffentlichter branches umzuschreiben … deshalb sollte man entweder nur die Entwicklungszweige öffentlich zugänglich machen, die man auch unverändert so stehenlassen möchte, oder wenigstens klar kommunizieren, welche Entwicklungszweige "work in progress" sind und keinesfalls für eigene Entwicklungszwecke gepullt werden sollen.

Git unter Windows

nospam@example.com (Thomas Hochstein) — Sun, 21 Feb 2010 16:21:00 +0000

Dieser Text ist überholt und nicht mehr aktuell. Ich nutze bereits seit Mitte 2010 TortoiseGit nicht mehr. Eine Anleitung für die Installation von git for Windows, dem Nachfolger von msysgit, zusammen mit plink aus dem Putty-Paket findet sich auf meinen Webseiten.

Bereits Anfang Januar hatte ich von Git berichtet und danach geschildert, wie man Git-Repositories mit gitosis und gitweb, offen wie auch paßwortgeschützt, aufsetzen kann. Seitdem habe ich eine ganze Reihe Projekte in Git-Repositories eingecheckt und gewöhne mich immer mehr an die Arbeit mit Git, zumeist allerdings unter Windows (weil ich auf Laptop wie auch Desktoprechnern unter Windows arbeite).

Dazu verwende ich TortoiseGit, eine Portierung des recht bekannten (und gelobten) TortoiseSVN, und zugleich Git on Windows (msysgit), das ohnehin als Voraussetzung für die Verwendung von TortoiseGit heruntergeladen werden muß. Beide ergänzen sich, wie ich finde, recht gut. TortoiseGit ermöglicht eine einfache Definition des Remote Repository und elegante Lösungen für die Darstellung von Diffs und Merges, ganz zu schweigen von der grafischen Darstellung des Dateistatus im Explorer; die Git-Bash und GitTk aus msysgit hingegen sind m.E. optimal für Branching und (inkrementielle) Commits sowie für die Darstellung der History. Störend allenfalls, daß die Tools teilweise - trotz der einigermaßen großzügigen Ausstattung an Rechenleistung und RAM - arg langsam wirken. Insgesamt aber, wie ich finde, eine sehr bequeme Lösung.

INN-Funktionsweise: Steuernachrichten und Filter

nospam@example.com (Thomas Hochstein) — Sun, 17 Jan 2010 16:06:00 +0000

Der Urlaub neigt sich endgültig seinem Ende zu, und - leider - ist die Todo-Liste, insbesondere hinsichtlich angedachter größerer Projekte, die man abends oder am Wochenende (zumindest bei meiner derzeitigen zeitlichen Belastung) nicht sinnvoll angehen kann, nicht merklich geschrumpft. Stattdessen habe ich mich (ungeplant) auf die Datensammlung zu Usenet-Hierarchien und danach dann auf den Umgang mit git konzentriert und am Ende eine ganze Reihe Dinge umgesetzt, die auf der ToDo-Liste eigentlich gar nicht vorkamen.

Nachdem Newsserver in den letzten Wochen eine so große Rolle gespielt haben ist es jetzt zum Abschluss nur recht und billig, wenn ich (nach mehrjähriger Pause) meine Seite zur Funktionsweise des INN endlich um die noch fehlenden Teile ergänze; umso mehr, als ich meine Webseiten mittlerweile in ein git-Repository eingecheckt habe und daher auch den Umgang damit üben kann, insbesondere, was fraktionierte Commits betrifft. Das ist eine sehr nette Sache: man nimmt eine Reihe unterschiedlicher Änderungen vor, die nichts miteinander zu tun haben - bspw. eine Ergänzung der INN-Beschreibung auf der einen Seite und Richtigstellungen/Tippfehlerkorrekturen, über die man zufällig stolpert, auf der anderen -, und kann diese Änderungen aber selektiv committen, bspw. zuerst nur die Ergänzungen, dann die Änderungen, dann die Rechtschreibfehler. Das macht die Commits übersichtlicher und ggf. auch leichter zu reverten, weil man nur logisch zusammengehörendes auch zusammen committet, ohne daß man beim Editieren darauf achten müßte.

Ich kann also hiermit verkünden, daß ich die Abschnitte über Steuernachrichten (control.ctl), Filter und Reader-Authentifizierung sowie eine recht umfangreiche Linksammlung ergänzt habe. Fehlen nur noch Erläuterungen zum Expire, aber das muß ich erst einmal selbst verstehen.

Update 2010-01-26: Inzwischen steht auch die Erläuterung zum Expire online. Die Seite ist damit - endlich! - fast fünf Jahre nach ihrer ersten Erstellung komplettiert. Ich hoffe, sie hilft dem einen oder anderen (vermißt wurden die fehlenden Teile allerdings offensichtlich nicht, wenn man nach dem erhaltenen Feedback über die Jahre geht …).