Änderungen in den Remote-Tracking-Feature-Zweig ziehen und dabei den einfachen Workflow für die Verzweigung beibehalten

477
Stefan Wallin

Wir sind ein Team von einigen Entwicklern, die über einen Master-Zweig verfügen und Funktionen in Feature-Zweigen entwickeln. Wir verzweigen Release-Zweige von Master, wenn wir veröffentlichen. Alle Fehlerbehebungen werden im Master vorgenommen und dann in den entsprechenden Release-Zweig gepflückt.

Wir möchten atomare Merge-Commits für jedes neue Feature, das wir zurücksetzen und halbieren können, wie in https://gist.github.com/jbenet/ee6c9ac48068889b0912 beschrieben . 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 tritt auf, wenn mehrere Entwickler an derselben Remote-Version des Feature-Zweigs mit derselben Funktion arbeiten. Während einige Entwickler an diesem Feature arbeiten, kann die Fehlerbehebung während der Feature-Entwicklung in Master auftreten. Wir möchten nun diese Fehlerbehebungen in den Feature-Zweig aufnehmen (dh den Feature-Zweig eines neuen Status in Master, in dem der Fehler behoben ist, umbasieren).

Gibt es eine Möglichkeit, dies zu tun, ohne den Remote-Tracking-Zweig zu beschädigen und dadurch den Clean-Verlauf und die Arbeitskopien anderer Feature-Entwickler zu vermasseln?

Fx Könnte man den Fehler in den Funktionszweig blasen und ihn nach der letzten Rebase, in der wir den Fernverfolgungszweig verwaist haben, automatisch beheben, bevor die neue, basierende Version des Funktionszweigs in den Master eingefügt wird?

0

2 Antworten auf die Frage

1
jbenet

Könnte ein Fehler den Fehler in den Funktionszweig herauspicken und git ihn automatisch beheben lassen

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

Wenn Sie einen Konflikt nach der Kirschpickel-Lösung lösen, können Sie das Festschreiben manuell entfernen, wenn Sie auf Master umbasieren, bevor Sie PR einführen.

Aber IMO, ich würde den Funktionszweig auf Master setzen, wenn der Hotfix verfügbar war. Dies ist gleichbedeutend mit dem Abrufen aller Änderungen vom Master (einschließlich anderer kürzlich zusammengeführter Funktionszweige). Sie machen sich also keine Sorgen, dass Ihre Zweigstelle nicht mehr aktuell ist. Abhängig davon, was Ihr Team gerne behandelt: Entfernen zusammengeführter Hotfixes oder häufiges Umbasieren.

0
Aaron Jensen

Wenn Sie den Bug-Fix in Ihrem Feature-Zweig wirklich benötigen, fügen Sie den Bug-Fix-Zweig ein. Das Gespräch über Bisect / Rollback / Was auch immer FUD war - Bisect behandelt meiner Erfahrung nach komplizierte Zusammenführungs-Historien gut. Das in diesem Beitrag vorgeschlagene Modell führt zu künstlichen Problemen (wie zum Beispiel dem, über das Sie Fragen stellen), und der einzige Vorteil ist, dass die Geschichte sauberer aussieht . Wir haben dieses Modell ein paar Jahre lang verwendet, bevor wir den Nutzen der Nichtbasierung erkannt haben. Ich baue zurück, wenn ich meine eigene Geschichte bereinigen muss (Squash-Commits, Change-Commit-Nachrichten usw.), aber nur das wirkt sich auf niemanden anderen Downstream aus (wenn ich beispielsweise am Zweig solo arbeite).

Verwandte Probleme