it-swarm.com.de

Ist es in GitHub Flow in Ordnung, den Feature-Zweig auf einem anderen Feature-Zweig zu basieren?

Wir verwenden GitHub Flow in unserem Projekt und öffnen die meiste Zeit einen neuen Feature-Zweig vom Master , erledigen einige Arbeiten Öffnen Sie dort eine PR, überprüfen Sie den Code und führen Sie ihn zurück in master .

Meine aktuelle Arbeit hängt jedoch von einem anderen Problem ab, an dem in feature-branch-A Gearbeitet wird. Ist es koscher, meinen Zweig aus diesem anderen Zweig zu erstellen oder ist das gegen den Geist von GitHub Flow?

Die Alternative wäre, meinen Zweig auf Master zu stützen und die Änderungen von feature-branch-A (Häufig) zusammenzuführen.

Welche Option wird im GitHub-Flow bevorzugt?

23
Borek Bernard

Hier ist der Workflow, dem ich folge, wenn ich von einem Feature-Zweig verzweige:

  1. Erstellen Sie feature-branch-B Aus feature-branch-A
  2. Arbeite an feature-branch-B
  3. Wenn nach der Verzweigung mehr Commits zu feature-branch-A Hinzugefügt werden, setzen Sie feature-branch-B Auf feature-branch-A
  4. Beenden Sie die Arbeit an feature-branch-B Und warten Sie, bis feature-branch-A In master zusammengeführt wird.
  5. Nachdem feature-branch-A In master zusammengeführt wurde, wird feature-branch-B Auf master neu basiert
  6. Füge feature-branch-B In master ein

Wenn Sie dem obigen Workflow folgen, werden Sie anscheinend von master verzweigt, nachdem feature-branch-A Zusammengeführt wurde. Sie müssen nicht warten, bis feature-branch-A Zusammengeführt wird, um mit der Arbeit an feature-branch-B Zu beginnen. Sie erhalten jedoch eine saubere Geschichte ohne komplizierte Bäume.

29
geoji

Ich denke, das ist völlig in Ordnung, wenn Sie das Feature bei einem anderen Feature erstellen.

Aber mach es nicht oft. Ich sehe einen Entwickler, der dies gemacht hat, und ein oder zwei Wochen, in denen er 10 PR zum Zusammenführen rauswirft. Das war für andere Mitglieder völlig anstrengend und schwer zu verschmelzen. Versuche keine Bäume in Git zu machen. Das hilft bei der Halbierung, um Fehler zu finden.

8

Eine wichtige Sache, mit der sich git-flow befassen sollte, war die Fähigkeit, über die Rolle eines bestimmten Zweigs nachzudenken und darüber, von welchem ​​Zweig er sich verzweigt und zu welchem ​​er verschmilzt.

Im Idealfall werden alle Zweige wieder mit der Codeline zusammengeführt, aus der sie zusammengeführt wurden. Dies ist normalerweise eine Zusammenführung von der Hauptzeile (im Git-Flow ist dies dev). Feature-Zweige verzweigen und von dev zusammenführen, verzweigen und verzweigen von dev (mit einer zusätzlichen Zusammenführung zu master). Hotfixes verzweigen und führen vom Master zusammen (mit dieser zusätzlichen Zusammenführung zurück zum Entwickler).

Jede Codeline verzweigt von ihrem übergeordneten Element und wird wieder mit diesem übergeordnet. Eine Codeline kann jederzeit Code aus anderen Codelines abrufen, wenn dies erforderlich ist.

Wenn der Zweig eines Feature-Zweigs ein "Ich möchte diese Art der Behebung eines Problems in diesem Feature-Zweig untersuchen" ist - vollkommen in Ordnung. Es verzweigt vom Feature-Zweig, schreibt Code fest und wird wieder zum Feature-Zweig zusammengeführt (oder wird verworfen).

  1. von Feature verzweigen
  2. idee erkunden
  3. zum Feature zusammenführen

Was Sie jedoch vermeiden möchten, sieht folgendermaßen aus:

  1. verzweigen Sie von der erforderlichen Funktion
  2. code bearbeiten
  3. nach Abschluss der erforderlichen Funktion von dev zusammenführen
  4. überprüfen Sie die Funktionalität (und zusätzliche Commits) im Feature-Zweig
  5. verschmelzen zu dev

Der Grund ist, dass Anfang und Ende nicht übereinstimmen - es macht es ein bisschen schwieriger zu verstehen, was dies ist und war. Nicht unmöglich, aber es dauert nur ein bisschen länger, bis jemand seine Rolle versteht.

Wenn dies jedoch eine neue Funktion ist, die von Code abhängt, der noch nicht in dev gefunden wurde, sollte der Ablauf wie folgt lauten:

  1. zweig von dev
  2. aus der erforderlichen Funktion zusammenführen
  3. code bearbeiten
  4. nach Abschluss der erforderlichen Funktion von dev zusammenführen
  5. überprüfen Sie die Funktionalität (und zusätzliche Commits) im Feature-Zweig
  6. verschmelzen zu dev

Beachten Sie, dass dies mit einem Zweig von dev beginnt und mit einer Zusammenführung zu dev endet.

Alles, was gesagt wird, ist wahrscheinlich das Beste, eine Zusammenführung von einem Feature zu einem anderen Feature zu vermeiden. Verzweigen Sie die Funktion, führen Sie die erforderlichen Vorbereitungen durch ... und warten Sie.

  1. zweig von dev
  2. code bearbeiten
  3. nach Abschluss der erforderlichen Funktion von dev zusammenführen
  4. überprüfen Sie die Funktionalität (und zusätzliche Commits) im Feature-Zweig
  5. verschmelzen zu dev

Dies bietet den stabilsten Satz von Zweigen und Code.

Für zukünftige Arbeiten sollte eine Funktion in Betracht gezogen werden, mit der die für die Interoperabilität mit anderen Funktionen erforderlichen Schnittstellen veröffentlicht werden können - auch wenn der Implementierungscode nicht vollständig ist. Dies würde mit dev zusammengeführt, und dann könnte die erforderliche Funktion von diesen Schnittstellen funktionieren, ebenso wie die zukünftige Funktion. Dies würde es wahrscheinlich ermöglichen, dass das zukünftige Feature weiter voranschreitet (Codierung gegen die Schnittstellen, Testen gegen Stubbs, die die Schnittstellen implementieren), als wenn es warten müsste, bis das erforderliche Feature mit dev zusammengeführt wird.

7
user40980

Ein Feature-Zweig wird normalerweise als weniger stabil als der Trunk (Entwickeln/Master) angesehen, sodass Sie möglicherweise mehr zugrunde liegenden Änderungen als normal unterliegen, wenn Sie Ihre Arbeit auf einem basieren.

Auch wenn es normalerweise verpönt ist, wenn der Zweig verschoben wurde, ist es nicht ungewöhnlich, Feature-Zweige auf den übergeordneten Zweig zu verschieben, um eine schönere Historie zu erhalten. Dies wäre jedoch besonders kompliziert, wenn zusätzliche Zweige daran hängen würden, also Sie Wir schaffen im Wesentlichen eine neue Einschränkung für den übergeordneten Zweigstellenbesitzer sowie potenzielle Kopfschmerzen für Sie.

Das heißt, es gibt keine strenge Regel dagegen. Dies sind schließlich nur Muster und Best Practices.

Bearbeiten: Teil Ihrer Frage verpasst. Durch das Zusammenführen des Feature-Zweigs in Ihren eigenen, der auf dem Master basiert, werden die oben genannten Probleme nicht wirklich vermieden, und es kann tatsächlich zu einem noch komplizierteren Verlauf kommen.

Wenn ich also in Ihren Schuhen stecke und die Arbeit verschieben könnte, bis Feature a fertig ist, oder zuerst etwas anderes tun würde, würde ich das tun.

1
axl