Development:Git Workflow
Dieser Artikel befindet sich derzeit im Reviewprozess. Hilf mit, ihn zu verbessern!
Falls du bei weiteren Artikeln helfen willst, findest du hier eine Auswahl offener Artikel. Development
- Allgemein
- Neutrino-HD-Entwicklung
- dbox2 Entwicklung
Mit Git haben Entwickler ein sehr mächtiges und umfangreiches Tool zur Softwareentwicklung an der Hand. Damit man Git wirklich effektiv zur Entwicklung einsetzt haben sich folgende beschriebene Modelle bei der Softwareentwicklung von großen, aber auch kleinen Projekten etabliert.
Inhaltsverzeichnis
Alles beruht auf Branches
Der wohl größte Unterschied zwischen Git und den anderen Versionsverwaltungssystemen liegt in der einfachen Möglichkeit einen Branch zu erstellen und mit diesem zu arbeiten. Git erstellt per Default einen Branch master wenn ein Git Repository erstellt wird.
Es gibt eine fast goldene Regel beim Arbeiten mit Git die besagt "Entwickle nie im master Branch." Ergo muss bzw. sollte man zusätzliche Branches erstellen. Aber wie soll man nun die einzelnen Branches benennen?
Dazu muss man sich Gedanken machen wie der Arbeitsablauf (Workflow) sich darstellt. Man braucht aber das Rad nicht versuchen neu zu erfinden, vor dieser Frage der Namensgebung standen schon viele andere Projekte. Also schaut man einfach mal wie man es dort macht.
Das Modell "master/release/feature/hotfix" Branches
Dieses Branchingmodell findet man so oder ähnlich sehr oft in großen Projekten mit vielen Unterkategorien.
Folgendes ist dort im origin Repository übliche Praxis. origin ist der Git Server der als "zentraler" Hauptserver fungiert. Bedenkt das Git ein DCVS ist und somit jeder Git Benutzer somit auch eine komplette Kopie der jeweiligen Server, inclusive des eigenen, besitzt und anbieten könnte. Der Server der origin darstellt kann also auch recht schnell geändert werden.
Der "master" Branch
Jede Software wird irgendwann einmal als produktiv angesehen. Wenn ein User sich ein Git Repository clont benutzt Git den master Branch als Default Branch, wie schon erwähnt. Damit nun der User sich unsere Software auch bauen und auch benutzen kann muss "master" aber auf jeden Fall den letzten als produktiven benannten Stand wieder spiegeln! "master" ist also immer auch das letzte getaggte Release! Oder anders gesagt, im master findet keine Entwicklung statt, diese wird in einem oder auch mehreren Branches getätigt!
Damit nun nicht unbeabsichtigt ein Developer in den Branch origin/master pusht haben auf den master Branch in origin nur wenige Personen die benötigten Rechte um in diesen Branch zu pushen bzw. zu mergen.
Die Release Tags
Wie findet man nun den vorherigen releasten Stand?
Im Prinzip ganz einfach, in dem man jedes Release basierend auf dem master Branch taggt! An Hand des Tagnamen kann man diesen Stand in Git einfach auschecken. Damit kann man jederzeit auch jedes Release wieder bauen, da Git sich um die nötigen Dinge kümmert. Ein Releasetag ist kein eigener Branch, es ist eigentlich ein zusätzlicher (einfach zu lesender) Vermerk zu einem Commit. Das Tagging kann man durch Hook Scripte sogar automatisieren, da ja jedes Pushen in origin/master automatisch ein Tagging verlangt.
Der Devel- oder Entwicklungsbranch
Noch sind wir nur bei einem Branch, eben den Standardbranch den Git von selbst anlegt, den schon bekannten origin/master Branch. Nun soll und muss ja irgendwo auch entwickelt werden und dies geschieht natürlich in einem extra Branch. In den meisten Projekten wird dieser devel oder develop benannt. Dieser Branch ist also Bleeding Etch und kann auch mal durch einen fehlerhaften Commit zu einem Buildfehler oder fehlerhaften Verhalten der Software führen. Dies fällt aber sehr schnell auf und wird durch den letzten Committer dann hoffentlich schnell gefixt.
Hat man einen Entwicklungsstand erreicht in dem es keine Fehler mehr gibt und die Software ausreichend getestet hat wird man nun den develop Branch in den master Branch mergen und final dort dann noch das Tagging erstellen. Damit hat man dann ein neues Release erschaffen, der Kreis schließt sich.
Erstes Fazit
In der Minimalvariante hat man zwei Branches. Im master findet man immer die stable Varianten als Release, im develop findet man statt dessen den aktuellsten Entwicklungsstand.
Release Branches
Bisher war der Workflow noch sehr einfach, es gibt nur zwei Branches.
In einem gutem Projekt gibt es üblicher Weise eine Roadmap in der Features für ein bestimmtes Releases festgelegt sind. In den Projekten gibt es Entwickler die an unterschiedlichen Features, die z.B. in unterschiedlichen Releaes verfügbar sein sollen, arbeiten. Damit diese sich nicht gegenseitig behindern, trotzdem aber entsprechender Quellcode nicht verloren geht werden in solchen Fällen Release Branches eröffnet. Diese Branches werden dann nach dem Releasetag benannt. Zum Beispiel
origin/v1.0 und origin/v1.1.
Wenn man mit mehr wie einem Releasebranch arbeitet muss man beim Mergen aufpassen. Der/die höherwertige(n) Releasebranch(es) sollte(n) nicht mehr nach origin/develop gemerged werden, wenn einzelne Funktionalitäten trotzdem schon in jüngeren Releases zur Verfügung stehen sollen werden selektiv einzelne Commits eingepflegt (per cherry-pick).
Releasebranches sind temporäre Branches, das heißt das diese nach dem erfolgreichen Mergen in den Hauptentwicklungsbranch develop wieder gelöscht werden. Nach dem Mergen haben diese Branches keinen tieferen Sinn mehr und stören mehr wie das sie eine Hilfe sind. Nach dem Mergen wird dann im Branch develop das Release in Form von finalen Codecleaning und Beseitigen von noch auftretenden Bugfixes betrieben.
Zweites Fazit
Ein Projekt mit verschiedenen Releasezielen erfordert mehrere Entwicklungsbranches. Die Ausarbeitung zukünftiger Releasestände erfolgt in eigenständigen Branches. Nach dem Erreichen eines Softwarezieles wird der entsprechende Branch nach develop gemerged und gelöscht. Dies ist nicht mit dem Tagging zu verwechseln!
Features Branches
Ab einer gewissen Größe von einem Projekt lassen sich neue Features innerhalb des obigen aufgezeigten Ablaufes nicht effektiv einbringen, da die Entwicklung nicht mir wenigen Commits getan ist. Oder dies ist von den Projektverantwortlichen nicht erwünscht. Dann muss die Entwicklung eines neuen Features außerhalb der Releasebranches erfolgen. Dies hat den Vorteil das keine Reverts im Releasebranch (oder gar im develop Branch) durchgeführt werden müssen wenn sich ein Feature als obsolet oder überflüssig erweist. Auch kann der eventuell einzige Entwickler des neuen Features Seine Entwicklung aus verschiedensten Gründen einstellen.
Deshalb kann es in einem Projekt einen oder mehrere sogenannte Featurebranches geben. Diese haben in der Regel einen sehr experimentellen Charakter, zu mindestens in der Anfangsphase. Featurebranches arbeiten fast immer auf ein Release hin. Featurebranches können auf dem Server liegen der origin/... darstellt, dann kann jeder interessierte sich diese Branches auschecken und testen. Diese können aber auch auf anderen Servern liegen. In dem Fall muss ein weiterer Remote hinzugefügt werden.
Ist ein Featurebranch "fertig" zur Integration in den aktuellen Releasebranch und liegt auf dem Server der origin/ ist kann ein Entwickler diesen Branch in den jeweiligen Releasebranch mergen.
Liegt der Branch auf einem entfernten Server so wird durch den Betreiber des Featurebranch ein "Pull" Request oder auch ein Patchset gestellt. Die Releasebranchverantwortlichen prüfen dann gfs. die Pull- Commitfähigkeit sowie die Codequalität des Featurebranches. Sollte es keine Probleme oder Einsprüche seitens der Releaseverantwortlichen geben dann wird der Featurebranch ins Projekt gemerged.
Drittes Fazit
Komplexere und große Projekte erfordern in der Regel weitere Branches. Diese zusätzlichen Branches dienen der speziellen Entwicklung von einzelnen Features. Diese Branches können im Projekt direkt integriert werden aber auch von einzelnen Personen lokal oder in deren Repositorys liegen. Nach Fertigstellung neuer Funktionen werden diese Branches in den Releasebranch gemerged oder auch per Patchset committet um danach durch weitere QS in den develop Branch bis hin zum Release zu wandern.
Mit Git ist dieses Arbeiten kein Problem, im Gegenteil, dies ist eine der Stärken von Git. Diese Art des Workflow wird zum Beispiel sehr stark im Kernelumfeld praktiziert.
Das Modell "master/maint/next/pu/..." Branches
Ein weiteres Modell welches man sehr oft antrifft. Im Gegensatz zum oben beschriebenen Modell findet hier die Entwicklung bewusst im origin/master Branch statt. Aber insgesamt ist das Prinzip im Grundprinzip das selbe wie im obigen Modell, die Namen der Branches ist aber etwas anders. Bei der Kernelentwicklung, sowie fast allen GNU Projekten wird dieses Modell benutzt.
Der "master" Branch
Eines haben alle Modelle gemeinsam, den origin/master Branch. In diesem Modell spielt dieser master Branch aber eine zentrale Rolle, er ist der Branch der Quelle für alle anderen Branches ist, aber auch die Sammelstelle für alle Merge Vorgänge die zu einem Release führen sollen. Im Gegensatz zum oben beschriebenen Modell findet im master Branch die Entwicklung für das laufende Release statt. Dies allerdings nur um das Release stabil und fehlerfrei releasen zu können. Alles was gegen diese Vorgabe verstößt gehört nicht in diesen Branch sondern in den next oder einen der pu/... Branches.
Der "next" Branch"
Der next Branch ist die Sammelstelle für alle zukünftiges Features nach den aktuellen Releasevorbereitungen. Somit gehört Code der entweder noch sehr neu ist oder bestimmte neu Abhängigkeiten mit sich bringt in diesen Branch. Trotzdem ist der next Branch aber kein experimenteller Branch, vielmehr ist er Sammelstelle für neue Ideen und Weiterentwicklungen.
