GitFlow: Entwicklungsänderungen sicher mit einem Feature-Branch zusammenführen

Vor kurzem habe ich angefangen, an einem großen Feature zu arbeiten, also habe ich ein neues erstellt feature/xyz Zweig. Das Problem ist, dass diese Funktion groß ist, also werde ich ungefähr 3 Monate brauchen, um sie fertigzustellen. Ich möchte Fortschritte, die in gemacht wurden, sicher zusammenführen develop zu meinem Feature-Zweig, ohne sich Gedanken darüber zu machen, dass sich das ändert develop branch überschreibt Aktualisierungen, die ich bereits in meinem Feature-Branch vorgenommen habe. Mein vorheriger Versuch zu verschmelzen develop zu feature/xyz führte dazu, dass einige Änderungen, die ich bereits in der neuen Funktion vorgenommen hatte, rückgängig gemacht wurden.

Was wäre der Befehl, um dies zu erreichen? Vielen Dank

Die einzige Sicherheit liegt in gelehrten, anspruchsvollen und häufigen Zusammenführungen.

Nur Sie verstehen, wie der Code weitergeht develop und feature/xyz richtet sich aus, sonst niemand. Nur Sie selbst können die beiden Strömungen auf differenzierte Weise richtig zusammenführen. Auch mit den standardmäßigen Zusammenführungsstrategien, die weit weniger gefährlich sind als -S ours oder -X theirs Sie müssen das Ergebnis immer noch überprüfen.

Möglicherweise benötigen Sie natürlich etwas Hilfe, und git wird Ihnen welche anbieten. Beispielsweise können Sie mit Git aufgezeichnete Auflösungen verwenden – rerere um Ihnen dabei zu helfen, die gleiche richtige Zusammenführungsentscheidung zu treffen, nachdem Sie ursprünglich eine getroffen haben.

Ein ziemlich verbreitetes und relativ einfaches Modell, das die Namen verwendet, die Sie für die Zweige angegeben haben, könnte für Sie wie folgt funktionieren:

• develop ist die Branche, in der die Entwicklungsschwerpunkte liegen
• xyz ist der Zweig, in dem Sie das Feature xyz entwickeln
• xyz_stage ist der Zweig, in dem Sie die zusammenführen develop und die xyz Code, wobei dieser Zweig in Übereinstimmung mit den jeweiligen stabilen Punkten von stabil gehalten wird develop und xyz. Dies ist auch der Branch, den Sie schließlich wieder in den Develop-Branch zusammenführen würden, wenn Sie bereit sind, Feature xyz oder einen Teil davon zu veröffentlichen.

Das Obige setzt voraus, dass nicht nur Sie fusionieren xyz hinein xyz_stage aber dass Sie auch verschmelzen develop hinein xyz_stage von Zeit zu Zeit und stellen Sie sicher, dass die Portionen xyz bisher freigegeben xyz_stage arbeiten und bestehen die entsprechenden Tests in Verbindung mit dem Code aus develop.

Trotzdem müssen Sie sich noch entscheiden, wie Sie das machen xyz Zweig, wo Sie an der Funktion arbeiten und den Entwicklungsfortschritt verfolgen.

Die sauberste Option ist – nicht bewusst machen. Deshalb hast du xyz_stage wo die beiden Entwicklungsströme zusammentreffen. Dieser Ansatz ist machbar und vernünftig, solange die Entwicklung von xyz wird nicht verlängert.

Die zweite Möglichkeit ist das Zusammenführen xyz_stage zurück in xyz wenn Sie mit dem Staging-Zweig zufrieden sind. Auf diese Weise haben Sie einen stabilen Punkt, den Sie fortsetzen und weiterentwickeln können xyz Funktion oben.

Hier ist eine einfache Illustration des Prozesses mit Kommentaren:

Meiner Erfahrung nach besteht die einzige “sichere” Lösung darin, das Ergebnis einer Zusammenführung immer manuell zu überprüfen und zu testen. –no-commit wird die Zusammenführung inszenieren und Sie können sie vor dem Festschreiben überprüfen, oder Sie können sie zurücksetzen/ändern, was immer praktischer erscheint. Ein Drei-Wege-Merge-Tool zu bekommen, kann sehr hilfreich sein. Es gibt einfach zu viele Möglichkeiten, wie Dinge kaputt gehen können, ohne dass es zu Merge-Konflikten kommt, dass das Verlassen auf automatisches Mergen Sie zwangsläufig in Schwierigkeiten bringen wird. Wenn Sie eine 100-prozentige Testabdeckung haben, können Sie sicher etwas entspannter sein, aber wie viele Projekte können das wirklich von sich behaupten? 😉

Verwenden git merge -s recursive -X ours. Dadurch werden Konflikte in den beiden Zweigen immer mit der Version im ausgecheckten Verzeichnis (feature/xyz in diesem Fall).

Wichtig: entgegen Ihrer Überschrift, diese Strategie ist nicht unbedingt “sicher”: die Modifikationen von develop könnte die in widersprechen feature/xyz. Stellen Sie wie immer sicher, dass Sie die zusammengeführten Änderungen ordnungsgemäß testen.