Eine Datei aus der git-Historie ausgraben…

git

Versionskontrollsysteme benutzt man bekanntlich, um die vorgenommenen Änderungen an den Dateien nachvollziehen und bei Bedarf zurückholen zu können. Wenn man das dann tatsächlich mal machen muss, stellt man fest, dass der Weg dahin gar nicht so einfach ist und es diverse unterschiedliche Herangehensweisen dafür gibt.

Bei Github hat man sogar einen Longread für die unterschiedlichen Situationen und Wege dafür verfasst (»How to undo (almost) anything with Git«). Und bei Stack Overflow findet man eine schöne Diskussion mit hervorragend erklärten Wegen (»How to revert a Git repository to a previous commit«).

Als einfachster Weg für den Fall »ich habe an einer Datei vor 47 Commits was geändert, war aber Mist und jetzt brauche ich mal den alten Stand aus genau einer Datei« hat sich in der Praxis die folgende Vorgehensweise bewährt:

Zunächst muss man wissen, in welchen Commits die Datei überhaupt geändert wurde. Das kann man mit git log –follow– herausfinden:

  git log --follow -- app/views/products/_channelproducts_form.html.haml

Das Ergebnis ist eine Liste von Commits, in der die Datei verändert wurde. Der Commit ist der, den wir brauchen:

 commit 2918261…
 Author: Ralf G… <…>
 Date:   Tue Dec 4 14:40:32 2018 +0100
    Umbau der Produktform…

Wenn man jetzt einfach den Commit mit git checkout 2918261 wieder auscheckt, befindet man sich in einem Zustand des »detached HEAD«, man ist also in keiner Branche mehr. Man kann dem zwar mit git checkout master wieder entfliehen. Gerade für Menschen, die das nicht so oft machen, ist die Gefahr groß, durch Änderungen und Checkouts ein kleines Durcheinander zu produzieren.

Der sichere Weg ist das Auschecken des Commits in eine neue Branche:

  git checkout -b alte_produkt_form 2918261

Die Branche alte_produkt_form befindet sich nun auf dem Stand des Commits 2918261. Man kann in dieser in aller Ruhe rummachen, ohne die anderen Branches anzurühren.

Wenn man fertig ist und gefunden hat was man braucht, kann man sich die alte Datei über verschiedene Wege (gute alte Zwischenablage oder Stash) in seinen Master übernehmen und den alten Stand dort als neuen Commit einchecken. Was die Änderung dann im Log deutlich leichter nachvollziehbar macht als ein Löschen des Commits mit anschließendem Rebase.

Das nächste große Ding: JAMstack

ssg jamstack

Alles in der Welt der Webentwicklung braucht einen griffigen Namen. Mit »Ajax« fing das an…

Als in den letzten Jahren statische Seitengeneratoren wie Jekyll immer populärer wurden und man begann (so wie früher mit Wordpress), jede für diese Technologie geeignete und auch eher ungeeignete Aufgabe damit lösen zu wollen, stellte man fest, dass es ganz ohne »Dynamik« halt auch nicht geht. Man verlagerte die dynamischen Komponenten mangels Backend deshalb mit JavaScript ins Frontend. Statische Seiten enthalten JavaScript, das sich von APIs Daten holt und darstellt. Und schon war der »JAMstack« geboren:

»Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.«

Und so denken sich die Leute kühne Konstrukte für ihre Websites aus. Statische Websites werden mit aktuell voll im Trend liegenden javascriptlastigen Generatoren wie Gatsby (das gute alte Jekyll, das meine Blogs allesamt antreibt, ist bei den »Coolen« voll out…) gebacken und aus einem »Headless CMS« wie Contentful mit Inhalten gefüllt. Und das Endergebnis wird bei Hostern wie Netlify abgelegt. Das ist der Fortschritt: Die Abhängigkeit vom eigenen programmierten Backend durch Abhängigkeiten von einem oder mehreren externen Anbietern zu ersetzen…

Wer sich in das Thema JAMstack einlesen möchte, findet bei JAMstack WTF eine schöne bunte Einführung. Und kann staunen, wie schnell es die Webentwicklungs-Community mal wieder geschafft hat, aus der simplen Idee »Wir nehmen einen SSG und backen aus ein paar Dokumenten eine statische Website und werfen diese auf einen Server und freuen uns!« ein kompliziertes Etwas voller externer Abhängigkeiten zu schaffen…

»What‘s in a name?«

miszellen ruby

»What‘s in a name?« Fragten sich schon Romeo und Julia bei Shakespeare. Dieses kleine devblog heißt nil?. Was soll das eigentlich heißen?

nil? ist eine Methode der Programmiersprache Ruby. Sie wird verwendet, um zu testen, ob ein Objekt existiert:

  if blogpost.nil?
    puts "Kein Blogpost"
  else
    puts blogpost.content
  end

Also das, was in anderen Sprachen ein Vergleich mit null ist. In Ruby ist aber bekanntlich alles ein Objekt. So auch nil. Deshalb vergleicht man mit nil? ein Objekt mit dem nil-Objekt. Wer alle Geheimnisse von nil erfahren möchte, sollte folgende Artikel lesen:

nil? ist also einfach im Gebrauch, aber es steckt eine ganze Menge dahinter, wenn man genauer hinschaut. Damit erschien es mir, als ich für das kleine devblog einen Namen aus dem Bereich »was mit Programmieren« suchte, perfekt geeignet. Willkommen bei nil?!