Website-Suche

Git Branching Tutorial für Einsteiger

Branching ermöglicht es Git, mehrere Entwicklungslinien zu verfolgen. Auf diese Weise können Sie im Wesentlichen mehrere Versionen Ihres Projekts gleichzeitig in der Entwicklung haben. Zum Beispiel entscheiden sich viele Projekte dafür, einen stabilen Master-Zweig zu haben, während neue Funktionen oder Fehlerbehebungen in einem Entwicklungs- oder Testzweig implementiert werden. Sobald die Projektorganisatoren davon überzeugt sind, dass die im Entwicklungszweig vorgenommenen Änderungen den erforderlichen Reifegrad erreicht haben, können sie sich dafür entscheiden, diese Änderungen mit dem Hauptzweig zusammenzuführen.

Bei vielen größeren Projekten wird sich dieser Zyklus oft unbegrenzt wiederholen. Der Vorteil der Implementierung dieser Strategie besteht darin, dass sie dazu beiträgt, die Einführung von Fehlern in die primäre Version der Codebasis zu reduzieren und somit das Auftreten von Fehlern und anderem potenziell unerwünschten Verhalten in der Software zu reduzieren. Gleichzeitig ermöglicht es Entwicklern, neue Ideen ohne Einschränkungen zu testen. Daher können sie weiterhin auf effiziente Weise kreativ zum Projekt beitragen.

In diesem Tutorial lernen Sie:

  • Was ist Verzweigung?
  • So erstellen Sie Zweige
  • So wechseln Sie zwischen den Zweigen
  • So löschen Sie Zweige
  • So führen Sie Zweige zusammen
  • Verwalten von Tags
  • Verwenden von Tags zum Nachverfolgen der Versionierung
  • So arbeiten Sie mit Branches und Tags in Remote-Repositories

Git Branching Tutorial für Einsteiger

Verwendete Softwareanforderungen und Konventionen

Erstellen von Zweigen

Sehen wir uns ein kurzes Beispiel für die Arbeit mit Branches an und fahren wir mit dem anfänglichen Git-Projekt fort, das wir im vorherigen Git-Tutorial für Anfänger erstellt haben. Legen Sie zunächst projectname zu Ihrem aktuellen Arbeitsverzeichnis fest. Lassen Sie uns nun einen Zweig speziell für die Arbeit an der Dokumentation für unser Projekt erstellen. Geben Sie den folgenden Befehl ein, um diesen neuen Zweig zu erstellen.

git branch docs

Werfen wir nun einen Blick auf alle unsere Filialen.

git branch

Wenn Sie einfach den Befehl git branch wie oben ausgeben, wird eine Liste aller Zweige in unserem Git-Repository angezeigt. Sie werden feststellen, dass der erste Zweig standardmäßig master heißt. In unserem Fall sehen wir den Master-Zweig und unseren neu erstellten Zweig docs. Beachten Sie, dass der aktuelle Zweig, in dem wir arbeiten, mit * gekennzeichnet ist und es sich immer noch um den Master-Zweig handelt. Um mit der Arbeit im Zweig docs zu beginnen, müssen wir den Zweig auschecken.

Wechseln zwischen Zweigen

git checkout docs

Jetzt, da wir den Zweig docs ausgecheckt haben, wirken sich alle Änderungen, die wir vornehmen, nur auf diesen Zweig aus und der Master-Zweig bleibt unberührt und befindet sich genau in dem Zustand, in dem er sich vor dem Auschecken des Zweigs docs befand.
Erstellen Sie eine readme.txt Datei für unser Projekt.

echo "This is a simple Hello World program that was created during a git tutorial." > readme.txt

Jetzt, da wir eine beschreibende Readme-Datei für die Dokumentation haben, lassen Sie uns sie bereitstellen und committen, genau wie wir es im vorherigen Artikel des Git-Tutorials für Anfänger gelernt haben.

git add readme.txt
git commit -m "added readme to docs branch"

Nachdem wir die Änderung in unserem Docs-Zweig übernommen haben, können wir zurück zum Master-Zweig wechseln, indem wir ihn auschecken.

git checkout master

Fahren Sie fort und listen Sie den Inhalt des Verzeichnisses auf.

ls

Sie werden feststellen, dass der Master-Zweig nicht über die readme.txt Datei verfügt, da sie im Moment nur im Zweig docs vorhanden ist. Dies zeigt, wie die beiden Zweige zwei unterschiedliche Entwicklungszustände repräsentieren.

Zusammenführen von Zweigen

Was ist, wenn wir das Gefühl haben, dass unsere Dokumentation vollständig und bereit ist, in den Master-Zweig integriert zu werden? Hier kommt der Befehl git merge ins Spiel. Geben Sie den folgenden Befehl ein, um den Zweig docs mit dem Master-Branch zusammenzuführen.

git merge docs

Listen Sie den Verzeichnisinhalt auf und beachten Sie, dass der Master-Zweig jetzt die readme.txt Datei enthält.

ls

Wenn wir

git log

Dann sehen wir, dass die Protokollhistorie der beiden Zweige ebenfalls zusammengeführt wurde.

Überprüfen des Git-Protokolls

Löschen von Zweigen

Jetzt, da wir unsere Dokumentation abgeschlossen und den Zweig docs mit dem Master-Zweig zusammengeführt haben, können wir den Zweig docs sicher löschen, wenn wir möchten. Fügen Sie dazu einfach das Flag -d zum Befehl git branch hinzu.

git branch -d docs

Jetzt haben wir nur noch einen Zweig in unserem Projekt, und er spiegelt alle Änderungen wider, die wir im Laufe des Projekts vorgenommen haben. einschließlich des Hinzufügens einer Readme-Datei.

Identifizieren

Möglicherweise möchten wir in der Lage sein, einen bestimmten Commit leicht zu sehen und darauf zu verweisen, ohne seine Commit-ID verwenden zu müssen. Um dies zu erreichen, können wir den Befehl git tag verwenden, um einem Commit einen einprägsamen Namen zu geben. In unserem Fall nennen wir unseren ersten Commit init, unsere zweite Commit-Quelle und unsere letzte Commit-Readme-Datei, damit wir bei Bedarf in Zukunft leicht auf die Commits verweisen können, bei denen wir das Projekt initialisiert, den Quellcode hinzugefügt und jeweils eine Readme-Datei hinzugefügt haben.

git tag init abbda7da6f6257effc7da16766ffc464c4098a8e
git tag source 41dccee5478129094c3cbbcd08a26076a9aa370b
git tag readme

Möglicherweise stellen Sie fest, dass wir für den letzten Befehl keine Commit-ID angeben mussten. Dies liegt daran, dass dieser Commit unser aktueller HEAD ist und der aktuelle HEAD standardmäßig benannt wird, wenn keine Commit-ID angegeben wird. Wir hätten die Commit-ID bereitstellen können, wenn wir gewollt hätten, aber das wäre unnötig gewesen.

Wenn wir den Tag-Befehl ohne Argumente verwenden, erhalten wir eine Liste aller Tags, die wir verwenden.

git tag

Wenn wir alle Tags zusammen mit den anderen Commit-Informationen sehen möchten, können wir den bekannten Protokollbefehl ausgeben:

git log

Git-Tagging

Von nun an können wir, wenn wir auf diese Commits verweisen wollen, ihre Tags anstelle ihrer Commit-IDs verwenden. Genauso wie wir einen Zweig auschecken können, können wir auch einen bestimmten Commit auschecken. Wenn wir uns entschieden haben, unseren ersten Commit auszuchecken, können wir ihn jetzt anhand seines Tags überprüfen.

git checkout init

Wenn wir von diesem Punkt aus beschlossen haben, einen neuen Zweig zu erstellen, der in eine völlig andere Richtung geht als unser ursprüngliches Projekt, können wir dies tun, indem wir hier einige Änderungen vornehmen und den Befehl switch mit dem Flag -c gefolgt vom neuen Zweignamen ausgeben. Ähnlich wie der checkout-Befehl wechselt switch die Branche, aber mit dem Flag -c ist es auch in der Lage, gleichzeitig einen neuen Zweig zu erstellen.

   
git switch -c new-branch-name

Sie können auch einen neuen Zweig erstellen und mit dem checkout-Befehl wie folgt zu diesem wechseln.

git checkout -b new-branch-name

Verwenden Sie, was Sie bevorzugen, aber es ist wichtig zu beachten, dass laut den Manpages von git der switch-Befehl experimentell ist und sich seine Funktionalität in Zukunft ändern kann.

Weitere Überlegungen

Wir verwenden ein sehr einfaches Beispiel, um uns auf Git selbst zu konzentrieren und nicht auf den Code, den wir verwalten. Infolgedessen spiegeln die von uns verwendeten Tags ein einfaches Benennungsschema wider, das auf der Einführung von Funktionen basiert. Größere Projekte verwenden jedoch in der Regel Tags als Mittel, um die Versionierung nachzuverfolgen, indem Commits markiert werden, die bestimmten Releasepunktnummern entsprechen.

Beispiel: Version1.0,
Version2.0 usw. Es ist auch wichtig zu beachten, dass, wenn Sie Ihre Änderungen auf einen Remoteserver übertragen, neue Branches und Tags standardmäßig nicht gepusht werden, sondern mit den folgenden Befehlen speziell gepusht werden müssen.

git push origin new_branch_name
git push origin tag_name
git push origin --tags

Der erste Befehl überträgt den angegebenen Zweig auf den Remote-Server, der zweite überträgt das angegebene Tag auf den Server und der dritte überträgt alle Tags auf den Server.
Ein weiterer wichtiger Punkt, den Sie bei Remote-Servern beachten sollten, ist, dass, wenn Sie ein Remote-Repository geklont haben, der Master-Zweig auf Ihren lokalen Rechner geklont wurde. aber nicht die anderen Zweige.

Um alle anderen Zweige im Remoterepository anzuzeigen, geben Sie den folgenden Befehl mit dem Flag -a ein, das alle lokalen und Remotezweige anzeigt.

git branch -a

Sobald Sie einen Remote-Branch ausgecheckt haben, wird er in Ihr lokales Repository heruntergeladen, und Sie können weiterhin lokal daran arbeiten, bis Sie die Änderungen, die Sie am Branch vorgenommen haben, zurück auf den Server übertragen möchten.

Schlussfolgerung

Nachdem Sie die obigen Beispiele durchgearbeitet haben, ermutige ich Sie, weiter mit Zweigen und Tags herumzuspielen, bis sich die Arbeit mit ihnen für Sie intuitiv anfühlt. Wenn Sie keinen Zugang zu einem Remote-Repository haben, in dem Sie Dinge wie das Pushen von Branches, das Pushen von Tags und das Auschecken von Remote-Branches üben können, empfehle ich Ihnen, ein kostenloses GitHub-Konto zu erstellen und die Option auszuwählen, dort ein privates Repository zu erstellen.

Tatsächlich würde ich empfehlen, dies auch dann zu tun, wenn Sie Zugriff auf andere Remote-Repositorys haben. Wenn Sie während des Lernens einen Fehler in Ihrem eigenen privaten GitHub-Konto machen, entsteht kein größerer Schaden. Ich würde empfehlen, dass Sie anfangen, Git kollaborativ zu verwenden, sobald Sie sich damit sehr wohl fühlen.

Nachdem Sie diesen Artikel und den Leitfaden für Git-Tutorial für Anfänger befolgt haben, sollten Sie sich jetzt wohl fühlen, wenn Sie Git installieren, Git konfigurieren, mit Branches arbeiten, das Konzept der Versionierung, des Taggings und der Verwendung von Git verwenden, um sowohl mit lokalen als auch mit Remote-Repositories zu arbeiten. Sie verfügen jetzt über das praktische Wissen, um die Leistungsfähigkeit und Effizienz von git als verteiltes Versionskontrollsystem weiter auszubauen. Woran auch immer Sie arbeiten, ich hoffe, dass diese Informationen die Art und Weise, wie Sie über Ihren Workflow denken, zum Besseren verändern.

Verwandte Artikel: