Feature-Branch Entwicklung mit Gitblit

Gitblit und insbesondere git ermächtigen deren Benutzer auf einfache Art mit Branches zu arbeiten. Um diese Möglichkeit im Projekt effizient zu nutzen, werden im folgenden die Vorgehensweisen bei der Entwicklung und Änderung von Features bzw. Behebung von Fehlern beschrieben.

git_branchmodel

Es gibt einen Grundsatz der dabei immer befolgt werden sollte:

Alle Änderungen an der Haupt-Codebasis werden nur innerhalb von Feature-Branches durchgeführt, die nach einem erfolgreichen Review in den jeweiligen Entwicklungsbranch überführt werden

Der Grundsatz ist bedingt durch folgende Annahmen:

  • Die Haupt-Codebasis besteht aus einem (oder mehreren) Branches, die als Entwicklungsbranch dienen. Das kann z. B. dann der Fall sein, wenn es einen Branch gibt, in dem die Entwicklung einer neuen Version erfolgt (development-Branch) und einen Branch, in dem die Wartung einer schon ausgelieferten Version erfolgt (maintenance-Branch).
  • Es existiert eine effektive Möglichkeit, Code-Änderungen in einem Feature-Branch einem Review zu unterziehen.
  • Es besteht ein einfacher automatisierter Mechanismus, Code-Änderungen aus einem Feature-Branch in den jeweiligen Entwicklungsbranch zu überführen (mergen).
  • Da git ein dezentrales VCS (Version Control System) ist, muss ein Repository als das “zentrale” Repository angesehen werden, in dem die Überführungen in die Entwicklungsbranches stattfinden.

Das Arbeiten mit Feature-Branches bietet u. a. folgende Vorteile:

  • Entkapselung der Entwicklung von der Haupt-Codebasis
  • Möglichkeit Änderungen zu diskutieren, bevor sie übernommen werden
  • Frühzeitige Fehlererkennung durch Ausführung von Unit-Tests, die geänderte Bereiche abdecken
  • Sicherung des Codes durch regelmäßiges Bereitstellen (pushen) des Feature-Branches in das “zentrale” Repository

Um die o. a. Annahmen umzusetzen und die Vorteile des Arbeitens mit Feature-Branches zu ermöglichen, setzen wir Gitblit ein.

GitBlit

gitblit

Feature-Branches werden in Gitblit über sogenannte Tickets abgebildet:

gitblit_tickets

Tickets werden im jeweiligen Repository über den “Neu”-Button angelegt:

gitblit_newticket

Bei der Anlage von Tickets ist es wichtig anzugeben, mit welcher Haupt-Codebasis (Merge mit) das Ticket später zusammengeführt werden soll. Die anderen Felder dienen im Wesentlichen dazu, die Tickets später besser verwalten zu können.

  • Die Überschrift sollte später der des Commit-Kommentars entsprechen (siehe hier).
  • Im Thema kann eine Verknüpfung zu einem Ticket eines Bug-Tracking-Systems angegeben werden (dazu wird eine .gitbugtraq-Datei auf der Root-Ebene der Haupt-Codebasis benötigt).
  • In Beschreibung kann z. B. die erweiterte Beschreibung des Commit-Kommentars hinterlegt werden. Das ist im Sinne des DRY-Prinzips aber nicht wirklich sinnvoll, außerdem sollte im Normalfall zu jedem Ticket auch ein Thema im Bug-Tracker verknüpft sein, was eine weitere Beschreibung überflüssig macht.
  • In der Feldern Typ, severity und priority kann die Einstufung des Tickets erfolgen.
  • Das Feld Bearbeiter soll normalerweise dafür sorgen, angeben zu können, wer das Ticket bearbeitet. Eine weitere Möglichkeit ist aber auch, das Feld dafür zu nutzen, einen Reviewer für das Ticket anzugeben.
  • Der Meilenstein legt die Version fest, für die das Ticket vorgesehen ist. Über den Tab “Meilensteine” der “Tickets”-Seite können die Versionen verwaltet und nachvollzogen werden, aus welchen Tickets diese bestehen.

Nach der Anlage gibt es verschieden Ansichten innerhalb eines Tickets, die verschiedenen Zwecken dienen:

gitblit_discussion

Über den “Diskussion”-Tab lassen sich zum einen nochmal die o. a. Felder ändern. Zum anderen können hier Kommentare z. B. vom Reviewer angegeben werden. Über den “Abstimmen”-Link kann der Autor des Tickets den Reviewer darüber in Kenntnis setzen, dass das Ticket freigegeben zum Review ist.

gitblit_commits

Im “Commits”-Tab sind initial natürlich noch keine Commits vorhanden, allerdings ist eine Beschreibung hinterlegt, wie diese dort hinein gelangen (siehe hier). Durch ein sogenanntes Patchset werden mehrere Commits zusammengefasst, die per git pushin das Ticket geladen wurden.

gitblit_activity

Der “Aktivität”-Tab zeigt das Log aller Änderungen an dem Ticket.

Exkurs git

Nach dem Anlegen eines Tickets beginnt die Arbeit am Feature mit dem Anlegen eines Branches, der auf der Haupt-Codebasis aufsetzt, die auch im Ticket angegeben ist:

Wenn man sich bereits im Branch der Haupt-Codebasis befindet, kann der start_point (origin/development) auch weggelassen werden.

Sobald der Autor Änderungen “festschreiben” möchte sollte er diese commiten und in das “zentrale” Repository pushen:

Für eine gute Lesbarkeit und später bessere Nachvollziehbarkeit sollte der Commit-Kommentar mit bedacht gewählt werden. Siehe dazu auch http://chris.beams.io/posts/git-commit/.

Wie bereits erwähnt dient das Pushen in das “zentrale” Repository auch dazu, den Code zu sichern, falls das Ticket noch nicht fertig bearbeitet sein sollte. Nicht nur in diesem Fall können nach dem Weiterarbeiten noch weitere Commits in diesem Feature-Branch dazu kommen. Damit in solchen Fällen später ein Review der Änderungen vereinfacht wird, sollte das finale Patchset, welches zum Review freigegeben wird, zu einem Commit zusammengefasst werden:

Dieser Befehl führt ein interaktives Rebase im gleichen Branch durch und bietet in einem Texteditor die Zeilen mit den Commits ausgehend vom HEAD-Commit, angegeben durch Anzahl der Commits an, die verändert werden sollen. Per squash bzw.fixup lassen sich dann bspw. Commits zusammenfassen.

Sollte bei einem Rebase-Vorgang etwas nicht wie vorgesehen laufen und Commits vermeintlich verloren gegangen sein, können diese wieder zurückgeholt werden:

Durch den reflog-Befehl können sämtliche Aktionen, die durch git gemacht werden, nachvollzogen werden. Der reset-Befehl setzt dann den aktuellen Branch wieder auf den Stand, der durch HEAD@{Nummer des Commits} angegeben wird.

Da git ein so mächtiges Werkzeug ist, sind die hier angegebenen Befehle und Optionen nur ein Bruchteil der Möglichkeiten, die angeboten werden. Für nähere Informationen zu den Befehlen hilft immer der Aufruf:

Die Hilfe ist auch Online verfügbar über die offizielle Dokumentation https://git-scm.com/docs.

Gitblit Besonderheiten

Da einige git-Konfigurationseinstellungen ein Arbeiten mit Feature-Branches so wie Gitblit es vorsieht u. U. nicht zulassen, gibt es für das Arbeiten mit Tickets ein paar Besonderheiten, die hier erklärt sind. Die wichtigste ist, dass in Tickets, in die bereits ein Patchset gepusht wurde, für folgende Push-Operationen ein anderer Befehl benutzt werden muss, da der Push sonst abgewiesen werden kann:

Dadurch kann die Remote-Historie des Feature-Branches, der dem Ticket hinterlegt ist, auch ohne eine Force-Push (git push -f) geändert werden.


 

Wenn ein Ticket zum Review freigegeben wird, sollte sich der “Commits”-Tab in einem ähnlichen Zustand, wie auf dem Screenshot angegeben, befinden.

gitblit_review

Wichtig ist hier, dass tatsächlich nur ein Commit existiert. Dieser kann dann über den “Diff”-Link oder über den “Vergleichen”-Button im Diff-View angezeigt werden.

gitblit_commits_2

Nach dem Review sollte dann über den “Review”-Button im “Commits”-Tab die jeweilige Option ausgewählt werden, die zum Commit passt. Wenn “Akzeptiert” gewählt wird, kann der Commit über den dann angezeigten “Zusammenführen”-Button in die Haupt-Codebasis übernommen werden. Bei “Abgelehnt” gibt es ohne eine neues Patchset hochzuladen keine Möglichkeit, den Commit zu übernehmen.

Verfasst von Fabian Köntopp am 12. September 2016