Development:Git Workflow
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 hat sich nach folgendes beschriebenes Modell 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 "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 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.
Bisheriges 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.
