Einführung

Git ([ɡɪt], engl. Blödmann) ist ein quelloffenes und frei erhältliches Versionsverwaltungssystem. Wie Subversion (SVN) einst das Concurrent Version System (CVS) ablöste, gilt SVN nun schon einige Jahre als ausrangiert. Nicht weil git hipp ist, sondern essentielle Vorteile gegenüber SVN bietet. So sind etwa Änderungen am Repository (z.B. commit) solange lokal, bis diese explizit in das entfernte Repository übertragen werden (push). Somit muss ein Entwickler nicht erst eine stabile Version seiner Software schaffen, um Änderungen in das Repository zu übernehmen, sondern kann nun jede Änderung per commit festschreiben, ohne das entfernte Repository zu beeinflussen und dadurch evtl. andere Entwickler zu stören.

Freiheit bedingt aber immer auch feste Regeln, damit ein Miteinander reibungslos funktioniert. Dieser Beitrag stellt ein Vorgehensmodell vor, das den erfolgreichen Einsatz von git in Entwicklungsprojekten, sicherstellt.

Gitflow

Gitflow basiert auf einem zentralen Repository. Es dient als Kommunikationshub für alle Entwickler. Gitflow definiert ein striktes Branching-Modell, bei dem jedem Zweig eine feste Rolle obliegt.

Master-Branch

Der Master-Branch wird ausschließlich zur Verfolgung von Releases und Zwischenversionen verwendet. Dies ermöglicht jederzeit, ausgelieferte Software-Stände einfach zu rekonstruieren.

Develop-Branch

Dieser Zweig dient zur Integration der laufenden Entwicklung. Versionen einer Software, die nicht zu einem offiziellen Release gehören, werden im Develop-Branch festgeschrieben.

Feature-Branch

Jedes Feature sollte in einem eigenen Feature-Branch entwickelt werden. Es ermöglicht, Features unabhängig von einander zu realisieren. Ein Feature zweigt von dem Stand des Develop-Branches ab, auf dem das Feature basieren soll. Ist die Entwicklung abgeschlossen, wird der Zweig in den Develop-Zweig überführt.

Release-Branch

Damit eine Auslieferung die laufende Entwicklung nicht blockiert, wird der entsprechende Entwicklungsstand auf den Release-Zweig übernommen. Dort werden nur noch abschließende Arbeiten, wie Fehlerbehebung, Dokumentation und sonstige auslieferungsorientierte Aufgaben durchgeführt. Sind diese abgeschlossen, wird der Stand in den Master-Branch übernommen. Zusätzlich wird der Develop-Branch aktualisiert, damit die Änderungen in die aktuelle Entwicklung einfließen.

Hotfix-Branch

Müssen schnell Korrekturen an Auslieferungen vorgenommen werden, sind diese auf dem HotFix-Zweig durchzuführen. Dies begünstigt, dass der restliche Workflow nicht gestört wird. Auch ist es nicht nötig erst einen Release-Zyklus abzuwarten. Nach Fertigstellung der Änderungen, werden diese ebenfalls in den Develop-Zweig übernommen.