Kürzlich habe ich die drei Konzepte eines Workflows in GIT gefunden: GitFlow, GitHub Flow und GitLab Flow. Ich habe gelesen die schönen artikel darüber, aber ich verstehe GitLab Flow nicht sehr gut. Vielleicht weil ich kein Muttersprachler bin 🙂
Knapp.
GitFlow
Wir haben einen Master-Branch als Produktions-Branch. Außerdem haben wir einen Entwicklungszweig, in dem jeder Entwickler seine Funktionen zusammenführt. Manchmal erstellen wir einen Release-Branch, um unsere Funktionen in der Produktion bereitzustellen. Wenn wir einen Fehler im Release-Branch haben, beheben Sie ihn und ziehen Sie die Änderungen in den Developer-Branch. Wenn wir einen kritischen Fehler in der Produktion haben, erstellen Sie einen neuen Hotfix-Zweig, beheben Sie den Fehler und führen Sie den Zweig mit der Produktion (Master) zusammen und entwickeln Sie Zweige.
Dieser Ansatz funktioniert gut, wenn wir selten Ergebnisse unserer Arbeit veröffentlichen. (Vielleicht einmal alle 2 Wochen).
GitHub-Flow
Wir haben eine Master-Filiale als Produktions-Filiale. Und wir (als Entwickler) können Zweige erstellen, um neue Funktionen hinzuzufügen oder Fehler zu beheben, und sie mit dem Produktionszweig (Master-Branch) zusammenführen. Es klingt sehr einfach. Dieser Ansatz eignet sich für extreme Programmierung, bei der der Produktionszweig mehrmals am Tag bereitgestellt wird.
GitLab-Flow
Ich habe neue Begriffe wie eine Vorproduktion, eine Produktion, einen Release- (stabilen) Zweig und eine Staging-Umgebung, eine Vorproduktionsumgebung, eine Produktionsumgebung gesehen. Welche Beziehungen haben sie untereinander?
Ich verstehe das so: Wenn wir ein neues Feature hinzufügen müssen, stellen wir einen Vorproduktions-Branch aus dem Master-Branch bereit. Wenn wir das Feature fertiggestellt haben, stellen wir einen Produktionsbranch aus dem Pre-Production-Branch bereit. Ein Vorproduktionszweig ist die Zwischenstufe. Und dann zieht der Master-Branch alle Änderungen aus dem Production-Branch.
Der Ansatz ist gut, wenn wir jedes einzelne Feature sehen wollen; Wir checken einfach in der Filiale aus, was wir uns ansehen müssen.
Aber wenn wir unsere Arbeit zeigen müssen, erstellen wir so spät wie möglich einen Release-Branch mit einem Tag. Wenn wir später Fehler im Master-Zweig beheben, müssen wir sie in den letzten Release-Zweig auslagern. Am Ende haben wir den Release-Zweig mit Tags, die uns helfen können, zwischen Versionen zu wechseln.
Ist mein Verständnis richtig?
Was ist der Unterschied zwischen pull und cherry-pick?
