Was wäre der bevorzugte Weg, um den folgenden Workflow mit Git oder Subversion zu erreichen (Ich habe mehr Interesse an der Git Version, aber der Vergleich wird definitiv nützlich sein):
Nehmen wir an, wir hatten kürzlich eine größere Version des Produkts und es gibt einen speziellen Polisin-Zweig namens release-2.0.x .
Die Entwicklung wurde dann fortgesetzt und mehrere Feature-Zweige wurden in
master/trunkzusammengeführt (sie werden später zum Teil des kommendenrelease-2.1.x).
Nun wurde irgendwann ein anderes Feature (nämlich critical-feature ) entwickelt und wieder mit master/trunk zusammengeführt. Wir wissen, dass diese Funktion so wichtig ist, dass wir sie in release-2.0.x zurückversetzen müssen.
Hier ist eine kleine Pseudo-Illustration für den beschriebenen Fall. Beachten Sie, dass alles oben Baum Unterschiede zwischen release-2.0.x und aktuelle master/trunk bringt und zu Problemen führt (sonst könnte ich einfach die critical-feature zusammenführen und vermeiden diese Frage zu schreiben:)
Was wäre der beste Weg, die Rückportierung der Funktionen aus der Perspektive VCS durchzuführen?
Sollte dies als einfaches merge des entsprechenden critical-feature -Verzweigs mit Konfliktreliminierungskonflikten geschehen?
Oder sollte dies als cherry-pick des Commits gemacht werden, das die critical-feature in master/trunk zusammenführt, wenn es fertig ist? Oder vielleicht sogar als eine Menge von cherry-picks für jedes Commit im Zweig critical-feature ?
Können Sie etwas für das Konfliktlösungsverfahren empfehlen? Was sollte man tun, wenn der aktuelle Unterschied zwischen release-2.0.x und master/trunk so groß ist, dass "naives" Backporting zu einer großen Menge an Konflikten aufgrund von Code-Refactoring und fehlenden Features oder API führt, die nach dem% hinzugefügt wurden co_de%?
Bietet release-2.0.x oder Git etwas Bestimmtes für diese Routine außer dem Standard-Merging- oder Cherry-Picking-Ansatz? Ich denke, dass Rebasing nicht hilfreich sein wird, wenn die Menge an Konflikten groß ist, aber offensichtlich kann ich falsch liegen.
Die ganze Idee, Features rückzuportieren, sieht für mich kaputt aus. Nur kritische und nicht destruktive Änderungen sollten rückportiert werden. Für Features und Verbesserungen müssen Sie einen neuen Zweig erstellen und den Stabilisierungszeitraum starten.
Überprüfen Sie den Release-Prozess, der im Apache Subversion-Projekt selbst verwendet wird: Ссылка
Es kommt darauf an. Wenn das kritische Merkmal relativ einfach und klein ist, könnten Sie einfach mehrere Cherry-Picks machen. Allerdings könnte es natürlich viele Zusammenführungskonflikte verursachen, da die Implementierung des Features den refaktorierten Code verwenden könnte. Wie ich jedoch verstehe, wird es die einfachste Lösung sein. Und nur eine Lösung für SVN.
Diese Lösung spiegelt jedoch keine Aktionen im Verlaufsdiagramm wider, sondern verwirrend.
Mit git gibt es eine weitere Option, das kritische Feature neu zu installieren in der merge-base des Masters und des release-2.0.x Geäst. Es bedeutet wörtlich, dass Sie die Funktion mit altem Code, der für beide Zweige üblich ist, neu implementieren sollten. In diesem Fall könnten Sie das rebased Feature zusammenführen. Wenn Sie das Feature bereits mit dem Master zusammengeführt haben, wenn Sie das Feature rebased in den Master migrieren, wird höchstwahrscheinlich ein Konflikt auftreten (da Master bereits über eine solche Implementierung verfügt). So werden Sie Konflikte lösen, aber in den meisten Fällen wird es einfach sein, denn Änderungen sollten fast die gleichen sein.
Der Vorteil des rebased-Feature-Ansatzes besteht darin, dass Sie einen Fehler im Feature-Zweig beheben und Fixes problemlos in die Release- und Master-Zweige zusammenführen könnten.
Natürlich könnte das Rebasieren eine Menge Konflikte verursachen, aber es bedeutet, dass es keine einfache Möglichkeit gibt, das Feature in release-2.0.x zu portieren. Vielleicht wäre es einfacher, es einfach neu zu implementieren.
Ich habe einige Tools speziell entwickelt, um diesen Prozess mit git zu vereinfachen, und letzte Woche schrieb ich einen ausführlichen Blogpost über sie. Insbesondere kann der Befehl git cherry-menu , auf den in diesem Beitrag verwiesen wird, eine willkürliche Liste von Commits für Backport akzeptieren. Mit git log und Ihrem bevorzugten Texteditor können Sie also eine einigermaßen sorgfältig ausgewählte Liste von Commits erstellen, die das kritische Feature darstellen rückportiert und dann etwas wie folgt ausgeführt:
Dies ist vergleichbar mit dem kan-s-Vorschlag, abgesehen davon, dass der Backporting-Prozess strukturierter ist, und indem Sie Git-Notizen unter der Haube verwenden, erhalten Sie einige nützliche zusätzliche Funktionen, einschließlich dass alle Metadaten, die den Prozess beschreiben, über mehrere Läufe bestehen bleiben von git cherry-menu .
Natürlich, wenn Sie nur eine Handvoll Commits zum Backport haben, hat kan Recht, dass Sie auch einfach direkt per Mausklick auswählen können.
Leider denke ich, dass die akzeptierte Antwort leicht widersprüchlich ist:
Die ganze Idee von Backporting-Funktionen sieht für mich kaputt aus. Nur kritische und nicht destruktive Änderungen sollten rückportiert werden. Für Features und Verbesserungen müssen Sie einen neuen Zweig erstellen und den Stabilisierungszeitraum starten.
weil das Erstellen eines neuen Zweiges und das Starten eines Stabilisierungszeitraums immer noch rückportiert wird. Der einzige Unterschied ist, in welchen Zweig Sie die zurückportierten Commits einfügen! Sie können sie entweder in den ursprünglichen release-2.0.x Zweig einfügen oder einen anderen Zweig abzweigen, wie den oben angegebenen release-2.0.y Zweig. Es ist im Allgemeinen sicherer / sauberer, Letzteres zu tun (und ich denke, das ist Ivans Argument), aber das hängt wirklich davon ab, wie Sie Ihre Repositories und Filialen organisieren. Es vermeidet jedoch nicht die Notwendigkeit, Rosinenpicken und eine mögliche Konfliktlösung durchzuführen.
Tags und Links merge git svn merge-conflict-resolution feature-branch