Vor einigen Wochen habe ich auf dem Blog von Vincent Driessen einen Artikel über ein Git Branching Modell gelesen.

Next to the main branches master and develop, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

The different types of branches we may use are:

• Feature branches
• Release branches
• Hotfix branches

Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. We will walk through them in a minute.

Die Grafik verdeutlicht das Vorgehen.

Nachdem ich dieses Vorgehen verinnerlicht und für ein kleines Projekt angewandt habe, erlaube ich mir das Fazit: es funktioniert :). Ich würde dieses Modell als nächstes in einem Projekt einsetzen, in dem Subversion zum Einsatz kommt. Weitere Schwierigkeiten sehe ich da vielleicht mit Hudson-CI und Maven. Ich werde berichten.

Warum zum Teufel macht man auch 1400+ Bilder… naja, irgendwann lerne ich das auch noch… Vielleicht sollte ich noch mal mit einer Filmkamera starten, die ist dann wenigstens Vollformat.

Getting in the habit of creating quality commit messages makes using and collaborating with Git a lot easier. As a general rule, your messages should start with a single line that’s no more than about 50 characters and that describes the changeset concisely, followed by a blank line, followed by a more detailed explanation. The Git project requires that the more detailed explanation include your motivation for the change and contrast its implementation with previous behavior — this is a good guideline to follow. It’s also a good idea to use the imperative present tense in these messages. In other words, use commands. Instead of “I added tests for” or “Adding tests for,” use “Add tests for.” Here is a template originally written by Tim Pope at tpope.net:

Short (50 chars or less) summary of changes

More detailed explanatory text, if necessary. Wrap it to about 72

characters or so. In some contexts, the first line is treated as the

subject of an email and the rest of the text as the body. The blank

line separating the summary from the body is critical (unless you omit

the body entirely); tools like rebase can get confused if you run the

two together.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Typically a hyphen or asterisk is used for the bullet, preceded by a

single space, with blank lines in between, but conventions vary here

If all your commit messages look like this, things will be a lot easier for you and the developers you work with. The Git project has well-formatted commit messages — I encourage you to run git log –no-merges there to see what a nicely formatted project-commit history looks like.

In einer Zeit von häufigen Commits (Continuous Integration) ist es verständlicher weise aufwändig jede kleine Änderung (Typos, UI alignements, Code Formatierungen, etc) zu kommentieren. Meine Empfehlung wann ein Entwickler eine ausführliche Message schreiben sollte:

• Wenn sich ein Klassenname ändert oder eine Klasse verschoben wird
• Wenn sich die Signatur einer Methode ändert
• Wenn neue Bibliotheken verwendet werden

Diese Liste könnte sicherlich noch um einige Punkte ergänzt werden, aber prinzipiell geht es um Änderungen, die die Struktur des Codes oder des Projekts verändern, quasi Refactorings.

Hier erstmal noch ein paar Testbilder, links immer mit Polfilter in unterschiedlicher Drehstellung.

Zwei Impressionen vom heutigen MTB Trip zur Löwenburg im Siebengebirge. Leider wurde nichts aus dem geplanten Trip in den Bikepark Boppard. Der Regen sah schon übel aus. Naja, wird nachgeholt. Photos vom iPhone, daher die mäßige Quali.

“Es kann nicht sein, dass Fotografen, die in die europäische Kulturhauptstadt Region reisten, etwa, wie am vergangenen Wochenende für das Still-Leben auf der A40, oder wie am kommenden Wochenende zur Loveparade in Duisburg, Angst haben müssen, auch die Zeche Zollverein zu fotografieren, da sonst Abmahnungen auf sie zukommen könnten”, betonte die stellvertretende DJV Bundesvorsitzende Ulrike Kaiser. “Für uns ist klar: Es gilt auch im Fall der Stiftung Zollverein die Panoramafreiheit für Fotografen. Die Stiftung Zollverein kann diese nicht missachten”, so Kaiser. Zudem sei das die schlechteste Öffentlichkeitsarbeit für den Standort Ruhrgebiet, die man sich vorstellen kann.

Dazu kann ich nur sagen, Full Ack! Ich habe mich auch schon mal gefragt was ich alles so im öffentlichen Raum fotografieren darf und was nicht. Sehr seltsam. Ob ich wohl ärger für die Post-Tower Bilder bekomme?

Weitere Info zur Panoramafreiheit

Kommentar zum neuen Outfit gerne! Ach und noch etwas, wenn jemand ein WordPress Plugin kennt, dass mir Flickr Bilder in einem selbst zu bestimmenden Format in den Blog einfügt: Haben will!

Da lebt man in Bonn und ist Kamerabegeistert, da bleibt es nicht aus den Post Tower zu fotografieren.

Gestern ging es mit ein paar Freunden zum Fotografieren in die Bonner Rheinaue, genauer gesagt den Japanischen Garten. Eigentlich waren wir eher auf Sonnenschein und Blütensuche eingestellt, als dann der Regen einsetze, änderten sich die Motive :) Die Aktion gab dennoch gute Ausbeute.