Was ist der Unterschied zwischen dem GitHub-Flow und die GitLab-Flow?

Vor kurzem habe ich gefunden, die drei Konzepte eines workflow-GIT: GitFlow, GitHub-Flow und die GitLab-Flow. Ich habe gelesen, die netten Artikel über es ( https://docs.gitlab.com/ee/workflow/gitlab_flow.html ), aber ich verstehe nicht sehr gut GitLab-Flow. Vielleicht, weil ich bin kein native speaker 🙂

Kurz.

GitFlow (https://docs.gitlab.com/ee/workflow/gitdashflow.png).

Wir haben eine master-Zweig als Produktions-Zweig. Auch wir haben einen Zweig entwickeln, wo jeder Entwickler verbindet sich seine Gesichtszüge. Manchmal schaffen wir eine release-Zweig zu implementieren unsere Eigenschaften in der Produktion. Wenn wir einen bug im release-Zweig, das lösen und ziehen änderungen in den develop branch. Wenn wir einen kritischen Fehler in der Produktion, neue erstellen hotfix-branch fix-bug-und merge-Niederlassung mit Produktion (master) entwickeln und Zweige.

Dieser Ansatz ist sehr gut, wenn wir nur selten zeigen die Ergebnisse unserer Arbeit. (Vielleicht ein mal pro 2 Wochen).

GitHub-Flow (https://docs.gitlab.com/ee/workflow/github_flow.png).

Wir haben eine master-Zweig als Produktions-Zweig. Und wir (als Entwickler) können nur zur Erstellung von abzweigungen für das hinzufügen neuer Funktionen oder das beheben von Fehlern und mischen Sie Sie mit der Produktion (master) Zweig. Es klingt sehr einfach. Dieser Ansatz eignet sich für extreme programming, in denen die Produktion Zweig bereitgestellt wird, mehrmals an einem Tag.

GitLab Flow (https://docs.gitlab.com/ee/workflow/production_branch.png, https://docs.gitlab.com/ee/workflow/environment_branches.png, https://docs.gitlab.com/ee/workflow/release_branches.png).

Ich habe gesehen, neue Begriffe, die wie ein pre-Produktion, Produktion, ein release (stable) Zweig und eine staging-Umgebung, eine pre-production-Umgebung, einer Produktionsumgebung. Welche Beziehungen haben Sie zwischen Ihnen?

Ich verstehe es so: Wenn wir eine neue Funktion hinzufügen, die wir bereitstellen, eine pre-production-branch vom master branch. Wenn wir abgeschlossen haben die Funktion, die wir bereitstellen, eine Produktion der Abteilung von der pre-production-Zweig. Ein pre-production-Branche ist die Zwischenstufe. Und dann der master-branch ziehen Sie alle änderungen aus der Produktion Zweig.

Der Ansatz ist gut, wenn wir sehen wollen, jedes einzelne feature. Wir haben gerade Kasse in der Filiale, was wir brauchen und schauen.

Aber wenn wir brauchen, um unsere Arbeit, die wir erstellen ein release-branch mit einem tag-so spät wie möglich. Wenn wir später beheben von Fehlern in der master-Zweig müssen wir zum cherry-picken Sie auf die Letzte release-Zweig. Am Ende haben wir den release-Zweig mit tags, die helfen können, uns zu bewegen, zwischen den Versionen.

Meine vision ist richtig?
Was ist der Unterschied zwischen pull-und cherry-pick?

InformationsquelleAutor Avinar | 2016-10-07
  1. 22

    GitLab Flow schlägt master und feature Zweige zu. Sobald die Funktion fertig ist, verschmelzen wir es zurück master Zweig. Das Teil sieht genauso aus, wie in GitHub-Flow.

    Dann mein Verständnis ist, dass Sie uns 2 Optionen, wie es zu tun, je nachdem, ob es SAAS-app oder mobile-app (die Version aus der Welt).

    Wenn dies SAAS-app verwenden wir Umwelt-Filialen z.B. pre-production und production. Diese Zweige sind erstellt aus den master wenn wir bereit sind, implementieren Sie die Anwendung. Mit verschiedenen Verzweigungen pro-Umgebung erlauben uns, setup CI/CD-tool für die automatische Bereitstellung auf commits, die auf diese Niederlassungen. Wenn es ein kritisches Problem, wir beheben es in feature oder master Zweig und dann verschmelzen Sie zu environment Zweige.

    Als für Anwendungen, die freigegeben werden können, aus der Welt (z.B. Mobil-oder desktop-apps) mein Verständnis ist, dass Sie vorschlagen, verwenden Sie unterschiedliche Modell mit release Zweige anstelle von Umwelt-Filialen. Das tun wir immer noch alle arbeiten in feature Zweige und verschmelzen Sie zurück, um master Zweig bei Abschluss. Dann, wenn wir sicherstellen, dass master Zweig ist stabil genug, d.h. haben wir bereits durchgeführt, alle Tests und bug-fixing erstellen wir release Filiale und lassen Sie unsere software. Wenn es eine kritische Frage, die wir zunächst beheben in master Zweig und cherry-pick einen fix release Zweig.

    InformationsquelleAutor Alexey Andrushkevich
  2. 17

    Es ist ein Jahr nun seit diesem post angesprochen wurde, aber in Anbetracht der zukünftigen Leser und die Tatsache, die Dinge haben sich ein wenig geändert, ich denke, es lohnt sich erfrischend.

    GitHub-Flow als ursprünglich dargestellt von Scott Chacon im Jahr 2011 ausgegangen, jeder änderung einmal überprüft feature branch und zusammengeführt master sollten bereitgestellt werden, um die Produktion sofort. Während diese arbeitete zu der Zeit und entsprach den nur GitHub-Flow-Regel, die nichts in den master-branch bereitstellbar ist, es wurde schnell entdeckt, dass, um zu halten master einer echten Rekord von bekannten Arbeit-Produktion-code die tatsächliche Bereitstellung der Produktion geschehen sollte von der feature branch vor Verschmelzung master. Die Implementierung von der feature branch durchaus Sinn macht, da bei jedem Problem die Produktion kann sofort rückgängig gemacht, durch die Bereitstellung von master zu. Bitte werfen Sie einen Blick auf eine kurze visuelle Einführung zu GitHub-Flow.

    GitLab Flow ist eine Art Erweiterung von GitHub-Flow-begleitet von einer Reihe von Richtlinien und best practices, die darauf abzielen, die weitere Standardisierung der Verfahren. Abgesehen von der Förderung bereit master branch und der feature-Zweige (wie GitHub-Flow) es führt drei andere Arten von Verzweigungen:

    1. Produktion - Zweig
    2. Umwelt Filialen: uat, pre-production, production
    3. Release-Zweige: 1-5-stable, 1-6-stable

    Ich glaube oben genannten Namen und Beispiele sind selbst beschreibende, also werde ich nicht näher auszuführen.

    InformationsquelleAutor czerwin
Schreibe einen Kommentar