Quelltext der Seite Development:Git Workflow

[[Category:Register]]
[[Category:Development]]
[[Category:CDK]]
[[Category:NeutrinoHD]]
{{Development_sidebar}}

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.

__TOC__

= 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">master</span> wenn ein Git Repository erstellt wird. <br/ >
Es gibt eine fast goldene Regel beim Arbeiten mit Git die besagt "Arbeite 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. Folgendes ist dort im <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin</span> Repository übliche Praxis. <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">master</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">master</span> findet keine Entwicklung statt, diese wird in einem oder auch mehreren Branches getätigt!<br/ >
Damit nun nicht unbeabsichtigt ein Developer in den Branch <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin/master</span> pusht haben auf den <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">master</span> Branch in <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin</span> 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?<br/ >
Im Prinzip ganz einfach, in dem man jedes Release basierend auf dem <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">master</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin/master</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin/master</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">devel</span> oder <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">develop</span> 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.<br />
Hat man einen Entwicklungsstand erreicht in dem es keine Fehler mehr gibt und die Software ausreichend getestet hat wird man nun den <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">develop</span> Branch in den <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">master</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">master</span> findet man immer die stable Varianten als Release, im <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">develop</span> findet man statt dessen den aktuellsten Entwicklungsstand.

[[Bild:Git-workflow-two_branches.png|700px]]

== Release Branches ==
Bisher war der Workflow noch sehr einfach, es gibt nur zwei Branches.<br />
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 
<span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin/v1.0</span> und <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin/v1.1</span>.<br />
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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin/develop</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">develop</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">develop</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">develop</span> gemerged und gelöscht. Dies ist nicht mit dem Tagging zu verwechseln!

[[Bild:Git-workflow-two-branches-release-branches.png|900px]]

== 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">develop</span> 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin/...</span> darstellt, 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 <span style="background-color:#E0E0E0; padding:0 1.5pt 0 1.5pt">origin/</span> ist kann ein Entwickler diesen Branch in den jeweiligen Releasebranch mergen.<br />
Liegt der Branch auf einem entfernten Server so wird durch den Betreiber des Featurebranch ein "Pull" Request gestellt. Die Releasebranchverantwortlichen prüfen dann gfs. die Pullfähigkeit des Featurebranches. Sollte es keine Probleme oder Einsprüche seitens der Releaseverantwortlichen geben dann wird der Featurebranch ins Projekt gemerged.

= Quellen =
*[http://nvie.com/posts/a-successful-git-branching-model/ A successful Git Branching Modell]
*[http://csurs.csr.uky.edu/cgi-bin/man/man2html?gitworkflows+7/ Manpage of git WORKFLOW]