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 folgendes Modell bei der Softwareentwicklung von großen, aber auch kleinen Projekten etabliert.
Inhaltsverzeichnis
Alles beruht auf Branches
Der wohl größte Unterschied zu 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 goldenen 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 übliche Praxis.
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!
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 eigentlich ein zusätzlicher (einfach zu lesender) Vermerk zu einem Commit.
Der Devel- oder Entwicklungsbranch
Noch sind wir nur bei einem Branch, eben den Standardbranch den Git von selbst anlegt, eben den "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 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.
