Patchmanagement mit Git

Eine zentrale Aufgabe in der Softwareentwicklung ist der Umgang mit Änderungen. Das betrifft zum einen die Entwicklung der Quellcodebasis insgesamt, also die “klassische” Versionskontrolle. Zum anderen ist aber auch der Weg dahin wichtig, also die Entwicklung eines Patches. Gerade bei größeren, insbesondere strukturellen, Änderungen kann man leicht den Überblick verlieren. Das gilt umso mehr, wenn sich während der Entwicklung eines Patches die Sourcecodebasis ändert und es somit zu Konflikten kommt, die dann zu beheben sind. Mit diesem Teilaspekt, also dem (lokalen) Patchmanagement, befasst sich dieser Artikel.

Wenn man sich damit begnügt, zusammengehörende Änderungen in einem “großen Klumpen” zu verwalten, eignen sich lokale Branches in Git, einem verteilten Versionskontrollsystem, hierfür sehr gut. Damit hat man auch die Historie der lokalen Änderungen parat und kann sie bei Bedarf wieder hervorholen. Aber größere Änderungen werden schnell unübersichtlich, wenn man sie nicht in handliche Teile aufteilt. So könnte man beispielsweise eine Änderung in 1. das Bereitstellen einer Schnittstelle und 2. Änderungen in darauf aufbauendem Code, die auf diese Schnittstelle zugreifen, aufteilen.

Auch der Übergang von der lokalen Entwicklung in das zentrale Versionskontrollsystem wird dadurch erleichtert. Die ganze lokale Entwicklungshistorie mit allen Irrungen und Wirrungen will man gar nicht auf alle Ewigkeit für alle sichtbar machen. Die Änderung dort aber nur als Ganzes zu sehen, ist aber auch nicht detailliert genug. Zum einen weiß man nicht mehr, welche Änderung (einer bestimmten Zeile beispielsweise) für welchen Teilaspekt zuständig ist. Zum anderen bleibt bei Problemen mit dem neuen Code nur, die Änderung als Ganzes zurückzunehmen. Anders sieht es hingegen aus, wenn man sauber getrennte, auf einander aufbauende, aber jeweils für sich baubare und lauffähige Änderungen hat. Unter Berücksichtigung der Abhängigkeiten kann man diese dann, ggf. auch (teil)automatisiert, wieder zurücknehmen. Auch die Begutachtung (Review) von Quellcodeänderungen wird durch die Strukturierung erleichtert.

Nachdem die Vorteile einer entsprechenden Lösung nun hoffentlich einleuchten, möchte ich zu entsprechenden Werkzeugen kommen. Mercurial Queues setzt auf dem verteilten Versionskontrollsystem Mercurial auf. Dieses finde ich persönlich nicht sonderlich benutzerfreundlich, ich arbeite lieber mit Git. Außerdem hat Mercurial Queues den Nachteil, dass die einzelnen Patches nicht versioniert sind (es ist wohl irgendwie möglich, aber nur sehr umständlich). Bei der Suche nach einer Lösung, die zum einen die Versionierung von Patches erlaubt, und zum anderen gut mit Git integriert ist, bin ich schließlich auf topgit gestoßen. Das Prinzip von topgit ist schnell erklärt: Es arbeitet mit ganz normalen Git-Branches (jeder Teil des Patches ist ein eigener Branch), erfasst aber die Abhängigkeiten zwischen diesen. Wenn man Änderungen im zentralen Sourcecode oder in einem grundlegenden Teil des Patches hat, kann man diese mit einem Befehl schnell durch alle “Ebenen” des Patches durchziehen.

Fazit: topgit ist zwar noch recht jung und nicht vollständig ausgereift (so kann man beispielsweise Abhängigkeiten eines Branches zu einem anderen hinzufügen, nicht aber wieder löschen), die gute Integration mit Git macht das aber wieder wett. Da ganz normale Git-Branches incl. Historie verwendet werden, ist auch das Risiko durch irgendwelche Bugs gering: Zur Not kann man mit den Branches auch mit Git-Bordmitteln noch etwas anfangen. Insofern eine klare Empfehlung, es lohnt sich!

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>