Ich habe dieses Szenario, das ich nicht für ungewöhnlich halte, aber ich bemühe mich, ein Beispiel dafür zu finden, wie es im Internet richtig gemacht wird.
Wir haben unser Projekt mit einer Masterfiliale. In meinem Beispiel nehmen wir an, dass der aktuelle Status des Masters v1.5.0 des Projekts identifiziert.
Jetzt entscheiden wir uns, v2.0.0 zu schreiben, auf die massive Änderungen und Neuschreibungen folgen, Dateien werden komplett entfernt und gelöscht. Dieses Umschreiben findet nun auf einem neuen Zweig statt, den wir unstable nennen werden.
Eine Woche oder so in die Entwicklung auf unstable ein Feature und / oder ein Bugfix muss v1.5.0 hinzugefügt werden, kein Problem, wir sagen neue Zweig - schreiben Feature - mit dem Master zusammenführen. Der Master ist jetzt auf v1.6.0.
Nun gilt diese Korrektur / Funktion nicht für die neue Version des Projekts, da das gesamte Projekt neu geschrieben wird.
Wir vervollständigen v2.0.0 im unstable Zweig, der ursprünglich auf v1.5.0 des master Zweigs basiert, was jetzt zu sagen ist ... v1.8.4 - Wie würden Sie den unstable-Zweig mit dem Master-Zweig zusammenführen, ohne: den Verlauf der Versionen 1.5 bis 1.8.4 zu zerstören oder Artefakte von Versionen vor 2.0.0 im zusammengeschlossenen Zweig zu belassen und möglicherweise den in v2.0.0 geschriebenen neuen Code zu brechen ?
Wahrscheinlich kennen Sie git merge -s ours genau, was genau das Gegenteil von dem ist, was Sie tun möchten: Es ignoriert die Änderungen im Zweig source und lässt das Ergebnis der Zusammenführung genau identisch mit dem Inhalt von Der Ziel Zweig. Aus Gründen, auf die ich hier nicht eingehen werde, gibt es kein entsprechendes -s theirs .
Also müssen wir etwas improvisieren, das die gleiche Wirkung hat. Grobe Umrisse: Führen Sie eine Zusammenführung durch, ohne zu committen, fügen Sie den 2.0.0-Code magisch hinzu und schließen Sie dann die Zusammenführung ab.
Zunächst sollten Sie sicherstellen, dass Sie keine Änderungen ohne Commit haben. Wir werden hier lustige Tricks anwenden; Garantie ungültig und all das.
git merge -n unstable . Die -n stellt sicher, dass die Zusammenführung noch nicht festgeschrieben ist, selbst wenn keine Konflikte vorliegen (natürlich werden Sie Konflikte aufgrund Ihrer umfangreichen Umschreibungen bekommen, aber seien Sie sicher). git read-tree --reset -u unstable (lies unstable in den Index und aktualisiere den Arbeitsbaum entsprechend, ignoriere alle Konflikte) git commit , um die Zusammenführung abzuschließen. Es wird nun sowohl alte als auch neue in seiner Geschichte haben, aber nur 2.0.0 Sachen in der Struktur . Es geht darum, wie man mit stark divergierenden Branchen umgeht. Es gibt ein paar Optionen hier:
master seit unstable divergiert wurden, und rekodieren Sie diese. Dies ist der Fall, wenn Sie erkennen, dass die Divergenz zwischen den Zweigen zu groß ist und das Zusammenführen keinen Sinn ergibt. Sie können jedoch immer noch die Commits auswählen, die noch gelten. Sie sollten besser einen separaten Issue-Tracker haben, der die Dinge auflistet, die seit der Verzweigungstrennung auf master angewendet wurden. Beachten Sie, dass Rebase keine Option ist, weil master branch bereits veröffentlicht wurde.
Nebenbei bemerkt, ein sehr interessantes Projekt ist in der Betaversion, aber es sieht brauchbar aus: git-imerge . Dieses Projekt ermöglicht es, Commits einzeln zusammenzuführen und Konflikte zu lösen, die viel kleiner sind.
Tags und Links git