Wenn Sie 2018 Software für Ihren Lebensunterhalt schreiben, kann ich mit Zuversicht sagen, dass Sie mit Git vertraut sind Das von Linus Torvalds entwickelte Tool ist zum Synonym für Versionskontrolle geworden. Ohne Zweifel ist eine der besten Funktionen von Git, wie es den Schmerz des Verzweigens und Zusammenführens beseitigt. Es gibt verschiedene Möglichkeiten, einen Zweig in Git zu erstellen. In diesem Beitrag werden wir einige davon überprüfen. Dann werden wir mit einer kleinen Reflexion über das Verzweigungsmodell von Git und die Verzweigung im Allgemeinen enden.

Erstellen einer Verzweigung vom Master

Es ist nicht überraschend, dass Sie Zweige in Git mit dem Befehl branch erstellen. Wie viele andere Git-Befehle ist „branch“ sehr leistungsfähig und flexibel. Neben dem Erstellen von Zweigen können damit auch Zweige aufgelistet und gelöscht und weitere Anpassungen vorgenommen werden den Befehl durch Verwendung einer breiten Liste von Parametern. Wir beginnen mit der ersten Möglichkeit, einen Zweig zu erstellen. Nehmen wir an, Sie möchten einen neuen Ordner mit dem Namen „my-app“ erstellen, ihn eingeben und ein neues Git-Repository starten. Genau so würden Sie es tun:

mkdir my-appcd my-appgit init

Jetzt haben Sie ein neues, leeres Git-Repository. Leere Repositorys sind jedoch langweilig. Wie wäre es also mit dem Erstellen einer neuen Markdown-Datei mit „Hello World!“?

echo Hello World! > file.md

Wenn Sie „git status“ ausführen, sollte eine Meldung angezeigt werden, dass Ihre Datei nicht verfolgt wird:

Nicht verfolgte Dateien sind jedoch auch uncool. Verfolgen wir sie also:

git add file.md

Und schließlich erstellen wir unsere Erstes Commit:

git commit -m "First commit"

Wir haben jetzt ein Repository mit einem Zweig, das genau ein Commit hat. Das klingt möglicherweise nicht nach dem Das Aufregendste auf der Welt (weil es wirklich nicht „t“ ist), aber es ist sicherlich weniger langweilig als ein Repo ohne Commits, oder? Sagen wir jetzt, aus welchem Grund auch immer Sie die Datei ändern müssen „s Inhalt. Aber du nicht Lust dazu. Was ist, wenn etwas schief geht und Sie den schönen, makellosen Inhalt Ihrer Datei irgendwie verderben? (Ja, ich weiß, es ist nur eine blöde Datei mit „Hello World!“, Aber nutzen Sie die wunderbaren Kräfte Ihrer Vorstellungskraft und betrachten Sie die Datei als Proxy für ein viel komplexeres Projekt.) Die Lösung für dieses Dilemma erstellt natürlich einen neuen Zweig:

git branch exp

Jetzt haben wir einen neuen Zweig namens „exp“ zum Experimentieren Einige Leute, die es gewohnt sind, verschiedene Versionsverwaltungssysteme zu verwenden, insbesondere zentralisierte, könnten sagen, dass die Zweige den gleichen „Inhalt“ haben. Dies ist jedoch nicht ganz richtig, wenn es um Git geht. Stellen Sie sich Zweige wie Verweise vor, die auf ein bestimmtes Commit verweisen.

Erstellen eines Zweigs aus einem Commit

Nehmen wir an, wir geben unser Experiment aus irgendeinem Grund auf, ohne ein einziges hinzuzufügen Commit für die neue Niederlassung. Kehren wir zum Master zurück und löschen den exp-Zweig:

git checkout mastergit branch -d exp

Nachdem wir nun zu einem einzelnen Zweig zurückgekehrt sind, Fügen wir einige Commits hinzu, um die geleistete Arbeit zu simulieren:

Stellen Sie sich vor, dass Sie nach all dieser „Arbeit“ lernen, dass Sie aus irgendeinem Grund in der Zeit zurückgehen müssen, in der Sie sich befinden waren nur zwei Zeilen in der Datei und erstellen von da an neue Änderungen. Gleichzeitig müssen Sie jedoch den bereits erzielten Fortschritt beibehalten. Mit anderen Worten, Sie möchten einen Zweig aus einem früheren Commit erstellen. Wie würden Sie das tun? In Git hat jedes Commit eine eindeutige Kennung. Sie können dies also leicht mit dem Befehl „git log“ sehen. Um einen neuen Zweig basierend auf einem bestimmten Commit zu erstellen, übergeben Sie einfach seinen Hash als Parameter an den Verzweigungsbefehl:

git branch new-branch 7e4decb

Abgesehen davon benötigen Sie die meiste Zeit nicht einmal den gesamten Hash. Nur die ersten fünf oder sechs Zeichen reichen aus.

Erstellen eines Zweigs aus einem Tag

Wenn Sie etwas mehr Erfahrung mit Git haben, sollten Sie mit dem vertraut sein Konzept von Tags. Sie verwenden Tags, um anzuzeigen, dass ein bestimmtes Commit in irgendeiner Weise wichtig oder speziell ist. Beispielsweise werden Tags im Allgemeinen verwendet, um die tatsächlichen Versionen eines Produkts anzuzeigen. Wenn Sie eine Weile in Ihrer Anwendung gearbeitet haben und Sie glauben, es ist an der Zeit, Version 1.0 zu veröffentlichen. Normalerweise müssen Sie die Versionsnummern bei Bedarf erhöhen, diese Änderungen übernehmen und dann zu diesem bestimmten Zeitpunkt ein Tag hinzufügen. Um ein Tag zu erstellen, führen Sie normalerweise Folgendes aus:

git tag -a v1.0 -m "First major version"

Der Parameter „-a“ zeigt an, dass dies geschieht Im Gegensatz zu einem leichtgewichtigen Tag handelt es sich hierbei um ein ausgewachsenes Git-Objekt, das Informationen wie den Namen und die E-Mail-Adresse des Committers, den Zeitstempel und eine Nachricht enthält. Jetzt haben Sie ein Tag, ein Hinweis darauf, dass dieser bestimmte Punkt in der Geschichte etwas Besonderes ist und einen Namen hat. Nett. Sie können wie gewohnt weiterarbeiten und Änderungen erstellen und festschreiben, die Teil der Version 1.1 sind. Bis ein Fehlerbericht eingeht. Einige Clients, die auf 1 aktualisiert wurden.Die Version 0 des Produkts besagt, dass eine Importfunktion nicht wie beabsichtigt funktioniert. Nun, Sie könnten theoretisch den Fehler in der Hauptniederlassung beheben und bereitstellen. Dann würden die Clients jedoch Funktionen erhalten, die möglicherweise nicht getestet und unvollständig sind -Nein. Also, was machst du? Die Antwort: Sie erstellen einen neuen Zweig aus dem Tag, das Sie erstellt haben, um die Hauptversion anzugeben. Sie beheben das Problem dort, erstellen es und stellen es bereit. Und Sie sollten es wahrscheinlich später wieder zum Master zusammenführen, damit die nächsten Versionen das Update enthalten Wie würden Sie vorgehen? Einfach:

git branch <NAME-OF-THE-BRANCH> <TAG>

Genauer gesagt anhand unseres vorherigen Beispiels:

git branch fix-bug-123 v1.0

Danach können Sie Ihren neuen Zweig wie gewohnt auschecken. Oder noch besser, Sie können alles in einem Schritt erledigen:

git checkout -b fix-bug-1234 v1.0

Erstellen eines Zweigs im getrennten Kopfzustand

Wollten Sie jemals in der Zeit zurückgehen? Mit Git ist dies möglich … zumindest in Bezug auf die Dateien in unserem Repository. Sie können jederzeit ein Commit auschecken, wenn Sie den Hash kennen:

git checkout <SHA1>

Nach dem Ausführen zeigt Git Ihnen eine merkwürdige Nachricht:

You are in "detached HEAD" state. You can look around, make experimentalchanges and commit them, and you can discard any commits you make in thisstate without impacting any branches by performing another checkout.

Beim Auschecken Wenn Sie ein Commit ausführen, geben Sie einen speziellen Status ein. c alled, wie Sie sehen können, „losgelöster KOPF“. Während Sie Änderungen in diesem Status festschreiben können, gehören diese Festschreibungen keinem Zweig an und werden unzugänglich, sobald Sie einen anderen Zweig auschecken. Was ist jedoch, wenn Sie diese Festschreibungen beibehalten möchten? Die Antwort lautet, nicht überraschend den Befehl „checkout“ erneut, um einen neuen Zweig zu erstellen:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

Und natürlich wissen Sie jetzt, dass Sie den schreiben können Die letzten beiden Zeilen als ein einziger Befehl:

git checkout -b new-branch-to-keep-commits

Ziemlich einfach, oder?

Nur weil Sie können … Bedeutet nicht, dass Sie

Git’s Verzweigungsmodell eines seiner Verkaufsargumente sein sollten. Es macht das, was in anderen Versionsverwaltungssystemen ein schmerzhafter und sogar langsamer Prozess ist, zum Kinderspiel. Man könnte sagen dass Git die Verzweigung für die Massen erfolgreich demokratisiert hat. Aber es besteht eine ernsthafte Gefahr. Aufgrund der Billigkeit der Verzweigung in Git könnten einige Entwickler in die Falle geraten, mit extrem langlebigen Zweigen zu arbeiten oder Workflows oder Verzweigungsmodelle zu verwenden, die die Inte verzögern gration. Wir als Industrie waren dort. Wir haben das getan. Es funktioniert nicht. Umfassen Sie stattdessen Workflows mit extrem kurzlebigen Niederlassungen. Sie haben eine sichere Sandbox, in der Sie codieren können, ohne befürchten zu müssen, dass etwas kaputt geht oder Ihre Mitarbeiter Zeit verlieren. Aber fragen Sie sich: „Wie stelle ich Code mit teilweise abgeschlossenen Funktionen bereit?“ In diesem Fall handelt es sich um Feature-Flags zur Rettung. Git-Zweige sind ein leistungsstarkes Werkzeug. Verwenden Sie sie mit Bedacht und missbrauchen Sie sie nicht. Und wenn sie nicht ausreichen, setzen Sie kontinuierliche Bereitstellung / kontinuierliche Integration zusammen mit Feature-Flags – einschließlich spezieller Tools, die Ihnen zur Verfügung stehen – ein, damit Ihre Anwendungen die nächste Stufe erreichen können.