Git -Verzweigungs -Tutorial für Anfänger
- 1384
- 111
- Susanne Stoutjesdijk
Die Verzweigung ermöglicht es Git, mehrere Entwicklungslinien zu verfolgen. Dies ermöglicht es Ihnen im Wesentlichen, dass Sie gleichzeitig mehrere Versionen Ihres Projekts in der Entwicklung haben. Beispielsweise entscheiden sich viele Projekte für eine stabile Master -Filiale, während neue Funktionen oder Fehlerbehebungen in einer Entwicklung oder Testzweide implementiert werden. Sobald die Projektorganisatoren davon überzeugt sind, dass die in der Entwicklungszweig vorgenommenen Änderungen den erforderlichen Reifegrad erreicht haben, können sie diese Änderungen in den Master -Zweig zusammenschließen.
Für viele größere Projekte wird dieser Zyklus oft auf unbestimmte Zeit wiederholt. Der Vorteil der Implementierung dieser Strategie besteht darin, dass sie die Einführung von Fehlern in die Primärversion der Codebasis verringert und daher das Auftreten von Fehler und anderen potenziellen nachteiligen Verhaltensweisen in der Software verringert. Gleichzeitig können Entwickler neue Ideen ohne Einschränkungen testen. Daher können sie weiterhin kreativ zum Projekt effizient beitragen.
In diesem Tutorial lernen Sie:
- Was ist verzweigt
- So erstellen Sie Zweige
- Wie man zwischen Zweigen wechselt
- So löschen Sie Zweige
- Wie man Zweige zusammenfasst
- So verwalten Sie Tags
- So verwenden Sie Tags, um die Versionierung im Auge zu behalten
- Wie man mit Zweigen und Tags in Fernbedienungen arbeitet
Git -Verzweigungs -Tutorial für Anfänger Softwareanforderungen und Konventionen verwendet
| Kategorie | Anforderungen, Konventionen oder Softwareversion verwendet |
|---|---|
| System | Jedes GNU/Linux -Betriebssystem |
| Software | Git |
| Andere | Privilegierter Zugriff auf Ihr Linux -System als Root oder über die sudo Befehl. |
| Konventionen | # - erfordert, dass gegebene Linux -Befehle mit Root -Berechtigungen entweder direkt als Stammbenutzer oder mit Verwendung von ausgeführt werden können sudo Befehl$ - Erfordert, dass die angegebenen Linux-Befehle als regelmäßiger nicht privilegierter Benutzer ausgeführt werden können |
Zweige erstellen
Lassen Sie uns ein kurzes Beispiel dafür untersuchen, wie man mit Zweigen arbeitet und das erste GIT -Projekt fortsetzt. Machen Sie zunächst ProjectName Ihr aktuelles Arbeitsverzeichnis. Lassen Sie uns nun eine Zweigstelle speziell für die Arbeit an der Dokumentation für das Out -Projekt erstellen. Geben Sie den folgenden Befehl aus, um diesen neuen Zweig zu machen.
$ Git Branch Docs
Schauen wir uns jetzt alle unsere Zweige an.
$ Git Branch
Einfach die ausgeben Git -Zweig Der Befehl wie oben zeigt eine Liste aller Zweige in unserem Git -Repo. Sie werden feststellen, dass der erste Zweig aufgerufen wird Meister standardmäßig. In unserem Fall sehen wir das Meister Branche und unsere neu erstellte Docs Branch. Beachten Sie, dass der aktuelle Zweig, in dem wir arbeiten * Und es ist immer noch der Master -Zweig. Um in der Docs -Filiale zu arbeiten, müssen wir die Filiale auschecken.
Wechsel zwischen Zweigen
$ git checkout docs
Jetzt, wo wir das ausgecheckt haben Dokumente Zweig, alle Änderungen, die wir vornehmen Meister Der Zweig bleibt unberührt und in dem genauen Zustand, dass er vor dem Auschecken der Dokumente Zweig.
Lassen Sie uns a erstellen Liesmich.txt Datei für unser Projekt.
$ echo "Dies ist ein einfaches Hello World -Programm, das während eines Git -Tutorials erstellt wurde."> Readme.txt
Jetzt, da wir eine beschreibende Readme -Datei zur Dokumentation haben, lassen Sie uns sie inszenieren und genau so verpflichten, wie wir im vorherigen Artikel des Git -Tutorials für Anfänger gelernt haben.
$ git add Readme.txt $ git Commit -m "fügte Readme zu DOCS -Branch hinzu"
Nachdem wir die Änderung in unserem Docs -Zweig verpflichtet haben, können wir wieder in den Master -Zweig wechseln, indem wir sie auschecken.
$ Git Checkout Master
Gehen Sie voran und listen Sie den Verzeichnisinhalt auf.
$ ls
Sie werden feststellen, dass der Master -Zweig nicht die hat Liesmich.txt Datei, weil es im Moment nur im Docs -Zweig vorliegt. Dies zeigt, wie die beiden Zweige zwei verschiedene Entwicklungszustände darstellen.
Zweige verschmelzen
Was ist, wenn wir das Gefühl haben, dass unsere Dokumentation vollständig und bereit ist, in den Master -Zweig zusammengefasst zu werden?? Hier ist der Befehl git merge nützlich. Geben Sie den folgenden Befehl ein, um den Docs -Zweig in den Master -Zweig zusammenzufassen.
$ git merge docs
Listen Sie den Verzeichnisinhalt auf und beachten Sie, dass der Master -Zweig jetzt das Readme enthält.TXT -Datei.
$ ls
Wenn wir ausgeben
$ git log
Dann sehen wir, dass die Protokollgeschichte der beiden Zweige ebenfalls zusammengeführt wurde.
Überprüfen Sie das Git -Protokoll Äste löschen
Nachdem wir unsere Dokumentation abgeschlossen und die Docs -Zweigstelle mit dem Master -Zweig zusammengefasst haben. Um dies einfach zu tun, fügen Sie einfach das hinzu -D Fahnen Sie den Befehl git agir.
$ git branch -d -docs
Jetzt haben wir nur noch einen Zweig in unserem Projekt und es spiegelt alle Änderungen wider, die wir in der gesamten Zeit vorgenommen haben. einschließlich der Hinzufügung einer Readme -Datei.
Tagging
Möglicherweise möchten wir in der Lage sein, ein bestimmtes Commit leicht zu sehen und sich darauf zu verweisen, ohne seine Commit -ID verwenden zu müssen. Um dies zu erreichen. Nennen wir in unserem Fall unseren Faustbeamten drin, Unser zweites Commit Quelle und unser letzter Commit Liesmich Wenn wir also in Zukunft jemals müssen.
$ git tag init abbda7da6f6257effc7da16766ffc464c4098a8e $ Git Tag Quelle 41DCCEE5478129094c3cbbcd08a26076a9aa370b $ Git Tag ReadMe
Sie können feststellen, dass wir für den letzten Befehl keine Commit -ID angeben mussten. Dies liegt daran. Wir hätten den Commit -ID liefern können, wenn wir wollten, aber es wäre unnötig gewesen.
Wenn wir den Tag -Tag ohne Argumente verwenden, gibt es uns eine Liste aller von uns verwendeten Tags.
$ 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 ihre Tags anstelle ihrer Commit -IDs verwenden, wenn wir uns auf diese Commits verweisen möchten. Genau wie wir eine Filiale überprüfen können, können wir auch ein bestimmtes Commit ansehen. Wenn wir uns entschieden haben, unser erstes Commit zu überprüfen, konnten wir es jetzt mit seinem Tag überprüfen.
$ git checkout init
Ab diesem Zeitpunkt, wenn wir uns entschieden haben, einen neuen Zweig zu erstellen, der in eine völlig andere Richtung als unser ursprüngliches Projekt ging. Ähnlich wie beim Checkout -Befehl wechselt Switch die Zweige, aber mit dem -C -Flag kann es auch gleichzeitig einen neuen Zweig erstellen.
$ Git Switch -c New-Branch-Name
Sie können auch einen neuen Zweig erstellen und mit dem Kasse -Befehl wie folgt darauf wechseln.
$ git checkout -b new branchname
Verwenden Sie das, was Sie bevorzugen, aber es ist wichtig zu beachten.
Andere Überlegungen
Wir verwenden ein sehr einfaches Beispiel, um sich eher auf Git selbst als auf den Code zu konzentrieren, den wir verwalten. Infolgedessen spiegeln die von uns verwendeten Tags ein einfaches Namensschema wider, das auf der Einführung von Funktionen basiert. Größere Projekte verwenden jedoch normalerweise Tags als Mittel, um die Versionierung zu verfolgen, indem Sie Commits mit Tagging -Commits verfolgen, die den spezifischen Release -Punktnummern entsprechen.
Zum Beispiel Version1.0,
Version 2.0 etc. Es ist auch wichtig zu beachten.
$ git push Origin new_branch_name $ git push Origin Tag_Name $ Git Push Origin - -Tags
Der erste Befehl drückt den angegebenen Zweig auf den Remote -Server, der zweite wird das angegebene Tag auf den Server drücken und der dritte wird alle Tags auf den Server drücken.
Eine weitere wichtige Sache in Bezug auf Remote -Server ist, dass der Master -Zweig, wenn Sie ein Remote -Repo geklont haben.
Um alle anderen Zweige im Remote -Repo zu sehen, geben Sie den folgenden Befehl mit dem aus -A Flagge, die alle lokalen und abgelegenen Zweige anzeigt.
$ Git Branch -a
Sobald Sie eine Remote -Filiale auschecken.
Abschluss
Nachdem ich die oben genannten Beispiele gearbeitet habe, ermutige ich Sie, mit Zweigen und Tags weiter zu spielen, bis die Arbeit mit ihnen zu tun beginnt. Wenn Sie keinen Zugriff auf ein Remote -Repository haben, in dem Sie Dinge wie das Schieben von Zweigen, das Drücken von Tags und das Auschecken von Remote -Zweigen üben können, empfehle ich Ihnen, ein kostenloses Github -Konto zu erstellen und die Option zum Erstellen eines privaten Repo dort auszuwählen.
Tatsächlich würde ich dies empfehlen, auch wenn Sie Zugriff auf andere Remote -Repos haben. Wenn Sie während des Lernens einen Fehler in Ihrem eigenen privaten Github -Konto machen, wird kein großer Schaden angerichtet. Ich würde empfehlen, dass Sie GIT gemeinsam mit der Nutzung von Git verwenden, sobald Sie sich sehr wohl fühlen.
Nachdem Sie diesen Artikel und das Git -Tutorial für Anfängerhandbuch verfolgt haben, sollten Sie sich nun wohl fühlen, Git zu installieren, Git zu konfigurieren, mit Filialen zu arbeiten, das Konzept der Versionierung, Markierung und Verwendung von Git, um sowohl mit lokalen als auch mit Remote -Repositories zusammenzuarbeiten. Sie haben jetzt das Arbeitswissen, um die Macht und Effizienz von Git als verteiltes Überarbeitungskontrollsystem weiter zu übernehmen. Was auch immer Sie vielleicht arbeiten, ich hoffe, dass diese Informationen die Art und Weise verändern, wie Sie über Ihren Workflow zum Besseren denken.
Verwandte Linux -Tutorials:
- Git -Tutorial für Anfänger
- Mint 20: Besser als Ubuntu und Microsoft Windows?
- Wie man Pacman -Updates in Arch Linux rollt
- Einführungs -Tutorial für Git unter Linux
- Liste der besten Kali -Linux -Tools für Penetrationstests und…
- Manjaro Linux gegen Arch Linux
- Hung Linux System? Wie man zur Befehlszeile entkommt und…
- Git: Branche umbenennen
- So aktualisieren Sie Ubuntu -Pakete auf Ubuntu 22.04 Jammy…
- Liste der GIT -GUI -Anwendungen für Linux