<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Git on Michael Hönnig</title><link>https://michael.hoennig.de/de/tags/Git/</link><description>Recent content in Git on Michael Hönnig</description><generator>Hugo -- gohugo.io</generator><language>de-DE</language><copyright>© 2026 Michael Hönnig</copyright><lastBuildDate>Fri, 06 Nov 2026 00:00:00 +0100</lastBuildDate><atom:link href="https://michael.hoennig.de/de/tags/Git/index.xml" rel="self" type="application/rss+xml"/><item><title>Selbsttest: Wie Trunk-based ist mein Workflow?</title><link>https://michael.hoennig.de/de/blog/2026/2026-11-06-self-test-trunk-based-or-branch-based/</link><pubDate>Fri, 06 Nov 2026 00:00:00 +0100</pubDate><guid>https://michael.hoennig.de/de/blog/2026/2026-11-06-self-test-trunk-based-or-branch-based/</guid><description>Meine Vorstellung von Trunk-based Development war naiv: alle Commits direkt auf main, Branches verpönt. Die Recherche zeigte, dass kurzlebige Branches mit Review der Normalfall sind und Release-Branches ausdrücklich vorgesehen. Dieser Selbsttest fragt in zwanzig Fragen nach dem, was im Alltag eines Teams passiert, und bewertet gemäß trunkbaseddevelopment.com, wie weit die Praktiken von Trunk-based Development umgesetzt sind: Branch-Lebensdauer, Integration, Reviews, unfertige Funktionen, CI, lokaler Build, roter Trunk, Code Freeze, Code-Besitz, Story-Größe und Auslieferbarkeit. Das Ergebnis ist ein Umsetzungsgrad mit Hinweisen auf mögliche Engpässe, keine Note; Fragen und Gewichtung sind mein aktueller Recherchestand.</description></item></channel></rss>