Übernehmen von Änderungen in den Remote-Tracking-Funktionszweig unter Beibehaltung eines einfachen Verzweigungsworkflows

Question

Wir sind ein Team aus einigen Entwicklern, die unseren Master-Zweig haben und in den Feature-Zweigen Funktionen entwickeln. Wir verzweigen Release-Zweige des Masters, wenn wir etwas veröffentlichen. Alle Fehlerbehebungen werden im Master vorgenommen und dann in den entsprechenden Release-Zweig ausgewählt.

Wir möchten für jedes neue Feature atomare Merge Commits haben, die wir zurücksetzen und halbieren können, wie in beschrieben.https://gist.github.com/jbenet/ee6c9ac48068889b0912. Es sollte uns eine Geschichte geben, die so aussieht.

* aa55ffe -  (HEAD, master) D
* 88425f8 -  C
*   7bc519f -  Merge branch 'feature-X' into master
|\
| * 9364e61 -  feature-X: 2
| * bc76674 -  feature-X: 1
|/
* 88425f8 -  B
*   7bc519f -  Merge branch 'feature-Y' into master
|\
| * 0e0deea -  feature-Y: 4
| * 11079b5 -  feature-Y: 3
| * 9364e61 -  feature-Y: 2
| * bc76674 -  feature-Y: 1
|/
* c765ae3 -  A

Unser Problem entsteht, wenn mehrere Entwickler an derselben Funktion arbeiten und dabei unsere Remote-Version des Funktionszweigs verfolgen. Denn während einige Entwickler an dieser Funktion arbeiten, kann die Fehlerbehebung während einer Funktionsentwicklung im Master erfolgen. Wir möchten diese Fehlerbehebungen jetzt in den Funktionszweig aufnehmen (d. h. den Funktionszweig auf einen neuen Status im Master neu aufbauen, in dem der Fehler behoben ist).

Gibt es eine Möglichkeit, dies zu tun, ohne den Remote-Tracking-Zweig zu beschädigen und somit den sauberen Verlauf und die Arbeitskopien der anderen Feature-Entwickler durcheinander zu bringen?

Fx: Könnte man den Fehler in den Feature-Branch hineinpicken und ihn von Git automatisch beheben lassen, nach dem letzten Rebase, bei dem wir den Remote-Tracking-Branch verwaist machen, kurz bevor wir die neue rebasierte Version des Feature-Branchs in den Master-Branch integrieren?

Answer 1

Könnte man den Fehler in den Feature-Zweig einfügen und ihn von Git automatisch beheben lassen?

Dies kann funktionieren, wenn Ihr Fix keine Konflikte verursacht. git clone https://gist.github.com/jbenet/7959265, sehen Sie sich den Verlauf an und lesen Sie das Reflog, das ich dort eingefügt habe.

Wenn Sie den Konflikt beim Cherry-Picking lösen, können Sie das Commit manuell entfernen, wenn Sie ein Rebase auf dem Master durchführen, direkt bevor Sie den PR einbinden (Sie können es markieren/eine Erinnerung in die Commit-Nachricht schreiben, um den Konflikt zu lösen).

Aber meiner Meinung nach würde ich den Feature-Zweig auf dem Master neu aufbauen, wenn der Hotfix verfügbar ist. Das ist dasselbe, als würden Sie alle Änderungen vom Master übernehmen (einschließlich anderer, kürzlich zusammengeführter Feature-Zweige). Sie müssen sich also keine Sorgen machen, dass Ihr Zweig veraltet ist. Hängt davon ab, was Ihr Team gerne handhabt – zusammengeführte Hotfixes entfernen oder häufig neu aufbauen.

Answer 2

Wenn Sie den Bugfix wirklich in Ihrem Feature-Branch benötigen, führen Sie den Bugfix-Branch ein. Das Gerede über Bisect/Rollback/was auch immer war FUD – Bisect kommt meiner Erfahrung nach mit komplizierten Merge-Historien gut zurecht. Das in diesem Beitrag vorgeschlagene Modell schafft künstliche Probleme (wie das, zu dem Sie Fragen stellen) und sein einziger Vorteil ist buchstäblich eine saubereresuchenVerlauf. Wir haben dieses Modell ein paar Jahre lang verwendet, bevor wir den Vorteil erkannt haben, den es hat, nicht neu zu erstellen. Ich führe ein Rebase durch, wenn ich meinen eigenen Verlauf bereinigen muss (Commits zusammenfassen, Commit-Nachrichten ändern usw.), aber es hat keine Auswirkungen auf andere weiter unten (z. B. wenn ich alleine an dem Zweig arbeite).