(Hinweis: der Artikel ist sicher leichter zu verstehen, wenn man sich die Grafik auf Vincents Seite daneben legt)

Nachdem ich Gitflow nun einige Zeit in mehreren Projekten verwendet habe, möchte ich noch ein paar Dinge berichten, die mir aufgefallen sind. Zur Erinnerung: Man benutzt mehrere Zweige,1 die nebeneinanderher laufen. Neben develop, auf dem die Entwicklung vorangetrieben wird, gibt es master, der nur veröffentlichte Versionen2 enthält, Feature-Zweige (auf denen größere Neuerungen entwickelt werden; ein Zweig pro Feature), Hotfixes3 und Releases.4

Man kann zwar mehrere Feature-Zweige gleichzeitig offen haben, um einen neuen Hotfix- oder Release-Zweig zu starten, muß der vorhergehende aber abgeschlossen werden. Das war zunächst etwas schwer verdaulich für mich, ist aber letztlich sicher sinnvoll: Releases folgen aufeinander, sie können nicht parallel laufen; eigentlich könnte man auch mit einem einzigen Release-Zweig leben, nur wird dann das Tagging schwieriger. Für Hotfixes gilt das nicht so eindeutig, aber git flow verwendet einen Hotfix-Zweig pro Version, nicht einen pro zu behebenden Bug.

Heute habe ich dann etwas Dummes gemacht: nachdem ich einige Zeit an Feature X gearbeitet hatte, habe ich ein paar Bugs in der Produktionsversion behoben -- ein klassischer Hotfix. Die git flow Tools sorgen dafür, daß diese Fehlerkorrekturen in develop und in den Releases auftauchen -- nur mein Feature-Zweig war weiter verbuggt. Was tun? Ich habe mich dafür entschieden, den Feature-Zweig mittels Rebase an der aktuellen develop-Version zu starten. Das war ein großer Fehler. Durch das Rebase gab es nämlich Diskrepanzen zwischen meinem lokalen Repository und der zentralen Version, die sich nicht leicht (und vor allem nur fehleranfällig) korrigieren ließen. Git flow bemerkt das auch und verweigert an viele Stellen gleich den Dienst. Ich habe es zwar hinbekommen, aber mein Commit-Graph ist ziemlich unübersichtlich geworden.

Lektion gelernt: man kann jederzeit Feature-Zweige nach develop Mergen,5 aber nicht umgekehrt. Die letzten Bugfixes sind bei einer reinen Entwicklerversion oft auch überflüssig; und wenn man sie wirklich braucht, ist wahrscheinlich Cherry-Picking die beste Methode.

Übrigens hat git eine unangenehme Eigenschaft, die mich überhaupt erst in diese missliche Lage gebracht hat: Man kann die Geschichte umschreiben (rewriting history), i.e. es gibt git-Kommandos, die nicht nur neue Vertizes zum Commit-Graphen hinzufügen, sondern bestehende Vertizes löschen oder ändern. Das widerspricht meinen Erwartungen an ein Versionskontrollsystem sehr, es liegt aber wohl im Konzept der verteilten Repositories, und ließe sich nur mit schweren Nachteilen ausschließen.

  1. Branches []
  2. oder zumindest solche, die man veröffentlichen könnte []
  3. schwerere Bugs, die zwischendurch behoben werden müssen []
  4. Feinschliff zur nächsten Version []
  5. ich schrieb ja schon, daß man diese Begriffe nicht sinnvoll übersetzen kann []
Kommentare deaktiviert für Fließigkeiten

von kirjoittaessani


Tags:

20130509-145754.jpg

Kommentare deaktiviert für Mittagessen

von kirjoittaessani


Vor ein paar Tagen habe ich einen Schatz angebrochen, der noch vom letztjährigen Kalender übriggeblieben ist: eine kleine Tafel Schokolade. Sie wiegt nur 30 Gramm, ist in schwarzes Papier gekleidet und hört auf den vielversprechenden Namen Noir Infini.

Das alles machte einen so edlen Eindruck, daß ich es nicht für einen gewöhnlichen Feierabend verschwenden wollte. Jetzt hat sich aber das eine oder andere ruhige Stündchen ergeben, und ich muß sagen: das Warten hat sich gelohnt. Ich versuche gar nicht erst, das näher zu beschreiben, aber sie schmeckt wirklich sehr dunkel und sehr edel.

Übrigens fällt mir gerade auf, daß ich dunkle Schokolade (unabhängig von der Qualität) sehr genau dosieren kann, während ich Milchschokolade kaum zu essen aufhören kann.

Kommentare deaktiviert für Dunkel

von kirjoittaessani


Tags:

Das Versionskontrollsystem git habe ich ja schon gelegentlich erwähnt. Heute ist mir aufgefallen, daß git bei aller Komplexität und Mächtigkeit dadurch, daß sich Repositories so einfach einrichten lassen, auch wunderbar leichtfüßig1 ist. Früher2 habe ich echte Versionskontrolle3 nur für größere Softwareprojekte verwendet, kleinere Projekte habe ich allenfalls mit RCS verwaltet.

Derzeit stecke ich mehr und mehr auch Kleinkram in git: Konfigurationsdateien -- früher mehr schlecht als recht in RCS4 -- lassen sich so wunderbar handhaben. Ganz nebenbei bietet git auch noch eine Art Deployment: ich kann auf meiner Maschine entwickeln und dann einfach auf den Server, den ich eigentlich konfigurieren will, klonen. So bleiben alle Projekte und Projektchen schön übersichtlich beisammen; und dank Gitzilla ist auch für eine sinnvolle Dokumentation gesorgt.
Das einzige, was ich jetzt noch vermisse, ist eine gute und universelle Testumgebung: irgendetwas, das für ein neues Projekt keiner aufwendigen Neukonfiguration bedarf, das aber das Testen von neuen Konfigurationen ermöglicht, bevor sie auf den Produktionsserver geschoben5 werden.

  1. lightweight []
  2. TM []
  3. z.B. CVS []
  4. oder gar nicht verwaltet []
  5. deployt? deployed? []
Kommentare deaktiviert für Hohelied

von kirjoittaessani


Erkenntnis des Tages: Gitflow macht Spaß!

Außerdem fange ich an, ein zweites kürzlich entdecktes Werkzeug regelmäßig zu nutzen: Gitzilla. Das ist -- man ahnt es fast -- eine Git--Bugzilla-Integration. Nach der Installation läuft Gitzilla unsichtbar im Hintergrund. Wenn man nun in einem Git-Commit-Text eine Bugnummer aus dem angeschlossenen Bugzilla erwähnt, dann erscheinen automatisch Informationen zu diesem Commit als Kommentar in dem Bug.
Das ist sehr praktisch, um eine Gesamtdokumentation zu erstellen (statt Bugzilla und Git-Historie nebeneinander her laufen zu lassen)

Wer mag, kann die Bugnummer sogar erzwingen, aber für mich als Einzelkämpfer ist das übertrieben.

Zum Schluß noch ein kleiner Tipp für alle, die es selbst ausprobieren möchten: Gitzilla wird beim Push in ein (zentrales) Repository aktiv, nicht schon beim lokalen Commit. Das steht zwar in der Dokumentation, ich habe mich zunächst aber trotzdem gewundert, als nichts passiert ist. Diese Repositories habe ich mit mit --shared --bare in /home/git auf meiner Maschine angelegt, so sind sie zwar mir zugeordnet, aber trotzdem von meinen eigenen Daten getrennt.

2 Kommentare

von kirjoittaessani


Sam näki ensi kerran ihmisten taistelevan ihmisiä vastaan eikä hän erityisemmin pitänyt näkemästään. Hän oli iloinen ettei hän ollut nähnyt kuolleen kasvoja. Hän mietti, mikähän miehen nimi oli ja mistä hän oli kotoisin.

Aus dem Herrn der Ringe. Dazu geht mir so viel durch den Kopf, daß ich das einfach mal unkommentiert stehen lasse.

Kommentare deaktiviert für Zitat des Tages

von kirjoittaessani


Neulich vor dem Frühstück: der Bär steht in der Küche und pfeffert seinen Schnuller quer durch den Raum. Dann fixiert er ihn mit seinem Blick, wirft seine Hand in einer gebieterischen Geste nach vorn und wiederholt nachdrücklich: 'nulli 'aben! 'nulli 'aben!

Kommentare deaktiviert für Jedi-in-Training

von kirjoittaessani


Eigentlich bin ich kein großer Fan von Biographien, aber heute will ich eine Ausnahme machen und ein paar Worte zu Heisenbergs Der Teil und das Ganze sagen.

Mich hat vor allem interessiert, einen Einblick in die Anfangszeit der Quantenmechanik zu bekommen -- eine Zeit, in der die Tür zu einem weiten Feld gerade aufgestoßen war, in der es (jedenfalls aus heutiger Sicht) viel zu entdecken und zu erforschen gab und in der Geschichte passierte. In dieser Beziehung bin ich natürlich auf meine Kosten gekommen, aber es gibt auch noch andere interessante Episoden in dem Buch. Bevor ich auf diese näher eingehe, will ich noch kurz erwähnen, daß der an den physikalischen Laien gerichtete Text zu wissenschaftlichen Problemen meist nur Andeutungen macht, die gerade ausreichen, die Neugier zu wecken, nicht jedoch, sie zu stillen. Da werde ich mich wohl noch anderweitig informieren müssen.
So war mir zum Beispiel neu, daß die Heisenbergsche Quantenmechanik ursprünglich keine Wellenmechanik war. Die hat Schrödinger erst später eingeführt, und ich wüßte doch zu gerne, wie diese ursprüngliche Formulierung aussah.

Neben der Physik kommen aber, wie gesagt, auch noch andere Themen vor.
Die Beschreibung der Anfangszeit in Göttingen und der Spaziergänge, die Heisenberg dort mit Bohr unternimmt, haben ein bißchen das Gefühl von Heimat geweckt.
Besonders eindrücklich habe ich aber die Zeit des dritten Reiches empfunden -- man redet dabei so oft von der Verfolgung der Juden und anderer Minderheiten, daß der Blick auf den Durchschnittsbürger oft ein bißchen in Vergessenheit gerät: die bedrückende Stimmung in einem totalitären Staat, die Katastrophe, die vielen schon früh als unausweichlich erschien, und die Frage, wie man sich selbst verhalten soll.

Zum Schluß möchte ich noch kurz auf die Art der Darstellung eingehen: Der Autor bestreitet große Teile des Buches durch Gespräche mit Zeitgenossen. Das zieht den Leser in die Geschehnisse mit hinein und sorgt gleichzeitig für einen sehr persönlichen Blick auf die Dinge.

Mir fehlt, wie zu Anfang schon angedeutet, die Erfahrung, diese Form der Darstellung in den Kontext anderer Biographien einzuordnen. Mir hat sie jedoch gut gefallen.

Kommentare deaktiviert für Ein Physikerleben

von kirjoittaessani


Am Anfang seiner Karriere war Professor Mortimer in Kairo: hier hat er das Geheimnis der großen Pyramide1 gelüftet. Die Geschichte ist ursprünglich in zwei Bänden erschienen, die in der deutschen Ausgabe die Nummern eins und zwei tragen. Der eigentliche Beginn der Reihe, das dreibändige Kriegsepos Der Kampf um die Welt, ist erst etliche Jahre später auf deutsch veröffentlicht worden.

Weil dies schon meine dritte Rezension zu Blake und Mortimer ist, will ich mich kurz fassen: Jacobs' Stil begeistert mich nach wie vor, aber den Futurismus der späteren Bände vermisse ich doch. Stattdessen bekommen wir eine kleine Dosis Magie, die meines Erachtens nicht so recht zu den Hauptfiguren paßt. Deshalb mag ich diesmal auch nur vier von fünf Sternen vergeben.

Meine Ausgabe ist in einem Band bei Dargaud erschienen, und sie kann sich durchaus sehen lassen: unter den 128 Seiten finden sich auch zwölf mit Abdrucken der ursprünglichen Veröffentlichung in Form einer Fortsetzungsgeschichte im Tintin; ein Festeinband versteht sich von selbst.

  1. Cheops-Pyramide []
Kommentare deaktiviert für Par Horus, demeure!

von kirjoittaessani


Tags:

Jeder weiß, daß man Dokumente, in denen viel Hirnschmalz in wenig Text verpackt ist1, in einem Revision Control System hält. Ich habe früher CVS für größere Projekte und RCS für Kleinkram2 verwendet.

For ein paar Jahren bin ich dann auf git umgestiegen: Neben dem einfachen Einrichten des Repository3 macht vor allem das leichte und schnelle Branchen Spaß. Zugegeben, git hat auch seine Schwächen, und die Bedienung ist nicht immer einfach4.

Trotzdem überwiegen in meinen Augen zumindest gegenüber SVN und CVS (und natürlich RCS) die Vorteile. Vor ein paar Tagen bin ich zufällig über einen Blog-Eintrag von Vincent Driessen gestolpert, der dem Werkzeug git sozusagen als Überbau noch einen Prozeß oder einen Satz Richtlinien hinzufügt -- Anweisungen, wann man welche Branches erzeugen soll, und wohin sie gemerget werden. Das Modell gefällt mir auf Anhieb recht gut, und weil es dazu auch ein Tool gibt, das das Einhalten des Prozesses stark vereinfacht, werde ich meine Repositories demnächst wohl nach und nach umstellen.

Vincents Modell hat natürlich auch Kritiker, und wer tiefer einsteigen will, sollte sich die Diskussion zu Jeffs Blog-Eintrag durchlesen. Wahrscheinlich am meisten nachgedacht hat Adam Dymitruk. Die Feinheiten seines Modells sind für mich zu dieser späten Stunde definitiv zuviel, aber mir gefällt die Idee, Feature Branches unabhängig zu halten, so daß man jedes Feature jederzeit wieder ausbauen kann.5

Edit: HTML an falscher Stelle
Edit 2: Typo

  1. z.B. Source Code und Konfigurationsdateien []
  2. z.B. Dateien aus /etc []
  3. ja, ich benutze normalerweise auch lieber deutsche Begriffe, aber heute lasse ich das aus gutem Grunde mal sein: wenn man gut eingeführte termini technici übersetzt, versteht am Ende niemand etwas []
  4. manche Kommandos muß ich heute noch immer wieder nachschlagen, checkout -b vergesse ich regelmäßig, wenn ich es nicht oft genug benutze []
  5. jedenfalls bis zum nächsten Release []
2 Kommentare

von kirjoittaessani