it-swarm.com.de

Arbeiten an einem Zweig mit einer Abhängigkeit von einem anderen Zweig, der überprüft wird

Wie hilft Git mit dem folgenden Szenario umzugehen:

Ich habe eine Aufgabe, die in zwei Teile unterteilt ist: Backend-Aufgabe und Frontend-Aufgabe. Ich mache eine Pull-Anfrage, um die Backend-Änderungen zusammenzuführen, und warte, bis sie zusammengeführt sind (und adressiere Feedback). Während des Wartens kann ich nicht wirklich an den Frontend-Änderungen arbeiten, da dies von Backend-Änderungen abhängt und diese noch nicht im Master-Zweig verfügbar sind.

Was ist der beste Weg, um Änderungen am Zweig für Frontend-Änderungen aus dem Zweig für Backend-Änderungen zu übernehmen, während dieser noch überprüft wird?

79
sul4bh

Warte, überspringe das Zusammenführen

Für diesen Ansatz möchten Sie nicht Ihren feature_a Wiederholt in feature_b Zusammenführen.

Rebasing wurde in anderen Antworten erwähnt, jedoch nur, um Dinge auf master neu zu gründen. Was Sie in Ihrem Fall tun möchten, ist:

  • Starten Sie Ihren feature_b Von feature_a, D.h.

    git checkout feature_a
    git checkout -b feature_b
    
  • Immer wenn sich feature_a Ändert, während es darauf wartet, in master zusammengeführt zu werden, rebasefeature_b Darauf:

    ... commit something onto feature_a ...
    git checkout feature_b
    git rebase feature_a
    
  • Sobald feature_a In master zusammengeführt wurde, erhalten Sie einfach das neue master und setzen feature_a Ein letztes Mal darauf neu:

    git checkout master
    git pull Origin master
    git checkout feature_b
    git rebase --onto master feature_a feature_b
    

    Diese endgültige Neugründung überträgt alle Commits, die vom Commit feature_a (Das jetzt irrelevant ist, da es in master zusammengeführt wurde) baumeln, direkt auf master. Ihr feature_b Ist jetzt ein einfacher Standardzweig, der direkt von master ausgeht.

BEARBEITEN: Inspiriert von den Kommentaren, ein wenig Kopfzerbrechen: Wenn Sie Änderungen vornehmen müssen, die sich auf beide Funktionen auswirken, stellen Sie sicher, dass Sie diese in feature_a Einfügen (und dann wie gezeigt neu starten ). Machen Sie nicht machen Sie es in zwei verschiedenen Commits in beiden Zweigen, auch wenn es verlockend sein mag; Da feature_a Teil der Geschichte von feature_b ist, ist die einzelne Änderung in zwei verschiedenen Commits semantisch falsch und führt möglicherweise später zu Konflikten oder "Auferstehungen" von unerwünschtem Code.

57
AnoE

Ich habe dieses Problem auch manchmal. Git ist sehr flexibel. Hier ist eine Möglichkeit, wie Sie es tun können.

Ihr erster Zweig featureA steht zur Überprüfung bereit.

Ihr zweiter Zweig featureB befindet sich in der Entwicklung und hängt vom Code im Zweig featureA ab.

Führen Sie den Zweig featureA in den Zweig featureB ein.

Wenn Sie Änderungen am Zweig featureA vornehmen, sollten Sie den Zweig featureA erneut mit dem Zweig featureB zusammenführen, um die Änderungen zu übernehmen.

Sie sollten auch sicherstellen, dass featureA zuerst mit dem Hauptstamm zusammengeführt wird. Andernfalls werden Sie beim Zusammenführen von featureB mit dem Hauptstamm versehentlich auch featureA zusammenführen. Sobald featureA mit dem Hauptstamm zusammengeführt wurde, können Sie den Zweig featureA entfernen, da featureB jetzt nur noch vom Hauptstamm abhängt.

Ich bevorzuge es, wenn meine Feature-Zweige nicht voneinander abhängen, aber manchmal, und Sie müssen damit rollen.

43
Matt

Sie haben bereits einen Zweig, von dem jeder Feature-Zweig abhängt und der sich ständig ändert. Es heißt master.

Die typische Möglichkeit für einen Feature-Zweig, mit master synchron zu bleiben, besteht darin, oben davon zu bleiben. Wenn sich master ändert, werden Sie normalerweise git fetch Origin master:master && git rebase master im Arbeitsverzeichnis Ihrer Niederlassung.

Sie können das Gleiche mit einem anderen Feature-Zweig tun: Rufen Sie ihn weiter ab und bauen Sie ihn erneut auf.

Wenn Sie aus irgendeinem Grund Ihre Änderungen in einen anderen Zweig verschieben müssen, können Sie Ihre Commits auswählen, die niemals mit den Commits anderer Zweige gemischt werden.

30
9000

In diesem Fall, in dem die Frontend-Aufgabe eine kritische Abhängigkeit vom Backend-Code aufweist und Sie mit der Arbeit am Frontend beginnen möchten, bevor das Backend fertiggestellt und auf dem Master akzeptiert wird, würde ich die Frontend-Aufgabe einfach als Feature-Zweig starten, der vom Backend-Zweig, anstatt das Frontend auf Master zu verzweigen.

Ein Feature-Zweig, der lange genug lebt, muss gelegentlich Änderungen vom Master zusammenführen (um sicherzustellen, dass Sie alle Zusammenführungs- oder semantischen Konflikte im Rahmen der Entwicklungsarbeit am Feature-Zweig und nicht als Teil der "Überprüfung, qa, Zusammenführung" in Einklang bringen. to-master "-Prozess). Sie tun dies also in Ihrem Front-End-Zweig. Wenn die Backend-Arbeit als Master akzeptiert wurde, erhalten Sie alle geringfügigen Änderungen, die im Rahmen der Überprüfung/Annahme des Backends automatisch vorgenommen wurden, auf demselben Weg, den Sie möchten Holen Sie sich alle anderen Codeänderungen auf dem Master.

Wenn sich herausstellt, dass der Backend-Zweig viel mehr Arbeit benötigt und sich im Laufe der Zeit weiter ändert vor dem Master zusammengeführt wird (sagen wir, wenn während der Überprüfung größere Probleme festgestellt werden), dann würden Sie Wahrscheinlich möchten Sie regelmäßige Zusammenführungen direkt vom Backend-Zweig in den Frontend-Zweig durchführen (damit Sie Ihre gesamte Frontend-Arbeit nicht immer auf veralteten Backend-Code stützen). Dies ist einfach, wenn Sie der einzige Entwickler sind, der beide Funktionen ausführt (da Sie wissen, ob Sie selbst größere Änderungen vornehmen), aber selbst wenn beide Funktionen von verschiedenen Entwicklern parallel bearbeitet werden, sollte dies in Ordnung sein. Sie müssen nur in der Kommunikation bleiben (was Sie sowieso brauchen würden, wenn Sie parallel an Aufgaben arbeiten, bei denen eine eine kritische Abhängigkeit von der anderen hat).

Wenn sich herausstellt, dass der gesamte Backend-Zweig aufgegeben werden muss und niemals zusammengeführt wird (es klingt so, als wäre dies eine ziemlich große Sache, die selten passieren würde), wählen Sie entweder Ihre Commits für einen neuen Zweig aus, der vom Master kommt ohne die Backend-Arbeit, oder Sie wenden Reverse Commits an, die den gesamten Backend-Code für den Frontend-Zweig entfernen. Aber wie ich sehen kann, ist es wahrscheinlicher, dass die Frontend-Arbeit unterbrochen wird, bis Sie herausgefunden haben, was das Backend ersetzen wird, das Sie herauswerfen, und dann entscheiden, was zu tun ist.

5
Ben

Ich sehe das Problem hier nicht.

Sie haben dies bereits jedes Mal mit Ihrem Zweig master, der sich ständig ändert, während Features entwickelt und dann zusammengeführt werden.

In Ihrem konkreten Beispiel erstellen Sie zunächst den Zweig feature_xxx_backend Und entwickeln die Backend-Änderungen. Wenn dies erledigt ist, kann der Zweig überprüft werden und wird nach Abschluss der Überprüfung in master zusammengeführt.

Starten Sie einfach einen anderen Zweig, feature_yyy_frontend. Sie werden wahrscheinlich direkt von feature_xxx_backend Verzweigen wollen, damit Sie diese Änderungen bereits in Ihrem branc haben. Entwickeln Sie dann einfach die Frontend-Funktion, wenn der Zweig master ist.

Wenn sich der Zweig feature_xxx_backend Ändert, z. Da während der Überprüfung Dinge auftauchen, die behoben werden müssen, nehmen Sie diese Änderungen einfach vor und führen Sie sie in den Zweig feature_yyy_frontend ein. Fahren Sie dann auf dem Frontend-Zweig fort.

Sobald die Überprüfung des Backend-Zweigs abgeschlossen ist, wird er in master zusammengeführt. An dieser Stelle wäre es ratsam, rebase den Zweig feature_yyy_frontend Auf master zu setzen, damit die Prüfer nur den new Änderungen, die dieser Zweig zu master beiträgt, und müssen die für das Backend vorgenommenen Änderungen (die bereits genehmigt wurden) nicht erneut überprüfen.

Dies kann auch erfolgen, wenn Sie zwei, drei oder mehr abhängige Zweige haben. Wenn Sie zwei Feature-Zweige haben, von denen Sie abhängig sind, erstellen Sie einfach einen abgeleiteten Zweig, in dem beide Features zusammengeführt sind. Verzweigen Sie von dort aus, entwickeln Sie das dritte Feature und führen Sie beide Feature-Zweige auf dem Weg zusammen, wenn sich diese ändern. Wenn beide Funktionen fertig sind und entweder in den abgeleiteten Zweig eingefügt werden, bauen Sie sie erneut auf, oder wenn sie in den Master zusammengeführt werden, stützen Sie sich erneut auf den Master.

Rebasing (wie oben vorgeschlagen) ist sehr leistungsfähig und hilft dabei, ein sauberes Protokoll der Änderungen zu führen, wodurch Überprüfungen viel einfacher werden.

2
Polygnome

Wie Polygnome bereits erwähnt hat, können Sie Ihren Frontend-Zweig tatsächlich mit Ihrem Backend-Zweig anstelle der Master zusammenführen. Selbst mit dem aktuellen Zweigstellen-Setup, das Sie jetzt haben, können Sie einfach Folgendes tun:

git checkout frontend
git merge backend

oder einfach

git merge backend frontend

Beachten Sie jedoch, dass Sie Aktualisierungen vom Backend zum Frontend zusammenführen müssen, wenn Backend-Änderungen nicht akzeptiert werden und mehr Arbeit erforderlich ist, um Konflikte zu vermeiden. Sobald die Änderungen in den Master übernommen wurden, können Sie Ihr Frontend auf dem Master neu aufbauen, um die Commits für das Zusammenführen des Backends zu entfernen.

Technisch gesehen könnten Sie auch alles mit Rebase machen, aber das wird den Commit-Verlauf Ihres Frontend-Zweigs durcheinander bringen. Woher ich komme, wird dies als schlechte Praxis angesehen. YMMV

2
Joris Meys

Die meisten Antworten hier beschreiben den Prozess des Zusammenführens der Änderungen vom zweiten zum ersten Zweig korrekt, behandeln jedoch nicht, wie die Anzahl der Konflikte, die Sie möglicherweise lösen müssen, minimiert werden kann.

Wenn Sie zwei große Änderungen haben, die Sie einzeln überprüfen möchten (z. B. featureA und featureB), erstellen Sie eine PR, die NICHT zum Zusammenführen gedacht ist, sondern um frühzeitig Feedback zu einem PoC von zu erhalten featureA.

Die Benutzer können es schnell überprüfen (es ist nur ein PoC), und das Ziel besteht darin, das allgemeine Design oder den allgemeinen Ansatz zu validieren.

Anschließend können Sie an Feature A weiterarbeiten, eine Pull-Anforderung dafür erstellen und das Feature B verzweigen und bearbeiten.

Der große Unterschied besteht darin, dass Sie jetzt erwarten können, dass sich featureA nicht radikal ändert: Das Design und der Ansatz wurden bereits validiert. Die Codeüberprüfung und die erforderlichen Änderungen können eher subtil und lokal sein als "Woops, Sie brauchen einen anderen Ansatz". Dadurch wird der Arbeitsaufwand minimiert, den Sie später ausführen müssen, um featureB mit dem Code von featureA zusammenzuführen, unabhängig von der von Ihnen gewählten Methode.

1
Alpha