Ich arbeite an einem Team mit einer großen Java-Codebasis (300.000 Zeilen Code), die kürzlich Git als Quellcodeverwaltung (von ClearCase migriert) übernommen hat. Wir verwenden Git Flow als unsere Verzweigungsstrategie. Es gibt ein paar Anwendungsfälle, auf die wir ziemlich häufig stoßen, mit denen wir zu kämpfen haben.
Wir haben all unsere Funktionen in den Entwicklungszweig integriert, der in einer kommenden Version verwendet werden soll. Wenn wir uns der Veröffentlichung nähern, stellt sich heraus, dass eine Funktion nicht verfügbar ist (entweder weil der Client nicht bereit ist oder aus einem anderen Grund). Was ist der beste Weg, um den Release Branch zu erstellen, aber ein bestimmtes Feature (über viele Commits hinweg) wegzulassen? Die Funktion muss verfügbar sein, um in der nächsten zukünftigen Version enthalten zu sein. Was wir vorher versucht haben, ist eine "git revert" für alle Commits zu machen, den Release Branch zu erstellen und dann ein "git revert" für die zurückgesetzten Commits zu machen. Dies ist ein ziemlich schmerzhafter Ansatz, insbesondere für große Funktionen.
Wir haben bereits den Release-Zweig erstellt, aber bevor das Release live geschaltet wird, muss bestimmt werden, dass ein Feature entfernt werden muss. Ähnlich wie beim ersten Anwendungsfall muss diese Funktion in der Lage sein, in eine folgende Version zu gelangen. Aus diesem Grund löst ein "git-revert" auf den Commits es nicht vollständig, da die Rückgaben in den Entwicklungszweig zurückgemischt werden, wenn wir einen "git flow release finish" machen.
Wie im Git Flow-Modell beschrieben, werden alle Commits in Feature-Verzweigungen und niemals direkt im Entwicklungszweig ausgeführt. Wenn eine Funktion abgeschlossen und für die nächste Version bereit ist, wird sie zur Entwicklung zusammengeführt. Wenn es Zeit für die nächste Veröffentlichung ist, wird der Release-Zweig von Entwicklung erstellt. Nachdem das Release regression getestet wurde und bei Bedarf korrigiert wurde, wird es in die Produktion übernommen und im Fall von Fehlerbehebungen mit dem Master zusammengeführt und zurückentwickelt und mit einer Versionsnummer versehen. Die oben genannten Probleme treten auf, wenn ein Feature, von dem wir dachten, dass es in der nächsten Version gehen wird, am Ende bleiben muss.
Was sind die besten Methoden, um mit diesen Situationen umzugehen? In beiden Szenarien wurden die Zweige von vielen Entwicklern veröffentlicht und heruntergerissen, so dass Probleme mit der Historie entstehen können. Ich weiß, dass dies alles andere als ideal ist, aber leider sind die Situationen außerhalb unserer Kontrolle.
In Git hat ein Merge-Commit zwei Dinge. Erstens erstellt es Zusammenführungsverlauf, so dass Git weiß, was zusammengeführt wurde und was nicht zusammengeführt wurde. Und zweitens verbindet es die Veränderungen aus zwei divergierenden Linien der Zusammenarbeit.
Du kannst Git in diesen beiden Dingen austricksen, so wie es sich anhört. Es gibt zwei Möglichkeiten, den Zusammenführungsverlauf zu erstellen, ohne die Änderungen zu übernehmen.
%Vor%und
%Vor%Ersteres erstellt ein Merge-Commit (und merge history), aber lßt alle Änderungen aus, die normalerweise zusammengeführt worden wären. Das spätere erstellt ein Merge-Commit (und merge history) und verschmilzt in den Änderungen, aber entfernt dann sofort alle Änderungen unter Beibehaltung der ersten Geschichte.
Wenn Sie in Ihrer Instanz etwas zusammenführen und später Ihre Meinung ändern, möchten Sie das zweite Formular verwenden und die Zusammenführungs-SHA wiederherstellen. Um die Änderungen aus dieser Zusammenführung nicht in einen anderen Zweig weiterzuleiten, sollten Sie das erste Formular verwenden. Beachten Sie, dass Sie, um das erste Formular effektiv zu verwenden, möglicherweise stattdessen jeweils einen SHA zusammenführen müssen (oder verwenden Sie nur einen zusätzlichen Feature-Zweig).
Stellen Sie sich vor, Sie haben eine Verzweigung trouble , die 6 Commits (1-6) enthält, und Sie müssen trouble in Master migrieren, aber Sie möchten die in Commit 4 eingeführten Änderungen nicht zusammenführen git merge trouble würden Sie tun
Tags und Links merge git version-control git-flow