Eine der Kernfunktionen von Git ist die Möglichkeit, mehrere Versionen Ihres Projekts. Diese werden oft für kurzfristige Verzweigungen verwendet, die als “Feature-Branches” die in Master zusammengeführt werden. Manchmal ist es jedoch notwendig, wirklich separate Zweige zu haben, was es schwieriger macht, sie synchron zu halten.
Warum verschiedene Zweige pflegen?
Normalerweise sind Branches kurzlebig und sollen wieder in den Hauptversionszweig zusammengeführt werden. In einigen Fällen ist es jedoch erforderlich, vollständig separate Zweige zu unterhalten. Zum Beispiel können Sie Branches haben, die auf verschiedene Plattformen oder Abhängigkeiten mit unterschiedlichen Funktionen abzielen, oder nur separate Release-Branches, die Sie eine Weile am Leben halten.
Dies ist der gleiche Workflow mit den meisten Forks und abhängig von der Umfang und Schwere der Änderungen kann es schwierig sein, mit dem Upstream synchron zu bleiben. Wenn Ihre beiden Branches weitgehend synchron sind, abzüglich einiger Commits, wird es Ihnen viel leichter fallen, mit Konflikten umzugehen und die Dinge auf dem neuesten Stand zu halten.
In den meisten Fällen sollten Sie jedoch nach Alternativen zum Trennen von Zweigen suchen, da dies insbesondere bei Zusammenführungskonflikten und all den zusätzlichen Tests ziemlich mühsam werden kann. Wenn Sie beispielsweise zwei Builds haben, die auf unterschiedliche Plattformen abzielen, verfügen viele Sprachen über eine Build-Konfiguration und Präprozessoren, die damit umgehen können. C# hat #if NETVERSION, was Änderungen am Code ermöglicht, je nachdem, für welche Plattform es kompiliert wird.
Aus welchem Grund auch immer, dies ist ein gültiger Git-Workflow, den viele Leute verwenden.< /p>
Zweige mit Rebasing synchron halten
Grundsätzlich gibt es zwei Möglichkeiten dafür. Die erste und gebräuchlichste Methode ist das Rebasing, das dem Zusammenführen sehr ähnlich ist, es den Zweigen jedoch ermöglicht, vollständig unabhängig zu sein.
Werbung
Sie können sich Git-Commits wie eine Kette von Änderungen vorstellen, die in der Zeit zurückgehen, wobei jede auf den vorherigen Commit verweist. Wenn Sie einen neuen Zweig erstellen, bricht er an einer bestimmten Stelle vom Haupt-Master-Zweig ab, der Basis des Zweigs.
Beim Rebasing wird im Grunde der gesamte Feature-Zweig angehoben und an einen neuen Zeitpunkt verschoben, an dem das Ende auf eine andere Kette von Commits hinweist. Dies ist am nützlichsten, wenn der verzweigte Zweig nur wenige Commits enthält, da dann die Merge-Konflikte leichter zu lösen sind. In diesem Beispiel beinhaltet das Rebasing dieses Branchs die B- und C-Commits, aber nicht D und E, da es nicht auf den HEAD des Branchs umbasiert werden muss.
Rebasing wird jedoch häufig nur für lokale Zweigstellen verwendet und bereitet einige Probleme, wenn sie mit gemeinsam genutzten Zweigstellen verwendet wird. Die Commits bewegen sich nicht wirklich; sie werden kopiert, was zu neuen Commit-IDs führt, wobei der HEAD des Branchs an den neuen Ort verschoben wird.
Dies bedeutet, dass die alten Commits gestrandet bleiben. Da Git ein dezentralisiertes Versionskontrollsystem ist, können Ihre Mitarbeiter ungepushte Commits haben, die auf diese gelöschten Commits verweisen. Das Rebasing muss etwas sein, das Sie mit allen Mitarbeitern koordinieren, und wenn jemand Konflikte hat, muss er diese lokal beheben, indem er diese Änderungen an den richtigen Ort kopiert.
Einen Zweig umzubasieren ist ziemlich einfach. Sie müssen den Feature-Branch auschecken, alle Änderungen von Ihrer Fernbedienung abrufen und dann rebase <branch> um den Feature-Branch in den Ziel-Branch zu verschieben.
git checkout-Funktion git pull git rebase master Werbung
Dies führt wahrscheinlich zu Zusammenführungskonflikten, die du selbst lösen und dann die Änderungen festschreiben musst.
Während die meisten alltäglichen Git-Aufgaben ziemlich einfach über die Befehlszeile erledigt werden können, ist das Rebasing von Natur aus eine ziemlich visuelle Operation, daher empfehlen wir, wenn möglich, einen GUI-Git-Client wie Fork oder GitKraken zu verwenden. Dies zeigt Ihnen die Zweiglinien und hilft Ihnen, das Rebase effektiver zu planen, und kann sogar interaktive Rebases durchführen.
Da das Rebasing grundsätzlich jeden Commit aus dem Feature-Zweig an einem neuen Ort anwendet, müssen Sie nicht alle einschließen, und interaktives Rebasing kann Commits löschen, die Sie nicht verwenden’ ;t brauchen. Dies ist über die Befehlszeile möglich, aber über eine grafische Benutzeroberfläche sinnvoller.
Unerwünschte Commits beheben
Was passiert, wenn Sie beim Rebase einige Commits nicht einschließen möchten? Wenn Sie Commits in Ihrem Feature-Branch haben, die Sie beim Rebasing auf den Master ausschließen möchten, können Sie ein interaktives Rebase durchführen. Dadurch werden die unerwünschten Commits beim Rebasing gelöscht und im Wesentlichen aus dem Verlauf entfernt.
Es ist jedoch viel wahrscheinlicher, dass Commits im Master-Branch vorhanden sind, die Sie lieber nicht in Ihrem Feature-Branch haben möchten. Da das Rebasing die Basis des neuen Branch auf master setzt, gibt es keine Möglichkeit, diese Commits nicht einzuschließen.
Wenn es nur ein oder zwei Commits gibt, die Sie gerne hätten Um nicht zu haben, können Sie wahrscheinlich trotzdem ein Rebase durchführen und es entweder im Merge-Konflikt aussortieren, manuell beheben oder den Commit einfach rückgängig machen. Git hat eine “Revert” Befehl, der die gegenteiligen Änderungen anwendet, einen Commit im Wesentlichen rückgängig macht und ihn so macht, als wäre er nie passiert. Führen Sie dazu git log aus, um den Commit zu finden, den Sie rückgängig machen möchten:
Kopieren Sie dann den SHA1-Hash und kehren Sie den Commit zurück:
git revert 62ee517cc7c358eafbbffdebdde1b38dea92aa0f Werbung
Dadurch wird ein “Revert Commit” im Feature-Branch.
Cherry-Picking-Commits auf einen anderen Branch
Das letzte Szenario, auf das Sie möglicherweise stoßen, ist, wenn nur wenige Commits vom Master vorhanden sind, die Sie in der Funktion haben möchten. Dies ist üblich, wenn Sie Branches für verschiedene Versionen verwalten, da häufig Hotfixes und Patches auf ältere Softwareversionen angewendet werden müssen.
Dies ist jedoch die nervigste Methode, Dinge zu synchronisieren , denn wenn Sie Ihre Branches nicht zumindest etwas synchron halten, besteht eine hohe Wahrscheinlichkeit, dass der Commit, den Sie einschließen möchten, mit dem älteren Branch nicht kompatibel ist.
Git verfügt jedoch über Tools, um Commits im Wesentlichen zu kopieren und in einen anderen Branch einzufügen. Diese Aktion wird Rosinenpicking genannt, weil Sie einen einzelnen Commit aus dem Verlauf holen und ihn herausnehmen. Ähnlich wie beim Rebasing erstellt das Rosinenpicken neue kopierte Commits, aber Git ist normalerweise schlau genug, um es zu sortieren, selbst wenn Sie die Branches später zusammenführen würden.
Zur Rosinenpickerei müssen Sie die Commit-ID abrufen. Wenn Ihr Branch-Verlauf kompliziert ist, können Sie git log mit der Option –graph ausführen, um eine visuelle Darstellung Ihres Verlaufs zu erhalten, obwohl ein GUI-Client für Aufgaben wie diese besonders nützlich ist.
git log –pretty=format :”%h %s” –graph
Stellen Sie dann sicher, dass Sie& #8217;befinde dich im Feature-Zweig und führe Cherry-Pick mit der Commit-ID aus, um sie zu kopieren.
git checkout-Funktion git Cherry-pick 1da76d3 Werbung
Dies kann zu Konflikten führen, die du muss sich lösen.