Share
Verzweigungen vervielfachen die grundlegende Funktionalität, die Commits bieten, indem sie Benutzern erlauben, ihre Historie zu verzweigen. Das Erstellen eines neuen Zweigs ähnelt dem Anfordern einer neuen Entwicklungsumgebung mit einem isolierten Arbeitsverzeichnis, einem Bereitstellungsbereich und einem Projektverlauf.
Dies gibt Ihnen die gleiche Sicherheit wie eine "sichere" Kopie Ihres Projekts, aber Sie haben jetzt die zusätzliche Fähigkeit, an mehreren Versionen gleichzeitig zu arbeiten. Verzweigungen ermöglichen a nichtlinearer Workflow-die Fähigkeit, nicht verwandte Funktionen parallel zu entwickeln. Wie wir später erfahren werden, ist ein nichtlinearer Workflow ein wichtiger Vorläufer für das verteilte Wesen des Kooperationsmodells von Git.
Im Gegensatz zu SVN oder CVS ist die Zweigimplementierung von GIT unglaublich effizient. SVN ermöglicht Verzweigungen, indem das gesamte Projekt in einen neuen Ordner kopiert wird, ähnlich wie Sie es ohne Revisionssteuerungssoftware tun würden. Dies führt zu unbeholfenen, fehleranfälligen und langsamen Zusammenführungen. Im Gegensatz dazu sind Git-Zweige einfach ein Hinweis auf ein Commit. Da Git-Zweige auf der Festschreibungsebene und nicht direkt auf Dateiebene arbeiten, ist es viel einfacher, unterschiedliche Historien zusammenzuführen. Dies hat dramatische Auswirkungen auf die Verzweigungsworkflows.
Git trennt die Verzweigungsfunktionalität in einige verschiedene Befehle. Das Git-Zweig Befehl wird zum Auflisten, Erstellen oder Löschen von Zweigen verwendet.
In erster Linie müssen Sie Ihre vorhandenen Niederlassungen anzeigen können:
Git-Zweig
Dadurch werden alle Ihre aktuellen Zweige zusammen mit einem Sternchen neben dem derzeit "ausgecheckten" (mehr dazu später) ausgegeben:
* Meistere einige schnelle Fehlerbehebungen
Das Meister Branch ist Gits Standard-Zweig, der mit dem ersten Commit in einem beliebigen Repository erstellt wird. Viele Entwickler verwenden diesen Zweig als "Hauptgeschichte" des Projekts - ein permanenter Zweig, der alle wesentlichen Änderungen enthält, die er durchläuft.
Sie können einen neuen Zweig erstellen, indem Sie den Zweignamen an diesen übergeben Git-Zweig Befehl:
Git-Zweig
Dadurch wird ein Zeiger auf den aktuellen erstellt KOPF, aber tut nicht Wechseln Sie zum neuen Zweig (Sie benötigen git checkout dafür). Unmittelbar nach dem Anfordern eines neuen Zweigs sieht Ihr Repository in etwa wie folgt aus.
Ihre aktuelle Niederlassung (Meister) und die neue Branche (einige funktion) Beide verweisen auf dasselbe Commit, aber alle neuen Commits, die Sie aufzeichnen, sind exklusiv für den aktuellen Zweig. Auf diese Weise können Sie parallel an nicht verwandten Features arbeiten und gleichzeitig sinnvolle Historien beibehalten. Zum Beispiel, wenn Ihre aktuelle Niederlassung war einige funktion, Ihre Geschichte würde nach dem Festhalten eines Schnappschusses wie folgt aussehen.
Accentsconagua
einige funktion Ast Das neue KOPF (gekennzeichnet durch das hervorgehobene Commit) existiert nur im einige funktion Ast. Es wird nicht in der Protokollausgabe von angezeigt Meister, Die Änderungen werden auch nach dem Auschecken nicht im Arbeitsverzeichnis angezeigt Meister.
Sie können den neuen Zweig tatsächlich in der internen Datenbank sehen, indem Sie die Datei öffnen .git / refs / köpfe /. Die Datei enthält die ID des referenzierten Commits und ist die einzige Definition eines Git-Zweigs. Dies ist der Grund, warum Filialen so leicht und einfach zu handhaben sind.
Zum Schluss können Sie Zweige über löschen -d Flagge:
Git-Zweig -d
Das Engagement von Git, nie Ihre Arbeit zu verlieren, verhindert jedoch, dass Zweige mit nicht zusammengeführten Commits entfernt werden. Um das Löschen zu erzwingen, verwenden Sie die -D stattdessen kennzeichnen:
Git-Zweig -D
Nicht zusammengeführte Änderungen gehen verloren sei sehr vorsichtig mit diesem Befehl.
Natürlich ist das Erstellen von Zweigen ohne die Möglichkeit, zwischen ihnen zu wechseln, nutzlos. Git nennt dieses "Auschecken" einen Zweig:
git checkout
Nachdem Sie den angegebenen Zweig ausgecheckt haben, wird Ihr Arbeitsverzeichnis entsprechend dem Festschreiben des angegebenen Zweigs aktualisiert. zusätzlich KOPF wird aktualisiert, um auf den neuen Zweig zu verweisen, und alle neuen Commits werden auf dem neuen Zweig gespeichert. Sie können sich vorstellen, einen Zweig auszuchecken, als würden Sie zu einem neuen Projektordner wechseln. Es ist jedoch viel einfacher, Änderungen wieder in das Projekt zu übernehmen.
Aus diesem Grund ist es in der Regel eine gute Idee sauber Arbeitsverzeichnis vor dem Auschecken einer Filiale. Ein sauberes Verzeichnis ist vorhanden, wenn keine nicht festgeschriebenen Änderungen vorhanden sind. Wenn dies nicht der Fall ist, git checkout hat das Potenzial, Ihre Änderungen zu überschreiben.
Bei einer "sicheren" Revision können Sie mit einem neuen Zweig experimentieren, ohne befürchten zu müssen, dass vorhandene Funktionen zerstört werden. Sie haben jetzt jedoch eine spezielle Historie, mit der Sie arbeiten können, sodass Sie den Fortschritt eines Experiments genau aufzeichnen können git add und git begehen Befehle von früher im Buch.
Diese Funktionalität wird noch leistungsfähiger, wenn wir lernen, abweichende Historien wieder in den "Hauptzweig" (z., Meister). Wir werden gleich darauf eingehen, aber zuerst gibt es einen wichtigen Anwendungsfall von git checkout das muss bedacht werden ...
Git lässt Sie auch verwenden git checkout mit Tags und Commit-IDs, aber dies versetzt Sie in eine abgetrennter HEAD-Zustand. Das bedeutet, dass Sie sich nicht mehr in einem Zweig befinden - Sie sehen direkt ein Commit.
Sie können sich wie gewohnt umsehen und neue Commits hinzufügen. Da jedoch kein Zweig auf die Ergänzungen verweist, verlieren Sie Ihre gesamte Arbeit, sobald Sie wieder zu einem echten Zweig wechseln. Glücklicherweise erstellen Sie einen neuen Zweig in einem freistehenden KOPF Zustand ist leicht genug:
git checkout -b
Dies ist eine Abkürzung für Git-Zweig gefolgt von git checkout . Danach haben Sie einen glänzenden neuen Zweigverweis auf die zuvor freistehenden KOPF. Dies ist ein sehr praktisches Verfahren, um Experimente von alten Revisionen abzuwehren.
Beim Zusammenführen werden Commits von einem Zweig in einen anderen gezogen. Es gibt viele Möglichkeiten, Zweige zu kombinieren, aber das Ziel ist immer, Informationen zwischen Zweigen auszutauschen. Dies macht das Zusammenführen zu einer der wichtigsten Funktionen von Git. Die zwei häufigsten Zusammenführungsmethoden sind:
Beide verwenden den gleichen Befehl, git merge, Die Methode wird jedoch automatisch basierend auf der Struktur Ihrer Historie festgelegt. In jedem Fall, Der Zweig, in den Sie einbinden möchten, muss ausgecheckt sein, und der Zielzweig bleibt unverändert. In den nächsten beiden Abschnitten werden zwei mögliche Zusammenführungsszenarien für die folgenden Befehle vorgestellt:
git checkout master git einige Funktionen zusammenführen
Wieder verbindet dies die einige funktion verzweige in die Meister Zweig, der ehemalige bleibt unberührt. Sie führen diese Befehle normalerweise aus, wenn Sie eine Funktion abgeschlossen haben und sie in das Stable-Projekt integrieren möchten.
Das erste Szenario sieht folgendermaßen aus:
Wir haben einen Zweig für die Entwicklung einiger neuer Funktionen erstellt, zwei Commits hinzugefügt und können nun in die Hauptcodebasis integriert werden. Statt die beiden fehlgeschlagenen Commits neu zu schreiben Meister, Git kann das "vorspulen" Meister Der Zeiger des Zweigs, der der Position von entspricht einige funktion.
Nach der Verschmelzung die Meister Verzweigung enthält den gesamten gewünschten Verlauf, und der Zweig der Funktion kann gelöscht werden (es sei denn, Sie möchten ihn weiterentwickeln). Dies ist die einfachste Art der Zusammenführung.
Natürlich hätten wir die beiden Commits direkt auf der Website machen können Meister Ast; Die Verwendung eines dedizierten Funktionszweigs bot uns jedoch eine sichere Umgebung, um mit neuem Code zu experimentieren. Wenn es sich nicht als richtig herausstellte, hätten wir den Zweig einfach löschen können (im Gegensatz zum Zurücksetzen / Zurücksetzen). Wenn wir eine Reihe von Zwischencommits mit gebrochenem Code hinzufügen, könnten wir den Code bereinigen, bevor er ihn einfügt Meister (siehe unten). Da Projekte immer komplizierter werden und mehr Mitarbeiter gewinnen, macht Git diese Art der verzweigten Entwicklung zu einem fantastischen Organisationswerkzeug.
Aber nicht alle Situationen sind einfach genug für ein schnelles Vorwärtsgehen. Denken Sie daran, dass der Hauptvorteil von Branchen die Möglichkeit ist, viele unabhängige Entwicklungslinien gleichzeitig zu erkunden. Infolgedessen sehen Sie häufig ein Szenario, das wie folgt aussieht:
Dies begann wie eine Zusammenführung mit schnellem Vorlauf, aber wir haben ein Commit hinzugefügt Meister Zweig, während wir noch in der Entwicklung waren einige funktion. Wir hätten beispielsweise die Arbeit an der Funktion beenden können, um einen zeitkritischen Fehler zu beheben. Natürlich sollte der Bugfix so schnell wie möglich zum Haupt-Repository hinzugefügt werden, so dass wir in dem oben gezeigten Szenario landen.
Zusammenführen des Feature-Zweigs in Meister führt in diesem Zusammenhang zu einer "3-Wege" -Mischung. Dies geschieht mit den gleichen Befehlen wie beim Schnellvorlauf aus dem vorherigen Abschnitt.
Git kann das nicht vorspulen Meister Zeiger auf einige funktion ohne Backtracking. Stattdessen wird ein neues generiert Merge-Commit das ist die kombinierte Momentaufnahme beider Zweige. Beachten Sie, dass dieses neue Commit hat zwei Das übergeordnete Commit gibt ihm Zugriff auf beide Historien (in der Tat laufend) Git Log nach der 3-Wege-Zusammenführung zeigt Commits aus beiden Zweigen).
Der Name dieses Merge-Algorithmus stammt von der internen Methode, die zum Erstellen des Merge-Commits verwendet wurde. Git sieht zu drei verpflichtet sich, den Endzustand der Zusammenführung zu generieren.
Wenn Sie versuchen, zwei Verzweigungen zu kombinieren, die verschiedene Änderungen an demselben Codeteil vornehmen, kann Git nicht wissen, welche Version verwendet werden soll. Dies nennt man a Konflikt vermischen. Offensichtlich kann dies niemals während einer Schnellvorlauf-Zusammenführung passieren. Wenn Git auf einen Zusammenführungskonflikt stößt, wird folgende Meldung angezeigt:
Automatisches Zusammenführen von index.html CONFLICT (Inhalt): Konflikt in zusammenführenAutomatische Zusammenführung fehlgeschlagen; Konflikte beheben und das Ergebnis festschreiben.
Anstatt das Merge-Commit automatisch hinzuzufügen, hält Git an und fragt Sie, was Sie tun sollen. Laufen Git-Status In dieser Situation wird etwas wie das Folgende zurückgegeben:
# Auf Zweigmaster # Nicht zusammengeführte Pfade: # # Beide wurden geändert:
Jede Datei mit einem Konflikt wird im Abschnitt "Nicht zusammengeführte Pfade" gespeichert. Git annotiert diese Dateien, um den Inhalt beider Versionen anzuzeigen:
<<<<<<< HEAD This content is from the current branch. ======= This is a conflicting change from another branch. >>>>>>> einige Funktionen
Der Teil vor dem ======= ist aus dem Meister branch, und der Rest stammt von dem Zweig, den Sie integrieren möchten.
Um den Konflikt zu lösen, entfernen Sie die <<<<<<, =======, und >>>>>>> Notation, und ändern Sie den Code in das, was Sie behalten möchten. Dann sagen Sie Git, dass Sie den Konflikt mit gelöst haben git add Befehl:
git add
Stimmt; Alles, was Sie tun müssen, ist die in Konflikt stehende Datei in Szene zu setzen, um sie als aufgelöst zu markieren. Schließen Sie die 3-Wege-Zusammenführung ab, indem Sie das Zusammenführungs-Commit generieren:
git begehen
Die Protokollnachricht enthält eine Zusammenführungsbenachrichtigung sowie eine Liste mit "Konflikten", die besonders nützlich sein kann, wenn Sie herausfinden möchten, wo in einem Projekt etwas schiefgelaufen ist.
Und das ist alles, was man in Git mischen kann. Nachdem wir nun die Mechanismen hinter Git-Zweigen verstanden haben, können wir uns eingehend damit beschäftigen, wie erfahrene Git-Benutzer Zweige in ihrem täglichen Arbeitsablauf nutzen.
Die in diesem Abschnitt vorgestellten Arbeitsabläufe sind das Markenzeichen der Git-basierten Revisionskontrolle. Da Gits Filialimplementierung leicht und einfach zusammenzuführen ist, ist Git eines der produktivsten Werkzeuge in Ihrem Softwareentwicklungsarsenal.
Alle verzweigten Workflows drehen sich um die Git-Zweig, git checkout, und git merge Befehle, die zuvor in diesem Kapitel vorgestellt wurden.
Es ist oft nützlich, verschiedenen Zweigen eine spezielle Bedeutung zu geben, um ein Projekt zu organisieren. In diesem Abschnitt werden die gebräuchlichsten Arten von Verzweigungen vorgestellt. Beachten Sie jedoch, dass diese Unterschiede rein vordergründig sind. Git ist eine Verzweigung.
Alle Zweige können als kategorisiert werden permanent Geäst oder Zweigzweige. Ersteres enthält die Hauptgeschichte eines Projekts (z., Meister), während letztere temporäre Zweige sind, die zur Implementierung eines bestimmten Thema, dann verworfen (z., einige funktion).
Permanente Niederlassungen sind das Lebenselixier eines Endlagers. Sie enthalten alle wichtigen Wegpunkte eines Softwareprojekts. Die meisten Entwickler verwenden Meister ausschließlich für stabilen Code. In diesen Workflows können Sie noch nie direkt begehen Meister-Es ist nur ein Integrationszweig für abgeschlossene Funktionen, die in speziellen Zweigzweigen erstellt wurden.
Darüber hinaus fügen viele Benutzer eine zweite Abstraktionsebene in einem anderen Integrationszweig hinzu (herkömmlich als bezeichnet) entwickeln, aber jeder Name wird ausreichen). Das macht das frei Meister Zweig für Ja wirklich stabiler Code (z. B. öffentliche Commits) und Verwendungen entwickeln als interner Integrationszweig zur Vorbereitung auf eine öffentliche Veröffentlichung. Das folgende Diagramm zeigt beispielsweise mehrere Funktionen, die in integriert sind entwickeln, dann eine einzige, endgültige Verschmelzung Meister, was eine öffentliche Veröffentlichung symbolisiert.
Meister Zweig ausschließlich für öffentliche Veröffentlichungen Themenzweige lassen sich im Allgemeinen in zwei Kategorien einteilen: Feature-Zweige und Hotfix-Zweige. Feature-Verzweigungen sind temporäre Verzweigungen, die ein neues Feature oder einen neuen Refactor einkapseln und das Hauptprojekt vor nicht getestetem Code schützen. Sie stammen in der Regel aus einem anderen Funktionszweig oder einem Integrationszweig, nicht jedoch aus dem "superstabilen" Zweig.
Hotfix-Zweige sind von Natur aus ähnlich, stammen jedoch aus dem öffentlichen Veröffentlichungszweig (z., Meister). Anstatt neue Funktionen zu entwickeln, dienen sie zum schnellen Patchen der Hauptentwicklungslinie. In der Regel bedeutet dies Fehlerbehebungen und andere wichtige Updates, die nicht bis zur nächsten Hauptversion warten können.
Meister mit einem Hotfix-Zweig Wiederum sind die Bedeutungen, die jedem dieser Zweige zugewiesen werden, rein konventionell - Git sieht keinen Unterschied zwischen Meister, entwickeln, Features und Hotfixes. Fürchte dich nicht davor, sie an deine eigenen Zwecke anzupassen. Das Schöne an Git ist seine Flexibilität. Wenn Sie die Mechanismen von Git-Filialen verstehen, können Sie ganz einfach neue Workflows entwerfen, die zu Ihrem Projekt und Ihrer Persönlichkeit passen.
Neueinstellung ist der Vorgang, bei dem ein Zweig zu einem neuen verschoben wird Base. Die Umbasierungsfunktionen von Git machen die Filialen noch flexibler, da Benutzer ihre Filialen manuell organisieren können. Wie das Zusammenführen, Git Rebase erfordert, dass der Zweig ausgecheckt ist, und nimmt die neue Basis als Argument an:
git checkout git rebase master mit einigen Funktionen
Das bewegt das Ganze einige funktion Verzweigen Sie auf die Spitze von Meister:
einige funktion auf die Meister Ast Nach der Neubasis ist der Funktionszweig a lineare Ausdehnung von Meister, Dies ist eine viel sauberere Möglichkeit, Änderungen von einem Zweig in einen anderen zu integrieren. Vergleichen Sie diese lineare Geschichte mit einer Verschmelzung von Meister in einige funktion, was genau die gleiche Codebasis im letzten Snapshot ergibt:
Meister in einige funktion mit einer 3-Wege-Verbindung Da die Geschichte auseinandergegangen ist, muss Git ein zusätzliches Merge-Commit verwenden, um die Zweige zu kombinieren. Wenn Sie dies während der Entwicklung einer langwierigen Funktion viele Male ausführen, kann dies zu einer sehr unordentlichen Geschichte führen.
Diese zusätzlichen Merge-Commits sind überflüssig - sie existieren nur, um Änderungen herbeizuführen Meister in einige funktion. Normalerweise möchten Sie, dass Ihre Zusammenführungs-Commits ausgeführt werden bedeuten so etwas wie die Fertigstellung einer neuen Funktion. Aus diesem Grund ziehen viele Entwickler Änderungen mit ein Git Rebase, da dies zu einer vollständig linearen Historie im Feature-Zweig führt.
Interaktives Umbasieren geht noch einen Schritt weiter und ermöglicht es Ihnen Veränderung begeht, wenn Sie sie auf die neue Basis verschieben. Mit können Sie eine interaktive Basis festlegen -ich Flagge:
Git rebase -i Meister
Dies füllt einen Texteditor mit einer Zusammenfassung jedes Commits im Feature-Zweig sowie einem Befehl, der bestimmt Wie es sollte auf die neue Basis übertragen werden. Wenn Sie beispielsweise zwei Commits für einen Feature-Zweig haben, können Sie eine interaktive Basisstation wie folgt angeben:
pick 58dec2a Erstes Commit für neues Feature squash 6ac8a9f Zweites Commit für neues Feature
Der Standard auswählen Der Befehl verschiebt den ersten Commit wie üblich auf die neue Basis Git Rebase, aber dann die quetschen Befehl befiehlt Git, das zweite Commit mit dem vorherigen zu kombinieren, so dass Sie ein Commit mit all Ihren Änderungen erhalten:
einige funktion Ast Git bietet mehrere interaktive Umbasierungsbefehle, von denen jeder im Kommentarabschnitt der Konfigurationsliste zusammengefasst ist. Der Punkt ist interaktives Umbasieren lässt Sie vollständig Schreiben Sie die Historie einer Branche nach Ihren genauen Vorgaben. Dies bedeutet, dass Sie beliebig viele Zwischen-Commits zu einem Feature-Zweig hinzufügen können. Anschließend können Sie zurückgehen und sie anschließend in einen sinnvollen Verlauf bringen.
Andere Entwickler werden denken, dass Sie ein brillanter Programmierer sind und genau wissen, wie Sie das gesamte Feature auf einen Schlag implementieren können. Diese Art der Organisation ist sehr wichtig, um sicherzustellen, dass große Projekte eine navigierbare Geschichte haben.
Die Neueinstellung ist ein mächtiges Werkzeug, aber Sie müssen beim Umschreiben der Geschichte umsichtig sein. Beide Arten der Umbasierung finden eigentlich nicht statt Bewegung bestehende Zusagen erstellen brandneue (im obigen Diagramm durch ein Sternchen gekennzeichnet). Wenn Sie Commits überprüfen, die einer Rebase unterzogen wurden, werden Sie feststellen, dass sie unterschiedliche IDs haben, obwohl sie denselben Inhalt repräsentieren. Dies bedeutet Umbasierung zerstört Bestehende Commits im Prozess des "Verschiebens".
Wie Sie sich vorstellen können, hat dies dramatische Folgen für kollaborative Workflows. Zerstörung eines öffentlichen Commits (z. B. irgendetwas auf der Meister Niederlassung) ist, als würde man die Grundlage der Arbeit aller anderen ausreissen. Git hat keine Ahnung, wie man die Änderungen aller zusammenbringt, und man muss sich sehr entschuldigen. Wir werden dieses Szenario eingehender betrachten, nachdem wir gelernt haben, wie Sie mit entfernten Repositorys kommunizieren.
Halten Sie sich zunächst an die goldene Regel der Umbasierung: Verändern Sie niemals einen Zweig, der in ein öffentliches Repository verschoben wurde.
Diese Lektion repräsentiert ein Kapitel aus Git Erfolgreich, ein kostenloses eBook aus dem Team von Syncfusion.
