Lernen Sie Git und Github von Grund auf neu 2026 [Einfache Methode]

1. Einführung in Git-Masterclass: Willkommen zum ultimativen IT-Kurs. In diesem Kurs werden wir es von Grund auf lernen, bis hin zu fortgeschritteneren Konzepten. Wir beginnen damit, was ist es? Warum jedes Unternehmen es liebt, wie Git wirklich funktioniert, konfiguriere Git in unserem System. Git-Grundlagen wie das Staging der Dateien und das Übernehmen einiger Danach haben wir einen kompletten Abschnitt zum Durchsuchen des Commit-Verlaufs Darin können wir zwei Commits vergleichen, zu einem bestimmten Commit zurückkehren und Texte hinzufügen Danach haben wir einen Abschnitt für Branches und Zusammenführungen, was das wichtigste Thema von Kit ist Wir werden auch die Änderungen testen, verschiedene Arten der Zusammenführung, Konfliktlösungen wie Pro, Arten des Zurücksetzens, Techniken zum Heraustrennen. Danach haben wir einen Abschnitt für die Arbeit im Team, in dem ich Ihnen praktisch zeigen werde , wie Teammitglieder damit zusammenarbeiten Darin haben wir Cloning, Padging, Pull, Push. Außerdem tragen einige zusätzliche Funktionen von Github wie Veröffentlichungen, Probleme und Meilensteine zum Open-Source-Projekt bei Danach werden wir sehen, wie wir unsere Projekthistorie organisieren können , damit unser Projekt professioneller aussieht. Bestehende Commits modifizieren, sie aufteilen und zerquetschen können, und vieles In diesem Kurs werden wir Git also auf beide Arten lernen. Zuerst werden wir uns den Befehlszeilenansatz ansehen, und dann werde ich Ihnen zeigen, wie wir dasselbe mit GI-Tools wie Gitub Desktop, Visa Studio Code und Git Gracon tun können dasselbe mit GI-Tools wie Gitub Desktop, Visa Studio Code und Git Aber wie Sie vielleicht wissen, haben GI-Tools kaum eingeschränkte Funktionen kaum eingeschränkte Deshalb ist es für uns sehr wichtig, Git-Befehle zu lernen . Wenn du nichts über Git weißt oder dir die Konzepte von Git nicht klar sind oder du Kit und Github beherrschen möchtest, dann ist dieser Kurs genau das Richtige für dich. Jetzt fragst du dich vielleicht, wer bin ich? Ich bin Softwareingenieur und unterrichte auch Programmieren in leicht zu erklärender Sprache über meinen YouTube-Kanal, Gott segne dich, und mit meinen Online-Kursen. Und in diesem Kurs werde ich dir auch einige Projekte vorstellen, an denen du die Kit-Befehle üben kannst . Du kannst mir folgen , denn wenn du selbst Git-Befehle schreibst und mit ihnen experimentierst, wirst du die Befehle richtig verstehen. Machen Sie Fehler, lernen Sie aus den Fehlern und tun Sie es, bis Sie diese Fähigkeit beherrschen Nach Abschluss dieses Kurses werden Sie richtig verstehen, werden Sie richtig verstehen wie es funktioniert, und Sie werden es selbstbewusst anwenden , ohne verwirrt zu werden, und Sie werden die besten Techniken anwenden Ich weiß, dass du dich darauf freust, es und Github zu lernen, also springen Sie ein und tauchen Sie ein in diesen Kurs 2. Was ist Git und Github?: Bevor wir also anfangen, Gangart zu lernen, wollen wir uns ansehen, was Git ist Git ist das beliebteste Versionskontrollsystem. Jetzt fragst du dich vielleicht, was ich mit Versionskontrollsystem meine. Versionskontrollsystem bedeutet, dass es uns hilft , verschiedene Versionen unseres Projekts aufzuzeichnen. Lassen Sie mich Ihnen das anhand eines Beispiels aus der Praxis erklären. Stellen Sie sich vor, Sie arbeiten an einer E-Commerce-Anwendung. Jetzt, nach einiger Zeit, haben Sie mit Ihrem Code wirklich Mist gebaut und Sie können Fehler nicht identifizieren und nicht lösen. Sie beschließen, bei Null anzufangen. Was ist nun die Lösung, damit sich diese Situation nicht wiederholen wird? Eine Lösung besteht darin, dass Sie Ihr Projekt duplizieren und ihm einen Namen wie Version 1.0 geben können. Und speichern Sie es irgendwo als Backup. Wenn Sie also in Zukunft wieder Mist gebaut haben, können Sie zu diesem Code der Version 1.0 zurückkehren zu diesem Code der Version 1.0 zurückkehren Wenn Sie jetzt neue Funktionen einführen, Sie immer wieder Sicherungskopien und erstellen Versionen Ihrer Anwendung manuelle Erstellen von Backups führt jedoch zu vielen Problemen, z. B. zu Speicherproblemen. Außerdem sorgt es für große Verwirrung, wie in Version 1.0, welche Funktionen wir hinzugefügt oder entfernt haben. Stellen Sie sich außerdem vor, Sie haben ein weiteres Teammitglied, das an demselben Projekt arbeitet, dann müssen Sie Ihre Backups erstellen und welche Änderungen an diesem Projekt Sie nicht verfolgen können. Das sorgt für viel Verwirrung und Stress im Team. Zu diesem Zeitpunkt kommt es ins Bild. Kit hilft uns dabei, verschiedene Versionen unserer Projekte sehr systematisch und ohne zusätzlichen Speicherplatz zu speichern. Angenommen, Sie arbeiten an einer SML-Datei mit Indexpunkt und möchten eine Sicherungskopie des aktuellen Codes Sie sagen Git, diesen Dateicode im Verlauf zu speichern. G mache einen Schnappschuss von deinem Code und speichere ihn einfach in seinem Speicher. Ihre Anwendung wächst, machen Sie jetzt mehrere Screenshots und speichern sie im Git-Speicher. Wenn Sie eine bestimmte Version sehen möchten, zeigt Ihnen Git den Verlauf Ihres Projekts und Sie können diesen Code einfach wiederherstellen. Jetzt kannst du sagen, dass wir verstehen, dass Git unseren Projektverlauf verfolgt Deshalb müssen wir uns keine Gedanken über manuelle Backups machen, sondern darum, wie Git Probleme löst, indem wir im Team arbeiten. Ist ein anderes Problem. Lassen Sie mich Ihnen das schnell erklären. Hier arbeiten Sie und Ihre Teammitglieder einzeln an demselben Projekt, und Sie verwenden es beide, um Ihren Projektverlauf zu verfolgen. Wenn Sie nun mit Ihrer einen Aufgabe fertig sind, können Sie Ihren Code-Snapshot in Kit erstellen und dieses Projekt auf den Cloud-Dienst hochladen , sodass wir Kit-Projekte hochladen können. Jetzt holt sich Ihr Teammitglied Ihr Git-Projekt oder Git-Ordner von diesem Cloud-Dienst und beginnt, daran zu arbeiten. Wenn er mit dem Blog fertig ist, kann er einen Snapshot erstellen und Änderungen im Cloud-Dienst aktualisieren Und können Sie sich vorstellen, welcher Cloud-Dienst von Entwicklern am häufigsten genutzt Richtig, es ist Github. Git und Github sind unterschiedlich. Git ist ein Versionskontrollsystem, und Github wird zum Hosten von Git-Projekten in der Cloud verwendet , und auch Github bietet mehr Funktionen. Durch die Verwendung von Git und GitHub können wir problemlos im Team arbeiten, ohne uns gegenseitig E-Mails im Voraus schicken zu müssen. Mach dir keine Sorgen. Wir werden das im nächsten Abschnitt sehr genau verstehen. Tatsächlich haben wir einen ganzen Abschnitt, in dem ich Ihnen praktisch zeige, wie Entwickler miteinander arbeiten. Um es kurz zu machen, es ist das beliebteste Versionskontrollsystem. Mit Git können wir unsere Projekthistorie sehr effektiv verfolgen . Wir müssen uns also keine Gedanken über manuelles Backup und Recovery machen. Außerdem können wir mit Git wissen, wann bestimmte Änderungen mit Datum und Uhrzeit vorgenommen wurden und wer diese Änderungen vorgenommen hat. Außerdem macht Git die Zusammenarbeit mit Teammitgliedern sehr einfach und bietet viele weitere Vorteile , die wir in diesem Kurs sehen werden Aus diesem Grund wollen fast alle Unternehmen Entwickler, die Git sehr gut kennen, und deshalb muss jeder Entwickler Git und Github lernen Hier in diesem Kurs werden wir Git sehr gründlich lernen. Ich freue mich sehr darüber und hoffe, du auch. Wir sehen uns in der nächsten Lektion. 3. Verschiedene Möglichkeiten zur Verwendung von Git: Lassen Sie mich Ihnen nun die verschiedenen Möglichkeiten zeigen, Git als Entwickler zu verwenden. Der erste Weg ist also, dass Sie es in der Befehlszeile verwenden können, was bedeutet, dass Sie Ihr Terminal öffnen und anfangen, Befehle für den Zugriff auf Git zu schreiben. Dies ist eine der einfachsten Arten , Gate zu verwenden, und viele Entwickler bevorzugen die Befehlszeile. Wenn Sie den Befehlszeilenansatz nicht verwenden möchten, können Sie unsere Code-Editoren für den Zugriff auf das Gate verwenden. In VS-Code erhalten wir beispielsweise standardmäßig das Source Control Panel. Mit diesem Panel können wir grundlegende Operationen von Git ausführen. Jetzt fragst du dich vielleicht, was ist, wenn wir mehr Git-Funktionen verwenden wollen ? Mach dir darüber keine Sorgen. Wir haben eine VS-Code-Erweiterung namens Gitans, die beliebteste und am häufigsten verwendete Git-Erweiterung Sie können sehen, dass diese Erweiterung von fast 30 Millionen Benutzern heruntergeladen wird von fast 30 Millionen Benutzern heruntergeladen Sie können diese Erweiterung auch verwenden. Jetzt gibt es eine andere Möglichkeit, es zu verwenden indem Sie die grafische Benutzeroberfläche oder GUI verwenden. GI bedeutet, dass wir eine Anwendung verwenden können , die speziell für die Verwendung von Git entwickelt wurde. Heutzutage ist Github Desktop die am häufigsten verwendete und einfachste Git-Anwendung . Gitub-Desktop-Anwendung hat es für Gate-Anfänger so einfach gemacht Die Gitub-Desktop-Anwendung hat es für Gate-Anfänger so einfach gemacht, aber es ist sehr einfach und leicht zu verstehen, hat aber nicht alle Funktionen Wenn Sie ein anderes GI-Tool verwenden möchten, das mehr Funktionen als der Github-Desktop bietet, können Sie Gate Gracon verwenden Dies ist auch ein beliebtes Tool für Git, aber seine Benutzeroberfläche ist wenig komplex als die Github-Desktop-Anwendung Aber am Ende dieses Kurses wirst du Gate Gracon definitiv mögen Ich werde dir in den nächsten Abschnitten zeigen, warum. Jetzt fragst du dich vielleicht, wie man es am besten benutzt? Und die Antwort ist der Befehlszeilenansatz, und 70% der Entwickler verwenden gerne den Befehlszeilenansatz. Der erste Grund ist, dass alle GI-Tools, egal ob es sich um Github-Desktop oder Kraken handelt , mit einigen Einschränkungen verbunden sind, was bedeutet, dass Sie für einige Aufgaben auf jeden Fall die Befehlszeile verwenden müssen Mithilfe der Befehlszeile können Sie alle Aufgaben im Zusammenhang mit Git Ein weiterer Grund ist, dass Ihnen die Tools nicht immer zur Verfügung stehen. Zum Beispiel erlauben Server manchmal aus irgendeinem Grund nicht , GI-Tools für Git zu verwenden. Wenn Sie zu diesem Zeitpunkt die Git-Befehle nicht kennen, werden Sie in dieser Situation stecken bleiben. In den meisten Fällen verwenden viele Entwickler gerne sowohl GI-Tools als auch die Befehlszeile, und ich gehöre auch zu ihnen. Das werde ich dir in diesem Kurs beibringen. Wir werden zuerst den Befehlszeilenansatz lernen und dann werden wir uns auch mit diesen Konzepten mithilfe von GI-Tools befassen. Sie lernen beide Methoden und müssen dann das richtige Tool für die Aufgabe auswählen , die Sie ausführen. Lassen Sie mich Ihnen einen Vorfall in meiner Firma erzählen , bei dem ich als Softwareingenieur gearbeitet habe. Es gab einen Typen, der alle Kit-Aufgaben über die Befehlszeile erledigte, auch komplexe Aufgaben. Er findet, dass er cool aussieht, für jede Aufgabe die Befehlszeile benutzt. Aber wir alle wissen, dass wir diese Aufgabe mit IT-Tools viel einfacher ausführen können . Also werde nicht wie dieser Typ. Du musst klug denken. Weise kann ich diese Aufgabe schneller und ohne verwirrt zu werden erledigen. Wir werden die meiste Zeit mit der Befehlszeile verbringen , weil sie schneller ist. Aber wenn ich denke, dass die Verwendung des I-Tool vorteilhafter ist , werde ich Ihnen den Weg dieses GI-Tools zeigen. Außerdem haben viele Anfänger-Entwickler große Angst davor, die Kommandozeile zu benutzen, oder ich kann sagen, sich an die Befehle für die Gangart zu erinnern , aber keine Sorge, ich werde dir alles einfach Schritt für Schritt und einfacher beibringen , als du denkst Du wirst das Selbstvertrauen bekommen, Git wie ein Profi zu verwenden. In der nächsten Lektion werden wir sehen, wie man Git in unserem System installiert. 4. Git in unserem System einrichten: Also lasst uns Git in unserem System installieren. Aber vorher wollen wir überprüfen, ob Git bereits in unserem System verfügbar ist oder nicht. Und um das zu tun, verwenden wir Terminal. Wenn Sie also ein Windows-Benutzer sind, drücken Sie die Windows-Taste und geben Sie CMD Und wenn Sie Mcuser sind, drücken Sie Command plus Leertaste und geben Ich verwende Windows, also sieht mein Terminal oder CMD so Ihr Terminal sieht möglicherweise anders aus. Es spielt keine Rolle. Also zuerst geben wir hier git version ein, um zu wissen , welche Git-Person in unserem System installiert ist. Hier sehen wir, dass Git nicht als interner oder externer Befehl erkannt wird. Wenn du dieselbe Nachricht erhältst, dann ist sie nicht auf deinem System installiert , und wenn du eine Version bekommst, dann musst du sicherstellen, dass die Version nicht zu alt ist wie zwei oder älter als zwei. Stelle sicher, dass du deinen Gaiterson damit aktualisierst, du kannst ganz einfach weitermachen. Um Git zu installieren oder zu aktualisieren, öffnen wir unseren Browser und suchen hier nach Git-Download Öffne diese Post-it-Website. Nett. Die neueste Git-Version ist also 2.44 0.0 Wenn Sie sich diesen Kurs in Zukunft ansehen, erhalten Sie möglicherweise eine andere Version, aber keine Sorge, Sie können diesem Kurs trotzdem folgen Vertrauen Sie mir, Sie erhalten keine Fehlermeldung. Von hier aus können Sie Ihr Betriebssystem sehen, oder wir können einfach auf diese Schaltfläche klicken. Klicken Sie hier, um es herunterzuladen und sehen, wie es mit dem Herunterladen beginnt g. Lovely. Lassen Sie uns nun dieses Setup öffnen. Zuerst wird es um Erlaubnis bitten. Also erlaube es, klicke auf Weiter. Hier können Sie den Installationspfad auswählen, also klicken Sie auf Weiter, Weiter, Weiter und von hier aus können wir unseren Standard-Code-Editor auswählen. Ich werde Visual Studio-Code oder VSCode verwenden, da fast 90% der Entwickler VSCode verwenden und auf Weiter klicken Weiter und klicken Sie auf Weiter. Klicken Sie anschließend auf Weiter. Klicken Sie auf Weiter, bis Sie Installieren erhalten und die Installation gestartet wird. Fertig und klicken Sie auf Fertig stellen. Öffnen Sie nun das Startmenü und suchen Sie nach Git Bash , der Befehlszeilenschnittstelle für die Bereitstellung der Terminalschnittstelle für das Windows-System Für den Rest dieses Kurses werden wir die Git-Basis-CLI zum Schreiben von Git-Befehlen verwenden Wenn Sie Mguser sind, müssen Sie Ihr Terminal verwenden da dessen Basis nur für Windows bestimmt ist Hier schreiben wir Git Dash Dash Version und C, hier bekommen wir unsere Git-Version 2.42 0.0 Wir installieren Git erfolgreich in unserem System. 5. Benutzerdetails für Git konfigurieren: Um mit der Verwendung von Git zu beginnen, müssen wir zunächst einige Konfigurationseinstellungen wie Benutzername, EID, Standard-Code-Editor vornehmen, die wir bereits bei der Installation von Git festgelegt haben, sowie die Konfiguration für das Zeilenende. Mach dir keine Sorgen. Sie sind sehr einfach. Jetzt können wir diese Konfigurationseinstellungen auf drei Ebenen festlegen , auf Systemebene, die für alle Benutzer dieses Computers gilt. zweite Ebene ist die globale Ebene, die für das gesamte Repository des aktuellen Benutzers gilt, und die dritte Ebene ist die lokale Ebene, die für das aktuelle Repository gilt. Hab keine Angst, mach es einfach wie ich. Öffnen Sie Terminal oder ITBASHF, wir schreiben es als Konfiguration für die globale Ebene und fügen den Benutzerpunktnamen Hier fügen wir Doppelcodes hinzu und hier gebe ich meinen Namen ein. Lassen Sie mich mit Strg und Plus ein wenig zoomen, oder wir können Strg und Scrollen mit der Maus verwenden. Gut. Drücken Sie jetzt Enter. Hier verwenden wir Doppelcodes, weil unser Wert ein Leerzeichen enthält. Außerdem musst du hier deinen richtigen Namen schreiben. Welchen Namen Sie auch immer hier schreiben, Sie können diesen Namen in der Repository-Historie sehen. Lassen Sie uns nun auf die gleiche Weise E-Mails hinzufügen. Drücken Sie den Aufwärtspfeil, um den vorherigen Befehl zurückzugeben, und hier an der Stelle des Benutzerpunktnamens schreiben wir eine Benutzer-Punkt-E-Mail. Und hier haben wir keinen Platz in unserem Wert. Wir können diese Doppelcodes entfernen und ich schreibe hier einfach meine E-Mail. Lassen Sie uns nun unseren Standard-Code-Editor einstellen. Wie ich Ihnen bereits sagte, werden wir in diesem Kurs VS-Code verwenden. Wenn Sie keinen VS-Code haben, können Sie ihn von code.visualstudio.com herunterladen Jetzt zurück zu unserem Git-Pash und wir schreiben Git Config Dash Hier fügen wir auch Doppelcode-Code hinzu , der Visual Studio-Code ist, warte Jetzt fragst du dich vielleicht, warum wir hier hinzufügen, warte? Dieses Gewicht weist unser Terminal an, zu warten, bis wir das VS-Codefenster schließen. Hier speichern wir alle unsere Konfigurationseinstellungen in der Textdatei und um diesen Stapel anzusehen oder zu bearbeiten, schreiben wir config Global E. Drücken Sie Enter. Siehst du, hier bekommen wir die Konfigurationsdatei per Code rein. Von hier aus können wir die konfigurierten Werte ändern und wenn wir hier zu unserer Git-Pase zurückkehren , können wir sehen, dass sie darauf wartet, dass unser Editor die Datei schließt, und das liegt daran, dass wir hier warten hinzufügen Lassen Sie uns diese Git-Konfigurationsdatei schließen und sehen, wie wir sie beenden. Jetzt haben wir fast unsere Konfigurationseinstellungen abgeschlossen. Wir müssen nur eine Konfiguration machen , die für das Ende der Zeilen gilt. Dies ist eine sehr wichtige Einstellung, die viele Entwickler vermissen und vergessen. Diese Einstellung ist sehr nützlich , wenn Sie plattformübergreifend arbeiten . Sie verwenden beispielsweise Windows als Betriebssystem und ein anderer Kollege verwendet das Mac-Betriebssystem. Wenn Sie eine Textdatei zu Git für Windows hinzufügen, verwendet diese Datei R N. Dabei handelt es sich um Sonderzeichen, die in TextFile verwendet werden, um das Layout und die Struktur von Zeilen im Dokument zu verwalten Aber unter macOS oder Linux verwenden Textdateien nur N. Wenn wir uns also nicht mit der Eigenschaft „ Zeilenende“ befassen, treten in Git einige seltsame Probleme auf dieses Problem zu beheben, haben wir nun eine Konfigurationseinstellung namens autoCRLF, was Carriage Return und Line Feed also hier in unserem Beispiel unseren Wenn wir also hier in unserem Beispiel unseren Code in das Git-Repository einfügen, entfernt G alle Zeilenumbrüche und ersetzt ihn durch den Zeilenvorschub Wenn wir nun wieder denselben Code erhalten wollen, aktualisiert Git unseren Code erneut mit Zeilenumbruch und Zeilenvorschub. Hier müssen wir also diese CRLF-Eigenschaft auf Tru setzen , wodurch dieser Code automatisch konvertiert wird Wenn nun ein Mac- oder Windows-Benutzer den Code zu demselben Repository hinzufügt, dann müssen Sie diesen Code nicht aktualisieren, da er sich bereits im Zeilenfeed befindet Hier müssen Mac- und Linux-Benutzer diese autoCRLF-Eigenschaft auf die Eingabe setzen, bei der es sich um den ursprünglichen Typ handelt Mach dir darüber keine Sorgen . Du musst das nicht so tief verstehen. Tun Sie einfach wie ich und schon können Sie loslegen, denn das Einstellen der Konfiguration ist ein einmaliger Vorgang. In unserem Git Bach schreiben wir Git Config Global. Co dot atosRF auf True. Wenn Sie ein Mac-Benutzer oder ein Linux-Benutzer sind, müssen Sie hier an der Stelle von True eine Eingabe hinzufügen und die Eingabetaste drücken Hier ist unsere Konfiguration abgeschlossen. Jetzt können wir anfangen, Git zu lernen. 6. So lässt du Git Bash gut aussehen: Derzeit sieht unsere Gdbash so aus. Lass uns unsere Gitbash cool aussehen lassen. Es macht Spaß. Wenn Sie ein einfaches Terminal in Windows verwenden, wo ich vorschlage, gtbash zu öffnen, klicken Sie mit der rechten Maustaste auf Gitbsh und hier unten erhalten Hier können wir Farben oder ein Thema auswählen. Hier haben wir viele Themen. Das sind also sehr anständige Themen. Ich persönlich mag das Dracula-Thema. Siehst du, das sieht nett aus. Danach können wir die Transparenz und den Cursor ändern und den blinkenden Cursor auswählen Gehen wir jetzt zum Text. Hier können wir Schriften auswählen. Sie können versuchen, diese Schriftarten zu ändern. Ich bin mit der aktuellen Schrift zufrieden, also kann ich sie verkaufen. Außerdem glätte ich die Schriftarten auf den vollen Wert und wende die Einstellungen an und speichere sie und sehe, dass unser Git-Pash so aussieht. Wenn du ein anderes Theme oder eine andere Schriftart ausprobieren möchtest, dann kannst du das auch tun Ich bin mit den Einstellungen zufrieden. Jetzt fangen wir an, Git zu lernen. 7. Abschnitt 02 Git-Grundlagen: Willkommen im zweiten Abschnitt des ultimativen Kit-Kurses. In diesem Abschnitt werden wir sehr grundlegende Konzepte von Kit erlernen , die jeder Kit-Benutzer kennen sollte. Wir beginnen also zunächst damit, den Arbeitsablauf des Kits zu verstehen. Du wirst lernen, wie Git wirklich funktioniert, wie man seine Repositorys initialisiert , Codeverlauf aufzeichnet, Staging Commit durchführt. Das sind wirklich wichtige Konzepte, weil viele Entwickler nicht wissen, wie es funktioniert, und dann sind sie sehr verwirrt Schauen Sie sich also diesen kompletten Abschnitt an, auch wenn Sie sich mit den Grundlagen von Kit auskennen, denn viele Entwickler missverstehen diese Konzepte wirklich und Schauen Sie sich also jede Lektion dieses Abschnitts an. Lassen Sie uns darauf eingehen. 8. Das Git-Projekt initialisieren: Um mit Git zu arbeiten, müssen wir zunächst Git zu unserem Projekt oder Ordner hinzufügen Wenn wir Git nicht zu unserem Projekt hinzufügen, woher sollte Git dann wissen, welchen Ordner es verfolgen muss? Hier bin ich im Ordner des Projekts und hier erstelle ich einen neuen Ordner, sagen wir, Task-Track. Dies ist der erste Projektname, den ich in meinem ultimativen React-JS-Kurs erstellt habe . Machen Sie sich darüber auch keine Sorgen. Wir werden kein bestimmtes Projekt erstellen. Hier liegt unser Hauptaugenmerk darauf, Git zu beherrschen. Jetzt müssen wir diesen Ordnerpfad in unserem Terminal oder Git Bash öffnen diesen Ordnerpfad in unserem Terminal oder Git Bash Wenn Sie ein Windows-Benutzer sind, klicken Sie mit der rechten Maustaste hier und Sie haben die Möglichkeit , Git Bash hier zu öffnen Sehen Sie, wir öffnen unseren Ordner in der Git Bash, und wenn Sie Mcuser sind, klicken Sie mit der rechten Maustaste auf Ihren Ordner und Sie erhalten die Option Neues Terminal im Ordner öffnen Lassen Sie uns nun Git in unserem Ordner initialisieren. Hier schreiben wir einfach Git hinein und drücken Enter. Sehen Sie hier, wir erhalten eine Nachricht leeres Git-Repository mit unserem Ordnerpfad initialisiert Außerdem können wir hier sehen, dass wir Master bekommen, was einfach bedeutet, dass unser Ordner dafür bereit ist Wenn in unserem Task-Track-Verzeichnis Verzeichnis Verzeichnis Ordner bedeutet, erhalten wir ein anderes Verzeichnis namens.it. Wenn Sie diesen Ordner hier nicht finden, gehen Sie zur Option Ansicht und suchen Sie hier Standardmäßig ist dieses Verzeichnis ausgeblendet, da wir es nicht berühren müssen. Aber lassen Sie mich zeigen, was sich in diesem Ordner befindet? Grundsätzlich speichert der Git-Ordner Informationen über unseren Projektverlauf. Sehen Sie, hier erhalten wir eine Reihe von Ordnern wie Hooks, Informationen, Objekte, Referenzen und einige andere Dateien. Wenn Sie es verwenden, müssen Sie sich keine Gedanken über all diese Dateien machen. Diese Dateien enthalten Implementierungsdetails darüber, wie es Informationen speichert. Mach dir darüber keine Sorgen. Das ist nicht unser Geschäft. Unser Ziel ist es, Git zu verwenden und uns das Leben zu erleichtern. Deshalb ist das Punkt-Git-Verzeichnis standardmäßig versteckt. Wenn Sie etwas in diesem Verzeichnis tun oder das gesamte IT-Verzeichnis löschen, verlieren Sie Ihren Projektverlauf. In meiner Firma hat einer meiner Freunde diesen Git-Ordner aus seinem Projekt entfernt und dann versucht, alle darin enthaltenen Befehle zu verwenden, aber sie funktionieren nicht, weil der Ordner.it nicht verfügbar ist Lass mich dir das zeigen. Hier in unserer Git-Bash steht Master in Klammern, was bedeutet, dass Git diesen Ordner verfolgt das Git-Verzeichnis zu entfernen, können wir nun RM schreiben, um R rekursiv zu entfernen, F für Force, und Drücken Sie die Eingabetaste. C, Git wurde aus diesem Verzeichnis entfernt. Deshalb ist der Ordner.it wichtig. Lassen Sie uns nun Git erneut in unserem Projekt initialisieren und dafür, welchen Befehl wir richtig verwenden, verwenden wir Git darin Sehen Sie, wir machen unseren Ordner wieder zum Git-Repository. Git-Repository bedeutet im Grunde dass Git diesen Projektverlauf verfolgt. So einfach ist das. In der nächsten Lektion werden wir nun genau verstehen, wie Git funktioniert. 9. Wie funktioniert Git wirklich?: Also hier initialisieren wir unser Git-Repository. Lassen Sie uns nun sehen, was die häufigsten täglichen Schritte sind , die Entwickler damit machen Wir werden das anhand eines Beispiels aus dem wirklichen Leben verstehen. Stellen Sie sich vor, Sie schreiben ein Märchenbuch wie Harry Potter. Nun, hier willst du nichts direkt in dein Märchenbuch schreiben, du arbeitest oder schreibst in eine andere Datei Nehmen wir nun an, Sie schreiben das erste Kapitel überprüfen Sie zuerst, es korrekt ist oder nicht Wenn es nicht korrekt ist, ändern oder aktualisieren Sie diese Datei. Wenn sie korrekt ist, machen Wenn sie korrekt ist, Sie erst dann einen Screenshot dieser Datei und fügen sie Ihrem Storybook Das ist auch der Workflow von Git. Lass es mich dir erklären. Hier in unserem Git-Repository, das zum Beispiel unser Storybook ist Jetzt wollen wir unseren Code nicht direkt hinzufügen, denn was auch immer wir in unserem Git-Repository hinzufügen, Git speichert es in der Historie Wir fangen an, lokal zu arbeiten, das ist unser Task-Track-Ordner. Nehmen wir nun an, wir erstellen eine Datei in diesem Ordner und müssen sie als Historie als unsere Schreibdatei speichern . Denken Sie jetzt daran, dass wir überprüfen, ob alles in Ordnung ist oder nicht, bevor wir unsere Geschichte speichern. Hier machen wir das auch. Wir prüfen, ist es okay oder nicht? Wollen wir etwas hinzufügen oder entfernen? Dieser Überprüfungsbereich wird als Staging-Bereich bezeichnet. Jetzt fragst du dich vielleicht, warum wir diesen Staging-Bereich brauchen. Ohne diesen Staging-Bereich, was auch immer wir in unserem lokalen Code tun, wird der gesamte Code direkt in unserem Repository gespeichert und wir haben keine Chance zu sehen, was wir im Vergleich zum vorherigen Code ändern oder entfernen Aus diesem Grund wird ein Staging-Bereich benötigt. Nachdem wir unseren Code zum Staging-Bereich hinzugefügt haben und nur dann zufrieden sind, machen wir einen Screenshot unseres Codes und speichern ihn in unserem Git-Repository Jetzt fragst du dich vielleicht, wie wir unseren lokalen Code zum Staging-Bereich hinzufügen können unseren lokalen Code zum Staging-Bereich Oder wie können wir unsere Staging-Vorwahl zur Git-Historie hinzufügen unsere Staging-Vorwahl zur Git-Historie Die Antwort ist mit Git-Befehlen sehr einfach. Nehmen wir an, wir fügen hier eine weitere Datei namens Index Dot gs hinzu. Wir möchten diese Datei im Staging-Bereich hinzufügen. Hier schreiben wir den Befehl Git add und hier schreiben wir unseren Dateinamen index dot js Hier können wir auch mehrere Dateinamen hinzufügen. Mit diesem Befehl fügen wir unseren Code im Staging-Bereich Eine Sache, die ich klarstellen möchte, ist Staging-Bereich kein Ordner ist Der Staging-Bereich ist nur temporärer Speicher, den Git uns zur Verfügung stellt. Viele Entwickler bezeichnen den Staging-Bereich als Index. Hier überprüfen wir, ob unser Code korrekt ist oder nicht. Wenn er nicht korrekt ist, können wir ihn aktualisieren oder korrigieren, da wir keinen fehlerhaften Code in der Historie speichern möchten. Wenn wir nun bereit sind, diese Datei in unserem Verlauf zu speichern, machen wir einen Snapshot des Staging-Bereichs und speichern ihn mit Git in der Git-Historie. GamTTH ist die Abkürzung Hier schreiben wir unsere Nachricht , die wir mit diesem Snapshot speichern möchten In Zukunft werden wir wissen, was wir in diesem Kummet hinzufügen. Commit bedeutet, den Snapshot im Git-Verlauf zu speichern. zum Beispiel in Zukunft Fehler beheben oder neue Funktionen hinzufügen, Wenn wir zum Beispiel in Zukunft Fehler beheben oder neue Funktionen hinzufügen, erstellen wir für jeden Camt, den wir hinzufügen, eine Commit-Nachricht, die deutlich sagt, was wir in diesem Kat getan haben Auf diese Weise können wir ganz einfach einen Blick auf unseren Code-Verlauf werfen. Stellen Sie sicher, dass Sie jedes Mal, wenn Sie etwas begehen, eine aussagekräftige Nachricht hinzufügen. Jeder Commit, den wir machen, wird mit einer eindeutigen ID, Datum und Uhrzeit, dem Namen des Autors, der E-Mail-Adresse und unserer Commit-Nachricht gespeichert Datum und Uhrzeit, dem Namen des Autors, . Anhand dieser Details können wir sehen, welche Änderungen von wem und wann vorgenommen wurden. Nehmen wir nun an, wir fügen hier eine weitere Datei namens data dot TXT hinzu. Sag mir, was wir tun müssen, um diese neue Datei in der Geschichte zu speichern. Stimmt. fügen wir unseren Code mit Git add data dot TXT zum Staging-Bereich hinzu Danach können wir einen Snapshot dieses aktuellen Staging-Bereichs erstellen und ihn im Git-Repository speichern , indem wir Git Commit verwenden und dem Datenpunkt TxDFle hinzufügen Hier möchte ich eines klarstellen: Nach dem Commit des Codes aus dem Staging-Bereich in das Git-Repository wird klarstellen: Nach dem Commit des Codes aus dem Staging-Bereich in das Git-Repository unser Staging-Bereich Es wird so bleiben, wie wir uns verpflichten. Wenn wir in Zukunft etwas zu unserem lokalen Code hinzufügen oder entfernen und es dann in unserem Staging-Bereich hinzufügen, dann nur die Dateiaktualisierungen, die wir geändert haben Um kurz zusammenzufassen, wie der Code in unserer Git-Historie Zuerst fügen wir unseren Code dem Staging-Bereich hinzu. Wenn wir danach mit unserem aktuellen Code zufrieden sind, werden wir diesen Code erst dann in unser Git-Repository übernehmen und das Git-Repository speichert alle Befehle So einfach ist das. Machen Sie sich keine Sorgen , wenn Sie verwirrt sind oder viele Fragen haben werden Sie alle Antworten bekommen Im weiteren Verlauf dieses Kurses werden Sie alle Antworten bekommen, und ich wette, Sie werden Git wie P beherrschen. In diesem Abschnitt werden wir praktisch mit diesem Git-Workflow arbeiten. 10. Übung: Git-Workflow: In der vorherigen Lektion lernen Sie den grundlegenden Arbeitsablauf kennen. Jetzt möchte ich, dass Sie mit den beiden Befehlen die grobe Figur oder den groben Ablauf des Gangs zeichnen mit den beiden Befehlen die grobe Figur oder den groben Ablauf des Gangs Schließe die eine kleine Übung ab, aber die Bedingung ist, dass du dir die vorherige Lektion nicht ansehen kannst Versuche dich daran zu erinnern und zeichne es dann auf das Papier oder irgendwo anders. Wenn du auf Papier zeichnest, kannst du ein Foto machen und es im Bereich Fragen und Antworten hochladen Ich werde versuchen, Ihre Einreichung zu überprüfen und zu beantworten. Nach Abschluss dieser Übung können Sie sich die vorherige Lektion ansehen und sich vergewissern, dass Ihr Arbeitsablauf korrekt ist oder nicht. Es ist ein kleines Spiel. Mach dir keine Sorgen über Verlieren oder Gewinnen. 11. Dateien zum Staging-Bereich hinzufügen: Lassen Sie mich Ihnen nun praktisch zeigen, wie wir Dateien zum Stitching-Bereich hinzufügen können Aber zuerst müssen wir eine Datei in unseren lokalen Code einfügen. Ich öffne den Task-Track-Ordner im VS-Code und erstelle hier zunächst eine neue Datei namens Chapter One Dot TXT. Und hier schreiben wir Hallo. Ich erstelle hier eine XD-Datei, aber Sie können jede Datei erstellen. Speichern Sie diese Datei. Jetzt wollen wir diesen Stapel dem Staging-Bereich hinzufügen. Lassen Sie mich in unserer Git-Basis den aktuellen Status überprüfen. Wenn du die vorherigen Befehle löschen möchtest, dann können wir hier klar schreiben. Es wird alle unsere vorherigen Befehle löschen. Lassen Sie uns den Status mit dem Git-Status überprüfen. Sehen Sie hier, wir kommen auf Branch, Master, noch keine Commits Und wir erhalten eine Datei, die nicht nachverfolgt wurde, das ist Kapitel eins mit Punkt TXT Und es gibt uns auch Vorschläge mit dem Befehl Git add, Dateiname Also können wir hier schreiben, Git hinzufügen, und hier können wir Kapitel eins Punkt TXT schreiben. Wenn wir weitere Dateien hinzufügen möchten, können wir hier mit Leerzeichen, Kapitel zwei Punkt-TXT usw. bearbeiten . Wir können hier auch Star Dot TXT verwenden, was bedeutet, dass alle Dateien mit der Erweiterung TXT hinzugefügt Außerdem können wir hier Git add period verwenden, was bedeutet, dass alle Dateien hinzugefügt werden. Normalerweise verwenden viele Entwickler diese Methode, sodass wir jeden dieser Befehle verwenden können. Hier verwende ich Git Add Chapter One Dot TXT. Jetzt sehen wir hier nichts, aber wie können wir überprüfen, ob diese Datei im Staging-Bereich hinzugefügt wurde oder nicht Kannst du mir sagen, dass wir es einfach benutzen? Wir können den Git-Status verwenden. Sehen Sie hier, wie sich die Nachricht ändert und das war's. Wir fügen unsere Datei im Staging-Bereich hinzu. Nehmen wir nun an, wir ändern etwas in unserer Datei. Hier füge ich die Welt in der zweiten Zeile hinzu. Und speichere diese Datei. Lassen Sie uns jetzt den Status erneut überprüfen Rufen Sie den Status ab und drücken Sie die Eingabetaste. Sehen Sie jetzt hier, wo wir die Meldung „Geändert“ bekommen. Derzeit haben wir in unserem Staging-Bereich unseren vorherigen Bearbeitungscode, bei dem es sich um die Datei in Kapitel eins handelt, die nur eine Hallo-Nachricht Jetzt ändern wir etwas in unserem lokalen Code, dann müssen wir diese Änderungen erneut zu unserem Staging-Bereich hinzufügen, denn um unseren Code in die Git-Historie zu übernehmen, müssen wir unseren Code aus dem Staging-Bereich übergeben Hier können wir wieder Git schreiben und Kapitel eins Punkt TXT hinzufügen. Wenn wir unseren Status erneut überprüfen, erhalten wir keine ausstehenden Änderungen. So fügen wir unseren Code im Staging-Bereich hinzu. Außerdem möchte ich Ihnen sagen, wenn Sie Knoten erstellen möchten, können Sie damit beginnen, Ihre Knoten für Gate-Befehle zu erstellen Ich werde auch meine Knoten hinzufügen, aber Sie können auch Ihre eigenen Knoten verwenden. 12. Lass uns deine erste Datei übernehmen: Derzeit befinden sich unsere Dateien im Staging-Bereich. Lassen Sie uns nun unsere Datei in die IT-Historie übernehmen. In Git Bash schreiben wir es also Commit. Hier können wir für eine Nachricht schreiben, und in Doppelcodes fügen wir unsere Commit-Nachricht Sagen wir anfängliches Commit. Jetzt schreiben wir hier eine kurze Beschreibung unseres Mantels. Aber manchmal möchten wir weitere Beschreibungszeilen hinzufügen. Zum Beispiel reparieren wir die Burg, dann können wir in der Beschreibung hinzufügen, was diese Burg war, und wir können das nicht in einer einzigen Zeile erklären. mehrere Zeilen mit einer Beschreibung hinzuzufügen, geben wir hier nur get coat ein. Und drücken Sie die Eingabetaste. Dadurch wird ein Standard-Code-Editor geöffnet, den wir in unserer Konfiguration hinzugefügt haben. Erinnerst du dich? Großartig. Jetzt müssen wir hier in der ersten Zeile unsere Kurzbeschreibung eingeben und für eine lange Beschreibung müssen wir sie in die neue Zeile schreiben. Für diesen Commit fügen wir eine kurze Nachricht hinzu, z. B. initialer Commit für eine lange Beschreibung, wir können schreiben, das erste Kapitel abschließen. Nehmen Sie einige Änderungen an der Geschichte vor. Ich schreibe nur eine zufällige Nachricht für die Demo. Mach dir keine Sorgen. Ich werde hier kein Märchenbuch schreiben. Jetzt fragst du dich vielleicht, was ist mit diesen Zeilen? Diese Zeilen sind üblich, um diesen Teil der Beschreibung zu erklären, mach dir darüber keine Gedanken. Jetzt speichern wir diese Datei und schließen sie von hier aus. Wenn wir jetzt zu unserem Kit Dash zurückkehren, sehen Sie hier, dass eine Datei geändert und zwei eingefügt werden. Herzlichen Glückwunsch. Wir haben unsere erste Auslassung erfolgreich gemacht Um das zu überprüfen, können wir Kit-Statistiken schreiben und sehen, dass wir hier nichts festschreiben müssen. Working Tree Clean, was einfach bedeutet, dass unsere Arbeitsbereichsvorwahl, Staging-Vorwahl und der Snapshot im Git-Repository alle identisch sind So übertragen wir unseren Code in Git. Sie können sehen, dass es sehr einfach und leicht ist. 13. Wann solltest du dich engagieren: Heutzutage machen viele Entwickler bei der Verwendung von Git einen Fehler. Wenn sie etwas im Arbeitsbereich ändern, geben sie die Änderung sofort im Staging-Bereich an, was gut ist, aber sie übertragen auch all diese kleinen Änderungen das Git-Repository, was falsch ist Außerdem übertragen einige Entwickler große Änderungen direkt in das Git-Repository, und das ist auch falsch, weil wir nicht fünf Tage lang programmieren und dann den ganzen Code festschreiben wollen fünf Tage lang programmieren und dann den ganzen Code festschreiben Ist nicht der beste Weg. Sie fragen sich vielleicht, was ist die beste Vorgehensweise für Fell? Zuallererst möchte ich Ihnen sagen, dass Sie sich nicht für jede einzelne Änderung festlegen müssen. Das ist nutzlos, denn wie wir wissen, wird alles, was wir verpflichten, in der Geschichte gespeichert Wenn Sie alle kleinen Änderungen vornehmen, wird es sehr schwierig werden, aus der Geschichte herauszufinden, was Sie wollen . Die Camt-Größe sollte nicht zu klein oder zu groß sein. Sie sich immer dann, wenn Sie glauben einen bestimmten Status erreicht haben , den Sie aufnehmen möchten Stellen Sie sich vor, Code zu übertragen ist wie bestimmte Checkpoints , die Sie einrichten möchten Wenn bei Ihrer aktuellen Implementierung etwas schief geht, können Sie zum vorherigen Checkpoint gehen und Ihre Implementierung neu starten Erinnerst du dich an das Videospielkonzept für Checkpoints? Wenn du etwas Schwieriges erfolgreich abschließt, erhältst du den Checkpoint , der dein Spiel sicherstellt Denke so. Eine andere Sache ist jeder Commit einen logisch separaten Kettensatz darstellen sollte Commit einen logisch separaten Kettensatz Vermische nichts. Beispiel: Sie lösen einen Bug und haben auch einige Verbesserungen am Design gefunden, dann müssen Sie nicht beide Änderungen in einem Commit übernehmen. Sie können zwei separate Commits durchführen, einen zur Behebung des XYZ-Bugs und dann zur Verbesserung der Kartenstile Eine weitere bewährte Methode für Komitees ist, dass Sie eine aussagekräftige Commit-Nachricht schreiben müssen , da Sie mit der Commit-Nachricht Ihren Checkpoint in der Historie finden Also das sind meine Kassetten für den Mantel. Aber am Ende können Sie Ihre Situation am besten beurteilen. Denke nicht darüber nach, du wirst keine Fehler machen. alle werden einige Fehler machen, aber wir können aus unseren Fehlern lernen, oder? Versuche dich an diese Bänder zu erinnern. Es wird dir auf deiner Reise zum Gate helfen. 14. Übung für den Commit: Jetzt ist es an der Zeit, etwas Übung zu machen, um das zu kontrollieren, was wir in früheren Lektionen gelernt haben Ich möchte, dass Sie eine neue Datei mit dem Namen Chapter Two Dot TXT erstellen und etwas in diese Datei schreiben Nachdem Sie Text hinzugefügt haben, müssen Sie diese Datei in das Kid-Repository übertragen. Ich weiß, dass das ziemlich einfach ist und Sie können diese Übung abschließen, loslegen und sich dann die Lösung ansehen. Ich hoffe also, dass Sie diese Übung abschließen oder zumindest versuchen, sie zu lösen. Sehen wir uns nun die Lösung an. Ich erstelle hier eine neue Datei Kapitel zwei Punkt TXT. Und hier füge ich einfach hinzu, dass Learning Git eine lustige Erfahrung ist. Wenn du weißt, wie Git funktioniert, stimmst du dem zu? Lass es mich wissen. Speichern Sie diese Datei, und hier kehren wir zuerst zu unserer Git Bash zurück, welcher Status Sehen Sie hier, dass wir eine Datei erhalten , die nicht nachverfolgt wurde, und zwar im zweiten Kapitel mit dem Punkt TXT Wir müssen diese Änderungen zuerst implementieren und dann können wir sie übernehmen Also schreiben wir Git und fügen Kapitel zwei Punkt TXT hinzu. Wenn Sie hier keinen vollständigen Dateinamen schreiben möchten, können Sie, . Daraufhin indem Sie den halben Namen eingeben, die Tabulatortaste drücken werden nicht verfolgte oder geänderte Dateinamen zurückgegeben Das ist ein kleiner Trick. wir einfach Git Commit ein, schließen das zweite Kapitel ab und drücken die Eingabetaste. Sehen Sie hier, dass wir einen weiteren Commit machen, damit Sie sehen können, wie einfach und leicht es ist, Code zu übertragen. 15. So überspringt man den Staging-Bereich: Nun, die häufigste Frage, die sich viele IT-Benutzer stellen, lautet Können wir den Staging-Bereich überspringen Die Antwort lautet ja. überspringe den Staging-Bereich nicht wirklich, aber wie wir wissen, müssen wir für das Commit des Codes diese beiden Befehle verwenden Aber was Gangart angeht, haben wir noch einen anderen Befehl, nämlich die Kombination dieser beiden Befehle, aber das ist keine Tun Sie das nur, wenn Sie zu 100% sicher sind, dass Sie Ihren Code nicht überprüfen müssen Ihren Code nicht überprüfen müssen , denn das ist der Zweck des Staging-Bereichs Erinnern Sie sich an unser Bilderbuch-Beispiel. Lassen Sie mich Ihnen zeigen, wie wir den Staging-Bereich überspringen können Lassen Sie mich zunächst etwas in der Datei von Kapitel eins ändern Fangen wir mit Kapitel eins an. Speichern Sie die Änderungen und kehren Sie zu Git Bash zurück. Lass uns den Status überprüfen. Siehst du, wir bekommen eine modifizierte Datei. Um diese Änderungen zu übernehmen, müssen wir, wie wir wissen, zwei Befehle schreiben. Zuerst müssen wir die Datei bereitstellen und dann Commit hinzufügen. Aber hier können wir direkt Gate Commit A schreiben, das für alle modifizierten Änderungen und dann für die Nachricht gilt. Oder wir können das einfach gemeinsam am machen und danach können wir unsere Commit-Nachricht schreiben, Anfang von Kapitel eins. Und drücken Sie die Eingabetaste. Sehen Sie, dass es erfolgreich an das Gate übergeben wurde. Lassen Sie uns das mit Git Status überprüfen. Siehst du, wir haben nichts zu verpflichten. Dieser Befehl fügt außerdem alle Änderungen im Staging-Bereich hinzu und überträgt den Code auch in das Git-Repository Aber wie gesagt, benutze diesen Befehl nur, wenn du dir zu 100% sicher bist 99% der Fälle stellen wir zuerst unseren Code bereit und dann übergeben wir ihn an das Gate. 16. Dateien aus Bereichen entfernen: Nehmen wir nun an, wir stellen fest, dass wir Kapitel zwei nicht benötigen, oder wir möchten die Datei aus Kapitel zwei löschen. Aus dem VS-Code lösche ich diese Datei. Gut. Lassen Sie uns jetzt unseren Status überprüfen. Status abrufen. Sehen Sie, hier können wir sehen, dass wir die Datei aus Kapitel zwei gelöscht haben, weil wir unsere Datei aus dem Arbeitsverzeichnis löschen, aber diese Datei ist immer noch im Staging-Bereich verfügbar Lass es mich dir zeigen. Also hier schreiben wir Gates-Dateien. Dieser Befehl gibt alle Dateien zurück , die im Staging-Bereich verfügbar sind Siehst du, wir bekommen Kapitel eins und Kapitel zwei. Wie ich Ihnen bereits sagte, müssen wir jedes Mal, wenn wir einige Änderungen vornehmen, diese Änderungen im Staging-Bereich mit dem Befehl add hinzufügen Hier schreiben wir also Gate, fügen Kapitel zwei hinzu, um die Änderungen hinzuzufügen, oder wir können sagen, dass wir die Datei mit Kapitel zwei löschen Lassen Sie uns nun die Dateien im Staging-Bereich noch einmal überprüfen. Holen Sie sich S-Dateien. Hier bedeutet S Liste. Siehst du, hier bekommen wir nur die Datei aus Kapitel eins. Lassen Sie uns nun unseren Status mithilfe von Git Status überprüfen. Siehst du, hier machen wir uns bereit, uns zu verpflichten. Wir können Git Comet für Nachricht schreiben, Kapitel zwei löschen. Und fertig. Wir haben unsere Datei mit Kapitel zwei erfolgreich aus unserem lokalen Bereich und unserem Staging-Bereich gelöscht . Was auch immer wir tun, eine neue Datei erstellen oder die bestehende Datei löschen, wir müssen diese Änderungen zuerst dem Staging-Bereich hinzufügen und dann können wir sie übernehmen So einfach ist das. Jetzt fragst du dich vielleicht, gibt es eine Abkürzung oder lösche unsere Datei aus dem Arbeitsbereich und dem Staging-Bereich und ihr habt Recht Ja, es gibt einen Befehl , der diese beiden Schritte in einem Schritt ausführt Wir können schreiben: get RM RM heißt remove. Und hier fügen wir unseren Dateinamen hinzu, sagen wir Kapitel zwei mit dem Punkt TXT. Außerdem können wir hier mehrere Dateinamen hinzufügen und auch alle Dateien mit dem Sternpunkt TXT entfernen, was bedeutet, dass alle Dateien mit der Erweiterung TXT entfernt werden. Mit diesem Befehl können wir unsere Datei sowohl aus dem lokalen Bereich als auch aus dem Staging-Bereich entfernen sowohl aus dem lokalen Bereich als auch aus dem Staging-Bereich 17. Dateien in Git ignorieren [GitIgnore]: Jetzt haben wir manchmal in unserem Projekt einen Ordner oder eine Datei, haben wir manchmal in unserem Projekt einen Ordner oder eine Datei die wir gerade für unseren Gebrauch erstellt Wir wollen das nicht in das Git-Repository stellen. Wenn Sie beispielsweise Node-Pakete verwenden, erhalten Sie einen Node-Module-Ordner mit Tausenden von Dateien, sodass wir ihn nicht zu unserem Git-Repository hinzufügen möchten. Es wird die Größe unseres Repositorys ohne irgendeinen Wert erhöhen . Ein anderes Beispiel sind temporäre Dateien oder Protokolldateien , die nicht benötigt werden , um ein Git-Repository hinzuzufügen. Lassen Sie mich Ihnen eine Geschichte von meinem Freund, mir und meinem Freund erzählen , die in einer Unternehmensfirma gearbeitet haben. Mein Freund Harley wusste nichts über Gate. Er hat nur Githd und Git verpflichtet. Eines Tages legte er seine persönliche Passwortdatei mit dem Code Alle Teammitglieder kommen an seinen Schreibtisch und erzählen ihm von seinem Passwort und er weiß nicht, woher alle Teammitglieder sein Passwort kennen. Zu diesem Zeitpunkt müssen wir diese Datei ignorieren oder wir können auch den gesamten Ordner ignorieren. Lassen Sie mich Ihnen das praktisch zeigen. Hier in unserem Task-Track-Ordner erstellen wir einen neuen Ordner namens logs zum Speichern von Debugging - oder Anwendungsprotokollen Hier fügen wir eine neue Datei namens Debug Dot Log in diese Datei ein, wir fügen etwas Text hinzu Dies ist das Debugging-Protokoll. Speichern Sie die Änderungen. Wenn Sie hier wenig aufpassen, wenn wir eine neue Datei in unserem Ordner erstellen, unsere Datei oder unser Ordner mit der grünen Farbe in der rechten Ecke des Dateinamens hervorgehoben der grünen Farbe in der rechten Ecke des Dateinamens erhalten wir das U-Symbol Kannst du dir vorstellen, was dieses U bedeutet? Schreiben? U bedeutet nicht verfolgte Datei Grundsätzlich teilt uns VSC mit, diese Datei im Staging-Bereich nicht verfügbar ist Mach dir darüber keine Sorgen . Ich werde dir das alles in den kommenden Lektionen erklären. Nun zurück zu unserem Gitbsh hier, wenn wir Git Status machen, dann bekommen wir Dateien, die nicht Wenn wir hier Git add schreiben, dann wird dieser Log-Ordner auch in unseren Staging-Bereich aufgenommen und das wollen wir nicht Wie können wir diese Dateien also ignorieren? Sehr einfach. Nur in unserem Projekt erstellen wir eine neue Datei namens Dot Git Ignore. Stellen Sie sicher, dass Sie den gleichen Dateinamen ( Punkt Git Ignore) schreiben den gleichen Dateinamen ( Punkt Git Ignore auch diese Datei sollte sich in unserem Projektstammverzeichnis befinden. In jedem anderen Ordner. Nur dann wird es funktionieren. Im Grunde teilt diese Get Ignoriere-Datei Git mit, welche Dateien oder Ordner wir ignorieren wollen. Hier wollen wir den kompletten Logs-Ordner ignorieren. Wir schreiben Logs als Schrägstrich. Wenn wir den Ordner der Node-Module ignorieren wollen, dann schreiben wir Node-Underscore-Module oder wenn wir eine bestimmte Datei ignorieren wollen, dann können wir auch Logs mit Schrägstrich, Debug-Punktprotokoll schreiben Wir können hier alles machen. Sobald wir diese Datei speichern, können wir sehen, dass das U-Symbol aus unserer Protokolldatei verschwunden ist. Außerdem sind unser Ordner und unser Dateiname grau, was bedeutet, dass alle Dateien im Protokollordner ignoriert werden. Lass es mich dir noch einmal zeigen. Ich entferne diese Zeilen und speichere sie. Sehen Sie hier, wir bekommen U und wenn wir noch einmal einen Log-Schrägstrich hinzufügen und es speichern, dann ignorieren wir diese Dateien Lassen Sie uns diese anhand des Status überprüfen und sehen, dass wir nur eine Datei auf dem Track-Pile haben, nämlich Gino, den wir gerade Fügen wir es mit Git add dot gitignore hinzu und dann Git co, ignoriert alle Logdateien und Wunderbar. So können wir Dateien in Git ignorieren. Denken Sie jedoch daran, dass wir auf diese Weise nur die Datei oder den Ordner ignorieren können, die noch nicht festgeschrieben sind. In einfachen Worten, wenn wir unsere TXT-Datei mit Kapitel-Ein-Punkt jetzt ignorieren wollen , dann können wir das nicht einfach mit Git Ignore file tun, weil unsere Chapter-Eins-Datei bereits im Git-Repository festgeschrieben ist. Also müssen wir zuerst unsere Datei aus dem Staging-Bereich entfernen unsere Datei aus dem Staging-Bereich und dann können wir diese Datei ignorieren Lassen Sie mich Ihnen zeigen, wie wir das machen können? Hier in unserem Projektordner erstelle ich einen neuen Ordner namens, sagen wir, Ben. Und in diesem Ordner erstellen wir eine neue Datei namens Backup Dot Ben. Machen Sie sich keine Sorgen um diese Dateinamen. Es ist nur zur Demo. Hier fügen wir Text wie Hallo hinzu. Speichern Sie das und sehen Sie. Hier erhalten wir ein Symbol für eine nicht verfolgte Datei. Lassen Sie mich diese Datei jetzt versehentlich übertragen. Also schreibe ich in unserer Git-Bash Git Add Period , also alle Dateien und dann Git Commit Testing But Bin File und wir übergeben es Jetzt ist unsere Datei bereits festgeschrieben. Versuchen wir, diese Datei zu ignorieren. Lass mich dir zeigen , welche Dateien sich im Staging-Bereich von git As files Sehen Sie hier, wir können sehen, dass die Bupt-Bin-Datei bereits da ist. Wie können wir diese Datei also aus dem Staging-Bereich entfernen? In der vorherigen Lektion haben wir Git RM für Remove gesehen und wir haben unseren Dateinamen hinzugefügt, sagen wir, Been Slash Backup Dot Ben Aber mit diesem Befehl wird diese Datei aus dem Staging-Bereich, aber auch aus dem lokalen Bereich entfernt aber auch aus dem lokalen Aber hier wollen wir diese Datei lokal oder in unserem Arbeitsbereich haben Um Hilfe zu bekommen, schreiben wir H für Hilfe. Hier können wir sehen, dass wir die Option Dash Dash Cast haben, die nur aus dem Index entfernt wird. Index bedeutet Bereitstellungsbereich. Wir schreiben Git, RM, Dacast und müssen hier auch R für das rekursive Entfernen hinzufügen , weil wir alle Dateien aus dem Bin-Verzeichnis entfernen wollen Wenn wir hier R nicht schreiben, bekommen wir eine Fehlermeldung. Und wir fügen das Bin-Verzeichnis und unser Bin-Ordner wird aus dem Staging-Bereich entfernt Schauen wir uns auch unseren Staging-Bereich an, in dem sich diese Dateien stapeln. Sehen Sie, die Bin-Datei wurde von hier entfernt und lassen Sie uns unseren Status überprüfen Hier erhalten wir eine gelöschte Datei, aber wir erhalten auch eine Track-Datei von Hier müssen wir das Ben-Verzeichnis zu unserem Punkt Getting nor file hinzufügen . Speichern Sie das und sehen Sie, hier wird das Symbol gelesen, was gelöscht bedeutet. Lassen Sie uns den Status noch einmal überprüfen. Siehst du, hier bekommen wir eine gelöschte Datei und wir bekommen auch keine Datei geändert wurde, weil wir das Verzeichnis bin in unserer GTI-Nor-Datei hinzugefügt haben Verzeichnis bin in unserer GTI-Nor-Datei hinzugefügt Lassen Sie uns diese Änderungen festschreiben und das Verzeichnis bin, das versehentlich übernommen wurde , mit einem Commit entfernen Lassen Sie mich jetzt etwas in der Bin-Datei ändern. Speichern Sie das und sehen Sie, dass wir keine Änderungsnachricht erhalten, aber die Gitignore-Datei bleibt unverändert Kannst du mir sagen warum? Lassen Sie uns das mit dem Status überprüfen? Siehst du, hier bekommen wir eine modifizierte Gitignore-Datei , weil wir vergessen haben, unsere GetI no changes zum Staging-Bereich hinzuzufügen unsere GetI no changes zum Staging-Bereich Keine Sorge, das passiert mir oft. Also hier inszenieren wir die Änderungen einfach mit Git add period. Und dann ignoriert Git das Win-Verzeichnis und fertig. Sie können also sehen, wie schwer es ist, bereits festgeschriebene Dateien zu ignorieren Die beste Vorgehensweise für Git ist also, dass wir die Datei Git Ignore ganz am Anfang hinzufügen. Gehen Sie also zu github.com Schrägstrich GitHub, Schrägstrich Hier bekommen wir alle Vorlagen für das Getting no files. Wenn Sie beispielsweise mit einer React-Anwendung arbeiten, können Sie hier nach Knoten suchen. Und hier bekommen wir eine Vorlage für alle Anwendungen, die Node verwenden. Kopieren Sie einfach diese Vorlage und fügen Sie sie in Ihre Gating Nerve-Datei ein. So einfach ist das 18. Änderungen zwischen Bereichen anzeigen: Lassen Sie mich Ihnen jetzt eine Frage stellen. Wie können wir die Änderungen sehen , die wir damit vornehmen? Sie könnten sagen, wir können den Befehl Git Status verwenden, und Sie haben Recht. Dieser Befehl gibt jedoch nur den Dateinamen zurück. Was ist, wenn wir sehen wollen, was wir in unserer Datei ändern? Lass es mich dir zeigen. In unserer Datei mit Kapitel eins entferne ich diese drei Zeilen und füge sie hier hinzu Das ist der Anfang unserer Geschichte. Speichern Sie diese Datei und wir kommen zur Änderung hierher. Lassen Sie mich Ihnen nun zeigen, wie Sie einen anderen It-Befehl verwenden können, der für die Unterscheidung entscheidend ist. Siehst du, es sieht sehr komplex aus, die Börsen im Terminal zu sehen. Und wenn Sie das zum ersten Mal sehen, können Sie Ihren Bildschirm kaputt machen. Aber lass mich versuchen, es dir zu erklären. Hier können wir sehen, dass es zwischen einer Datei mit Kapitel Eins von A und Datei von Kapitel Eins von B unterscheidet , was bedeutet, dass dieselbe Datei mit einer anderen Version verglichen wird . Danach haben wir einen Index und einige Metadaten, was für uns wirklich egal ist. Danach erhalten wir diese beiden Zeilen, Änderungen in der ersten Datei werden mit einem Minus und Änderungen in der zweiten Datei mit einem Plus angezeigt. Mach dir darüber keine Sorgen. Im Grunde zeigt es, dass wir diese drei roten Linien entfernen und diese eine grüne Linie hinzufügen. So einfach ist das. Wie ich Ihnen bereits sagte, ist es nicht sehr einfach, die Änderungen im Terminal zu beobachten. Lassen Sie mich Ihnen erklären, wie wir unseren Code-Editor verwenden können , um diese Änderungen zu beobachten? Zuallererst müssen wir Kat sagen, dass wir VS-Code als TIF-Tool verwenden wollen. DIF-Tools bedeutet Differenzierungswerkzeug. Wir schreiben Kit, Config Dash Global. Wir setzen es auf global, sodass wir es nicht für jedes Projekt konfigurieren müssen. Fügen Sie danach das Div-Punkt-Tool und wir setzen es auf den VS-Code. Mit diesem Befehl geben wir nur Namen unseres DIV-Tools an, nämlich VSCode Keine Sorge, diese Konfiguration ist nur ein einmaliger Vorgang. Jetzt müssen wir Git sagen, wie man VS-Code startet. Wir schreiben wieder das Git Config Global DIV-Tool. Scode-Punkt CMD. Doppelte Codes. Jetzt füge ich auf meinem Computer Code als VS-Codepfad hinzu, sodass ich ihn von jedem Verzeichnis aus ausführen kann. Wenn Sie es nicht zu Ihrem Pfad hinzufügen, sich keine Sorgen, ich werde es Ihnen in nur einer Minute zeigen. Hier fügen wir Gewicht hinzu, wodurch unser Terminal angewiesen wird, zu warten. Danach verwenden wir D, was für „Datei unterscheiden“ oder „Datei vergleichen“ steht, und dann haben wir zwei weitere Argumente, nämlich das lokale Dollar-Argument, wobei alle Großbuchstaben Leerzeichen entfernt sind. Das sind die Platzhalter für die alte Kopie und die neue Kopie unserer Datei wir nun sicher, dass wir diesen Befehl in unsere Konfiguration aufgenommen haben oder nicht So können wir alle unsere Konfigurationseinstellungen mit Git config, Global E sehen und die Eingabetaste drücken. Hier können wir unsere gesamte Konfiguration sehen. Sehen Sie hier, dass unser Dollar Local und Dollar Remote nicht hinzugefügt wurden. Sie können sie hinzufügen. Speichern Sie diese Datei und fügen Sie diese Git-Konfigurationsdatei Jetzt zurück zu Git Bash. Wenn wir Änderungen im VS-Code sehen wollen, schreiben wir, anstatt Git Dev zu schreiben, das Git DV-Tool Dadurch wird verglichen, was wir im Arbeitsverzeichnis haben und was wir im Staging-Bereich haben Und es fragt nach dem Start von VSCode. Schreiben Sie ja und geben Sie ein. Siehst du, hier bekommen wir unsere Chapter-Eins-Datei. Wenn Sie nun die Änderungen in einer einzelnen Datei nicht verstehen, können wir sie in zwei Dateien aufteilen. In der rechten Ecke haben wir hier drei Punkte, wir müssen die Inline-Ansicht auswählen Wenn Sie immer noch keine Dateien nebeneinander erhalten, müssen Sie Strg+B oder Befehl+B drücken , um dieses Explorer-Bedienfeld zu schließen Hier können wir deutlich sehen, was wir geändert haben . Wir haben diese drei Zeilen entfernt und diese grüne Linie hinzugefügt. Dies ist unser alter Stage-Code und wir haben Änderungen an diesem lokalen Code vorgenommen. Wenn Sie jetzt in Zukunft die Änderungen sehen möchten, müssen Sie einfach das Git Div-Tool schreiben. Jetzt fragst du dich vielleicht, wie wir die Änderungen zwischen Staging-Vorwahl und Commit-Code erkennen können Änderungen zwischen Staging-Vorwahl und Commit-Code Wir schließen diese Vergleichsansicht und in unserem Git-Dash müssen wir einfach das Git Div-Tool, die Dash Stage, schreiben und die Eingabetaste drücken Hier bekommen wir nichts. Kannst du mir sagen warum? Weil unsere Staging-Vorwahl unserer Commit-Vorwahl identisch ist Wir müssen unsere neuen Änderungen veröffentlichen. Wir schreiben Git add dot. Jetzt führen wir wieder das Git D-Tool aus. Dash Dash-Bühne. Per Code starten, ja schreiben und sehen, hier bekommen wir Änderungen zwischen Stage-Vorwahl und Commit-Code. Um diese Lektion zusammenzufassen Wenn wir die Änderungen zwischen unserem lokalen Code und dem Staging-Code sehen wollen , dann verwenden wir das Diff-Tool, und wenn wir die Änderungen zwischen Stagecde - und Commit-Code sehen wollen , dann verwenden wir das Di-Tool, dann verwenden wir das Di-Tool, Sie schauen sich diesen Kurs ständig an und sollten dann, wie ich vorschlage, zehn bis 15 Minuten Pause Hören Sie Musik oder verbringen Sie etwas Zeit mit Ihrer Familie. Kümmere dich um deine Augen und wir sehen uns in der nächsten Lektion. 19. Shortcut für Status: Wenn wir derzeit den aktuellen Status sehen wollen, schreiben wir git status. Diese Befehle geben jedoch einen sehr langen Status zurück. Jetzt gibt es eine weitere Abkürzung, um den Status abzurufen. Dazu erstellen wir eine neue Datei, Kapitel zwei, Punkt TxD, und geben etwas Text hinein Außerdem ändern wir etwas in der Datei von Kapitel eins. Jetzt zurück zu unserem Git-Dash und anstatt Git Status zu schreiben, schreiben wir kurz Git Status A und drücken Enter. Siehst du, hier bekommen wir wenig Status. Das ist viel einfacher zu erkennen. Jetzt haben wir hier zwei Spalten, linke Spalte und rechte Spalte. Diese linke Spalte steht für den Staging-Bereich und die zweite Spalte für unser Arbeitsverzeichnis oder unseren lokalen Bereich Derzeit haben wir unsere Chapter-1-Datei im Staging-Bereich und auch im Arbeitsbereich geändert im Staging-Bereich und auch im Arbeitsbereich Deshalb bekommen wir hier sowohl M als auch M für modifiziert. Lass es mich dir auf einfache Weise erklären. Unsere Kapitel-Eins-Datei im Staging-Bereich unterscheidet sich von der Datei, die wir in Kapitel eins in unserem Commit haben Datei, die wir in Kapitel eins in unserem Commit Deshalb kommen wir zuerst hierher. Und unsere aktuelle Arbeitsbereichsdatei wurde ebenfalls gegenüber dem, was wir in unserem Staging-Bereich haben, geändert Deshalb haben wir auch hier. Lassen Sie mich das praktisch zeigen. Hier schreiben wir Git Add Chapter One Punkt TXT Wenn wir hier nochmal schreiben, hat Git Status, seht ihr, hier kommen wir nicht aus der rechten Spalte, was bedeutet, dass unser Arbeitscode derselbe ist wie Staging-Code Und wenn wir die erste Datei übergeben, dann wird sie auch von hier entfernt. Jetzt fragst du dich vielleicht, warum wir hier ein doppeltes Fragezeichen bekommen? Weil wir eine neue Datei erstellen. Deshalb bekommen wir hier beide Fragezeichen. Fügen wir die Datei mit Kapitel zwei im Staging-Bereich hinzu. Git füge Kapitel zwei TXT hinzu. Dann bekommen wir wieder den Status. C, hier bekommen wir A, was hinzugefügt bedeutet. So können wir schnell den Status sehen. Wenn du den gesamten Status sehen möchtest, kannst du den Git-Status verwenden. Wenn dir dieser Ansatz gefällt, kannst du diese Abkürzung verwenden. Die Wahl liegt bei Ihnen, es liegt ganz bei Ihnen. 20. Commit-Historie anzeigen: Derzeit haben wir den Code viele Male festgeschrieben. Was ist, wenn wir all diese Commits sehen wollen? Dafür schreiben wir es hier, protokollieren es und drücken die Eingabetaste Also hier bekommen wir alle Camtes in der Reihenfolge des Salats bis früher Ganz am Anfang erhalten wir unseren letzten Amit. Jeder Commit hat seine eindeutige ID , die automatisch von ihm Jeder Commit hat seine eindeutige ID generiert wird Wenn wir auf diesen Mite zugreifen wollen oder sehen wollen , was sich in diesem Amit befindet , dann können wir mithilfe dieser eindeutigen ID auf diesen spezifischen Commit zugreifen Als Nächstes bringen wir Headpoint zum Master. Sie fragen sich vielleicht, was Headpoint zu Master ist. Mach dir darüber keine Sorgen . Ich werde Ihnen das in den nächsten Abschnitten erklären. Vorerst sollten Sie wissen, dass dieser Git-Master ein Standard-Branch-Name ist. Branch ist ein Bereich, den wir für unseren eigenen Gebrauch erstellt haben und dieser Leiter teilt uns mit, dass wir gerade an diesem Master-Branch arbeiten. Keine Sorge, ich werde dir das in den nächsten Abschnitten sehr ausführlich erklären . Danach erhalten wir Namen des Autors und hier erhalten wir die E-Mail-Adresse des Autors. Sobald wir Datum und Uhrzeit erhalten , an dem dieser Commit erfolgt. Hier unten erhalten wir hier unsere Commit-Nachricht. Durch die Verwendung dieser Commit-Nachricht wissen wir, was in diesem Commit enthalten ist. Deshalb sage ich Ihnen, dass Sie aussagekräftige Commit-Nachricht schreiben sollen, die Sie und Ihr Kollege verstehen können. Derzeit erhalten wir nur drei oder vier Commit-Details , da diese Commits in Seiten aufgeteilt sind Wenn wir andere Seiten sehen wollen, drücken Sie die Leertaste. Siehst du, hier bekommen wir unsere anderen Commits. Um den Vorgang zu beenden, müssen wir nur noch Q drücken. Jetzt hat dieser Log-Befehl sehr interessante Optionen Hier können wir Git Log schreiben, Strich eine Zeile. Dadurch wird die Commit-Liste in einer Zeile zurückgegeben. Hier erhalten wir also ihre eindeutige ID, und nur hier erhalten wir eine kurze Beschreibung oder eine Commit-Nachricht. Wir haben noch eine weitere Option , nämlich Git log dash dash one line, dass reverse. Und sieh mal, hier bekommen wir unsere Commit-Liste in umgekehrter Reihenfolge, nämlich vom ersten Commit bis zum letzten Commit. Jetzt ist der Log-Befehl ein mächtiger Befehl zum Durchsuchen des Verlaufs. Wir werden es im kommenden Abschnitt häufig verwenden. Tatsächlich haben wir einen kompletten Abschnitt zum Durchsuchen unseres Code-Verlaufs. Lassen Sie uns vorerst bei den Grundlagen bleiben. 21. Unstagging der Dateien: Wenn ich jetzt unseren Status überprüfe, werden wir hier für die Datei mit Kapitel eins geändert, und wir fügen auch eine neue Datei hinzu, Kapitel zwei Nun, wie ich Ihnen bereits gesagt habe, sollten wir niemals zwei verschiedene Aufgaben in einem einzigen Commit übertragen. Also sollten wir zuerst unsere Kapitel-2-Datei und dann unsere modifizierte Chapter-Eins-Datei festschreiben. Dafür entpacken wir hier zuerst die Chapter-Eins-Datei. Also schreiben wir, holen, restaurieren das Stage und hier schreiben wir unseren Dateinamen, Kapitel eins Punkt THD Hier können wir auch mehrere Dateinamen schreiben, oder wir können ein Muster schreiben, oder wir können sogar einen Zeitraum schreiben, wodurch alle Änderungen an unserem Code rückgängig gemacht werden Im Moment wollen wir hier nur THD-Datei mit dem Punkt 1 aus der Staging-Umgebung entfernen Wenn wir den Status hier noch einmal überprüfen, wird er rot angezeigt, was bedeutet, dass er im lokalen Bereich oder im Arbeitsbereich geändert wurde Nun ist es wichtig, dass Sie verstehen, wie dieser Wiederherstellungsbefehl wirklich funktioniert. Der Wiederherstellungsbefehl verwendet im Grunde die Kopie aus der nächsten Umgebung. Lass dich nicht verwirren. Lass es mich dir auf einfache Weise erklären. Wenn wir also Git Restore Stage, Chapter One Dot ThD schreiben , sagst du im Grunde, dass wir die THD-Datei für Kapitel eins entfernen wollen die THD-Datei für Kapitel eins entfernen Git erstellt eine Kopie der nächsten Umgebung. Was ist die nächste Umgebung nach der Stage-Umgebung? Merken Sie sich diese Zahl. Commit ist die nächste Umgebung nach der Stage-Umgebung. Es nimmt also einfach eine Kopie unserer Kapitel-Eins-Datei aus dem letzten Befehl und fügt diese einfach im Staging-Bereich Aber in unserem Arbeitsbereich hat sich das geändert. Indirekt entpacken wir unsere Chapter-One-Datei. Wenn ich Ihnen nun eine Frage stelle, was ist, wenn wir diesen Befehl ausführen Get restore stage Chapter two dot TXT Wie ich Ihnen bereits gesagt habe, nimmt dieser Befehl die Kopie aus der nächsten Umgebung , der Commit-Umgebung. Aber unsere Chapter-2-Datei ist im letzten Commit nicht verfügbar , weil wir gerade unsere Chapter-2-Datei erstellt haben und deshalb diese Datei nie festschreiben. Dieser Befehl entfernt also unsere Kapitel-2-Datei aus dem Staging-Bereich Lassen Sie uns diesen I-Status überprüfen. Siehst du, hier bekommen wir zwei Fragezeichen, was bedeutet, dass es sich bei unserer Datei um einen Track handelt. Um es kurz zusammenzufassen Wenn du versehentlich Änderungen zum Staging-Bereich hinzugefügt hast, die du nicht in den nächsten Commit aufnehmen möchtest, dann hilft dir git restore d stage dabei, diese Änderungen zurück in dein Arbeitsverzeichnis zu verschieben zurück in dein Arbeitsverzeichnis zu Dadurch hast du die Möglichkeit, sie erneut zu bewerten oder weitere Änderungen vorzunehmen, bevor du sie festschreibst bewerten oder weitere Änderungen vorzunehmen, bevor du sie festschreibst So entpacken wir unsere Dateien. 22. Änderungen in lokalen Dateien verwerfen: Jetzt nehmen wir manchmal einige Änderungen in unserem Arbeitsverzeichnis vor, und wir wollen diese Änderungen einfach wegwerfen. In einfachen Worten, wir wollen unsere lokalen Dateien mit den Staging-Bereichsdateien wiederherstellen unsere lokalen Dateien mit den Staging-Bereichsdateien Hier haben wir also unsere Datei aus Kapitel eins geändert. Angenommen, wir möchten diese Änderungen rückgängig machen, damit wir diese lokale Chapter-Eins-Datei mit unserer Staging-Area-Chapter-Eins-Datei wiederherstellen können diese lokale Chapter-Eins-Datei mit unserer Staging-Area-Chapter-Eins-Datei wiederherstellen mit unserer Staging-Area-Chapter-Eins-Datei Dafür verwenden wir denselben Befehl, nämlich Git Restore. Und hier schreiben wir unseren Dateinamen, der Kapitel eins Punkt THD ist. Bisher schreiben wir Befehl, get restore as staged, get restore as staged, Chapter One Punkt TXT , der eine Kopie aus der nächsten Umgebung, also Commit , nimmt der nächsten Umgebung, also Commit , nimmt Denn in diesem Befehl erwähnen wir Stage als unsere aktuelle Umgebung und verwenden diesen Bindestrich als Staged Wenn wir nun staged aus diesem Befehl entfernen, können Sie sich vorstellen, wie die aktuelle Umgebung Derzeit befinden wir uns in der Arbeitsumgebung. Dieser Befehl übernimmt eine Kopie aus der nächsten Umgebung, und was ist die nächste Umgebung? Es werden Kopien aus der Staging-Umgebung übernommen. Wir können diesen Befehl auch so schreiben. Holen Sie sich mehrere Dateien, stellen Sie sie wieder her. Wir können auch alle Dateien mit einem Punkt wiederherstellen. Unsere Datei wird aus dem Staging-Bereich wiederhergestellt. Wir können es anhand des Git-Status überprüfen. Siehst du, hier bekommen wir nur die Datei aus Kapitel zwei. Aber warum stellt Git diese Datei nicht wieder her? Einfach, weil Git seine vorherige Kopie nicht im Staging-Bereich Git lässt es so wie es ist. Jetzt fragst du dich vielleicht, wie wir alle nicht verfolgten Dateien entfernen können? Dafür müssen wir den Befehl gate clean eingeben. Siehst du, hier bekommen wir einen Fehler. Es sagt uns, dass wir Kraft benötigen, sodass wir Gate Cleang für schnelle Hilfe schreiben können Hier können wir nach Force Remove suchen, wir müssen F benutzen und wir können das gesamte Verzeichnis bereinigen Wir haben auch benutzt. Wir schreiben Gate Clean F, D. Stellen Sie mit diesem Befehl sicher alle Dateien, die sich nicht im Staging befinden, aus unserem Arbeitsbereich entfernt wurden, und wir können diese Dateien nicht wiederherstellen Vergewissern Sie sich also, welche Stapel Sie reinigen. Lassen Sie uns nun den Status überprüfen. Siehst du, hier bekommen wir nichts, was bedeutet, dass alle Dateien wiederhergestellt werden. 23. Wiederherstellung zu einer früheren Version: Jetzt wissen wir also, dass es, sobald es anfängt, eine Datei zu verfolgen jede Version dieser Datei im Verlauf speichert. Wenn wir also aus Versehen mit unserer Datei Mist gebaut haben und sie auch übertragen haben, können wir unsere Datei aus der Git-Historie wiederherstellen Um das zu demonstrieren, entfernen wir zuerst unsere Chapter-Eins-Datei und dann werden wir diese Datei aus dem Git-Repository wiederherstellen Erinnern Sie sich also, welchen Befehl wir verwenden, um Dateien aus dem Arbeitsverzeichnis und auch aus dem Staging-Bereich zu entfernen? Dateien aus dem Arbeitsverzeichnis und auch aus dem Staging-Bereich Richtig, wir verwenden Git RM, Kapitel eins Punkt TXT Lassen Sie uns unseren Status überprüfen. Sehen Sie hier im Staging-Bereich, wir haben die Datei mit Kapitel eins gelöscht Lassen Sie uns nun diese Änderungen übernehmen. Also lösche Gitt die Datei aus Kapitel eins zum Wiederherstellen. Lassen Sie uns das auch im VS-Code überprüfen . Sehen Sie, unsere Datei in Kapitel eins ist gelöscht. Nehmen wir nun an, wir wollen diese Datei zurückholen. Lassen Sie uns diese Datei also aus dem Git-Repository oder dem Git-Verlauf wiederherstellen . Lassen Sie uns unseren Verlauf mit Gitlog in einer Zeile überprüfen. Hier wollen wir unsere Chapter-Eins-Datei aus dem vorletzten Commit wiederherstellen unsere Chapter-Eins-Datei aus dem vorletzten , was wir getan haben Dafür schreiben wir Git Restore H für schnelle Hilfe. Hier können wir sehen, dass wir nach Restore mehrere Optionen hinzufügen können. Und danach müssen wir unsere Quelle angeben. Source bedeutet im Grunde Commit, und danach müssen wir unseren Dateipfad angeben. Lassen Sie mich jetzt noch einmal den Verlauf überprüfen, Git log eine Zeile. Jetzt können wir Git schreiben, wiederhergestellte Quelle entspricht dem hier, wo wir unsere Commit-ID schreiben , von der wir wiederherstellen wollen Wir schreiben hier diese Commit-ID. Wenn wir eine Datei aus einem anderen Commit-Verlauf wiederherstellen wollen, müssen wir diese Commit-ID schreiben und danach schreiben wir unseren Dateinamen, Kapitel eins Punkt TXT. Lassen Sie uns nun den Status überprüfen. Siehst du, hier bekommen wir eine Datei, die nicht verfolgt wurde, und wenn wir sie im VS-Code überprüfen, sehen Sie, hier bekommen wir wieder unsere Chapter-Eins-Datei So stellen wir die Datei aus dem Commit-Verlauf wieder her. 24. Grundlegende Git-Operationen in VS-Code: Bis jetzt führen wir in diesem Abschnitt jede Aufgabe mit einer Befehlszeile aus, und ich hoffe, dass dies Ihre Zweifel an den grundlegenden Git-Operationen ausräumt. In unserem VS-Code können wir jetzt auch einige grundlegende Operationen für Git ausführen. Also hier gehen wir zum Source Control Panel und hier bekommen wir diese Art von Schnittstelle. In dieser Änderungsliste erhalten wir die Liste der Änderungen. Hier erhalten wir dieselben Ergebnisse wie dem Befehl git status. Hier haben wir eine Änderung, die in dieser Datei von Kapitel eins enthalten ist. Wenn wir auf diese Datei klicken, können wir hier unseren aktuellen Code mit dem vorherigen Code vergleichen . Außerdem können wir hier sehen, dass es sich bei dieser Datei um eine neue, nicht verfolgte Datei handelt. Nun, um diese Datei bereitzustellen, können wir das ganz einfach tun Wir müssen nur auf diese Plus-Schaltfläche klicken. Siehst du, hier bekommen wir Etappenwechsel. Wir können diese Datei auch sehr einfach aus der Staging-Umgebung entfernen. Klicken Sie einfach auf diesen Minus-Button. Jetzt haben wir lokale Änderungen in unserem Arbeitsverzeichnis. Lassen Sie uns diese Änderungen inszenieren. Jetzt fragen Sie sich vielleicht, können wir uns aus dem VS-Code heraus verpflichten? Und die Antwort lautet ja. Also hier schreiben wir unsere Commit-Nachricht. Fügen wir noch einmal die Datei Kapitel eins aus dem VS-Code hinzu. Klicken wir nun auf diesen Commit und wir übergeben diesen Code erfolgreich. Lass mich dir jetzt etwas wirklich Cooles zeigen. Lass uns zum Explorer-Panel gehen und von hier unten sehen wir die Timeline. Lass mich ein bisschen hineinzoomen. Hier erhalten wir den Verlauf unserer aktuell geöffneten Datei. Hier erhalten wir alle Änderungen, die wir an unserem Code vorgenommen haben. Wenn wir die Geschichte des Kits sehen wollen, dann verwenden wir hier diese Filteroption. Einfach das Häkchen aus dem lokalen Verlauf entfernen und schon erhalten wir den Verlauf dieser aktuell geöffneten Datei, das ist Kapitel eins. Wir können es uns ansehen, indem wir darauf klicken. So können wir unseren VS-Code für einfache Operationen verwenden. Jetzt fragen Sie sich vielleicht, warum ich Ihnen nicht diese Art der Grundoperationen zeige ? Warum unterrichte ich Befehlszeile? Stell dir vor, ich zeige dir diese Lektion direkt , ohne alle vorherigen Befehle zu erklären, dann wirst du bestimmt sehr verwirrt sein und du wirst die Grundlagen von Git nie verstehen. Deshalb bringe ich dir zuerst die Kommandozeile bei. Jetzt wissen Sie definitiv, was Sie in Ihrem Quellcode-Panel tun. 25. Einführung in Github Desktop: Lassen Sie mich Ihnen nun die grafische Benutzeroberfläche für die Verwendung von Git, Github Dktop , zeigen Benutzeroberfläche für die Verwendung von Git, Github Dktop , Dies ist eines der besten und anfängerfreundlichen GI-Tools für die Verwendung von Git Ein weiteres beliebtes Tool ist Git Kraken, aber es ist für Anfänger wenig komplex In diesem Kurs lernen wir also den Github-Desktop kennen , der anfängerfreundlich ist und ich werde Ihnen auch Git Kraken zeigen, was meine Empfehlung ist Gehen Sie also zu desktop.github.com und laden Sie die Github Dktop-Anwendung herunter und installieren So sieht es aus, wenn wir diese Anwendung zum ersten Mal öffnen Sie werden aufgefordert, sich mit einem Github-Konto anzumelden Wenn Sie kein Github-Konto haben, können Sie kostenlos ein neues Konto erstellen Ich habe bereits ein Github-Konto, also melde ich mich schnell damit an Hier wird nach meinem Namen und meiner E-Mail gefragt. Stellen Sie sicher, dass Sie diese Details noch einmal überprüfen. Hier kann ich auch meine E-Mail-Adresse ändern und bestätigen. Jetzt können wir hier ein neues Git-Repository erstellen und auch das Git-Repository öffnen und wir können auch ein vorhandenes Repository klonen. Machen Sie sich vorerst keine Gedanken über das Klonen. Das werden wir im nächsten Abschnitt sehen. Also hier öffnen wir das Git-Repository. Wir gehen in den Projektordner und wählen unser Task-Track-Projekt aus. Siehst du, hier bekommen wir diese Art von Schnittstelle. Wenn wir etwas in unserer Datei ändern, fügen wir etwas Text hinzu. Ich schreibe dieses erste Kapitel zur Einführung. Und speichern Sie die Änderungen. Wenn wir nun etwas an unserer Datei in unserer Github-Desktop-Anwendung ändern , erhalten wir diese Änderungen hier. Über dieses Einstellungssymbol können wir den Split-Typ auswählen. Nun, hier ist eine Sache zu dieser Anwendung. Diese Anwendung überträgt unseren Code direkt. Wenn wir diese Datei nicht übertragen möchten, können wir diese Datei aus dieser Liste entfernen Diese Liste ist ein Bereitstellungsbereich. Okay. Schauen wir uns nun an, wie wir unseren Code auf Git übertragen können. Also hier schreiben wir unsere Sortierbeschreibung. Sie können sehen, dass standardmäßig eine Commit-Nachricht angezeigt wird, in der wir das erste Update schreiben können , um den Github-Desktop zu probieren Und wenn wir eine falsche Beschreibung schreiben wollen, können wir sie auch hier schreiben Und danach für Amit klicken wir einfach auf diesen Kammit zu unserer Filiale, die Master ist. Und es ist geschafft. Wir haben unseren Code erfolgreich übergeben. Jetzt können wir auf dieser Registerkarte auch die Geschichte unserer Amide sehen dieser Registerkarte auch die Geschichte unserer Amide Hier erhalten wir die Liste all unserer Amide. jedes Amid auswählen, können wir seinen Dateiinhalt sehen Sie können also sehen, dass die iTU-Desktop-Anwendung Git so einfach macht Wenn Sie gerne die Befehlszeile oder den VS-Code verwenden oder den iTub-Desktop mögen, ist alles Aber wie Sie mit der Befehlszeile sehen, können wir auf Git mehr kontrollieren Mit Kit-Befehlen können wir eine Vielzahl von Aufgaben erledigen. Ehrlich gesagt verwende ich gerne Kit-Befehle und VS-Code, aber Sie haben die Wahl. Sie können ein Tool wählen , in dem Sie sich sicher fühlen. Es liegt ganz bei dir. 26. Einführung in GitKraken: In der vorherigen Lektion sehen wir also unser erstes GI-Tool, GitHub Desktop Wir haben ein anderes Tool, nämlich Kit Kraken, das etwas komplex ist Sobald Sie es jedoch verstanden haben und damit vertraut sind, werden Sie dieses Tool häufiger verwenden Außerdem bietet Kit Kraken mehr Funktionen als die GitHub-Desktop-Anwendung Ich persönlich benutze Kit Kraken gerne. Sie werden den Grund in den nächsten Abschnitten sehen. Lassen Sie uns auch TKRACon in unserem System installieren. Gehen Sie zu kitcracon.com, und hier bekommen wir Klicken Sie einfach darauf und der Download wird gestartet. Nach Abschluss des Downloads öffnen wir ein Setup und können Git Kraken einfach installieren Wenn wir Git Kraken jetzt zum ersten Mal öffnen, bekommen wir hier eine Repository-Option zu öffnen und können uns mit Github anmelden Lassen Sie uns vorerst ein Repository öffnen. Siehst du, es hat automatisch die Details meines Git-Kontos abgerufen, weil ich mich gerade in der vorherigen Github-Desktop-Lektion angemeldet Also kann ich das filmen. Hier bekommen wir diese Art von Schnittstelle. Wir können das Repository öffnen oder wir können das Repository aus dem Internet klonen, oder wir können ein neues Repository erstellen. Derzeit möchten wir das Repository lokal öffnen, also gehen wir zum geöffneten Repository und öffnen unser aktuelles Projekt. Sehen Sie, so sieht unser Repository aus. Das ist für Anfänger etwas komplex , weil es so überladen ist Mir geht es genauso, wenn ich Git Kraken zum ersten Mal benutze. Aber glaub mir, wenn wir uns mit Git vertraut machen, wird das alles sehr einfach Hier sind alle Kometen und wir können mehr Details über diesen Camt sehen , indem wir sie auswählen . Auf der rechten Seite erhalten wir die Sehen Sie hier, wir bekommen eine Commit-ID und eine Commit-Nachricht. Danach erhalten wir Informationen über den Autor, der dieses Datum und die Uhrzeit festgeschrieben hat, und darunter eine Liste von Dateien, die wir löschen, hinzufügen oder geändert haben. Im Grunde genommen erhalten wir Änderungen , die wir in diesem Commit vorgenommen haben. Hier können wir diese Dateien kürzen und wir können die Dateien auch in einer Baumstruktur sehen. Wenn wir auf diese Datei klicken, sehen Sie, hier bekommen wir die Datei und wir können diese Datei mit diesem Symbol im geteilten Modus sehen . Im Moment dreht sich alles darum, Kraken. Mach dir keine Sorgen Wir werden Git Kraken in den kommenden Abschnitten ausführlicher sehen in den kommenden Abschnitten ausführlicher Wir sehen uns im nächsten Abschnitt. 27. Abschnitt 03 Code-Historie: Willkommen im dritten Abschnitt des ultimativen IT-Kurses. In diesem Abschnitt werden wir sehen, wie wir unsere Cami-Geschichte genauer durchsuchen können wir unsere Cami-Geschichte genauer durchsuchen Zunächst werden wir sehen, wie wir alle Commits sehen und die Commits nach Autorennamen, Daten und Commit-Nachricht filtern können die Commits nach Autorennamen, Daten und Commit-Nachricht filtern Autorennamen, Daten Außerdem werden wir sehen, wie wir Tastenkombinationen für lange Befehle festlegen können Tastenkombinationen für lange Befehle festlegen Als Nächstes werden wir uns bestimmte Amide ansehen, zwei Amide vergleichen, zum jeweiligen Commit zurückkehren, Bug-Commit und Schuldzuweisungen erkennen, dem Gummit ein Tag geben und vieles mehr Ich weiß, dass du begeistert bist, also lass uns diesen Abschnitt beginnen 28. Lokales Projekt klonen: Zum Durchsuchen des Verlaufs benötigen wir nun ein Projekt, in dem wir nur wenige Commits haben Unter diesem Video findest du also den Ressourcenordner, und in diesem Ordner habe ich ein Task-Track-Projekt hinzugefügt, habe ich ein Task-Track-Projekt hinzugefügt das ich in SDML und CSS erstellt habe Lassen Sie mich Ihnen zeigen, wie Sie jedes vorhandene Git-Projekt auf Ihrem Computer klonen jedes vorhandene Git-Projekt auf Ihrem Computer Also pun den Ressourcenordner, und hier haben wir den Kurs Task Track Zip Wir können das entpacken, wir können diesen Ordner einfach von hier kopieren und in den Ordner unseres Projekts einfügen Jetzt können wir anfangen, dieses Projekt zu verwenden. So einfach ist das. 29. Protokollbefehl im Detail erkunden: Lassen Sie uns zunächst unser Projekt in Git Bash öffnen. Im vorherigen Abschnitt, den wir gesehen haben um die Geschichte unseres Git-Projekts zu verfolgen, verwenden wir den Befehl Git clock Dieser Befehl gibt uns alle Commit-Details zu jedem Commit, so wie Commit Autorendetails, Datum und Uhrzeit sowie eine Commit-Nachricht enthält . Außerdem ordnen wir diese Commits der Reihe nach an, was bedeutet, dass wir zuerst den letzten Commit und am Ende unseren ersten Commit erhalten Wir haben mehr als eine Seite, dann können wir die Leertaste drücken oder uns Pfeiltasten nach oben und unten bewegen diesen Befehl zu beenden, drücken wir Q. Wissen Sie noch, mit welchem Befehl wir dieses Log in weniger Details bekommen Richtig, wir können hier Git Log Dash eine Zeile schreiben. Sehen Sie hier, wir bekommen nur wenig Has und Commit-Nachrichten. Wir haben diese beiden Befehle bereits gesehen. Sehen wir uns diesen Protokollbefehl nun genauer an. Was ist, wenn wir sehen möchten, dass sich die Dateien in jedem Befehl ändern? beispielsweise im zweiten Befehl Welche Dateien werden beispielsweise im zweiten Befehl geändert oder was ändern wir im letzten Befehl? Dafür müssen wir einfach datat am Ende unseres Log-Befehls schreiben Das bedeutet Statistik. Siehst du, hier wird eine Datei geändert und hier wird der Name geändert. Danach können wir 16 Einfügungen sehen. In ähnlicher Weise haben wir diese Details für jeden Kometen. Wenn Sie nun durch viele Details verwirrt sind, können Sie dies auch tun Fügen Sie hier eine Zeile hinzu und sehen Sie, hier erhalten wir etwas weniger Details über Comet Hier erfahren wir nur, welche Datei sich ändert und wie viele Zeilen wir ändern Aber was ist, wenn wir sehen müssen , welche Zeile wir hinzufügen, entfernen oder aktualisieren? Keine Sorge, es ist wirklich einfach. Wir schreiben Gate, Log, One Line, Despatch. Sehen Sie hier, wir bekommen die grünen Zeilen, die wir in die Datei aufgenommen haben Und wenn wir etwas aus dieser Datei entfernen, bekommen wir diese Zeilen rot angezeigt. Mit diesen Befehlen können wir sehr schnell sehen, was in unserem Projekt passiert ist. Um das zu beenden, müssen wir mehrmals die Leertaste drücken, und wenn wir ankommen, drücken wir Q. 30. Filtern der Historie: Lassen Sie uns nun sehen, wie wir unseren Commit-Verlauf filtern und nur die spezifischen Details abrufen können unseren Commit-Verlauf filtern und nur die spezifischen Details abrufen , die wir sehen möchten. Es ist dasselbe, wie wir Produkte bei Amazon filtern. Und es macht auch super viel Spaß, das zu tun. Lass es mich dir zeigen. Zuerst schauen wir uns an, wie wir unsere Freunde anhand des Autorennamens filtern können unsere Freunde anhand des Autorennamens filtern Also schreiben wir hier Gate, Log, eine Zeile, Autor entspricht dem hier schreiben wir unseren Autorennamen Wenn der Name des Autors ein Leerzeichen enthält, müssen Sie diesen Namen in die Doppelcodes Andernfalls wird es verwirrt. Hier ist dieser Autorenname genauso sensibel, Sie müssen den exakt gleichen Namen schreiben. Und wenn du Sensitive ignorieren willst, dann schreib am Ende einfach I und erhalte Ignorieren sensibel. Sehen Sie hier, wir machen Gameten mit dem Namen Mt Patel. Wie können wir diese Milben besser filtern? Richtig, wir können Amide anhand von Datteln filtern. Also Git Log, Strich eine Zeile, Strich B vier entspricht hier, wir müssen unser Datum in Doppelcodes wie diesem schreiben 2024 unser Monat 01-30. Siehst du, hier bekommen wir alle Amide vor diesem Datum. Wenn wir an großen Projekten arbeiten, sehen wir uns manchmal gerne Camids an, die nach einem bestimmten Datum Also haben wir hier danach, und hier geben wir unser Datum im gleichen Format Wir können auch Zeichenketten wie gestern, vor zwei Tagen, vor einer Woche, vor einem Jahr usw. weitergeben zwei Tagen, vor einer Woche, vor einem Jahr usw. Das ist sehr nützlich. Ich nutze das oft, weshalb ich ein oder zwei Tage Urlaub nehme. Jetzt möchten wir manchmal aus unserer Commit-Nachricht filtern. Zum Beispiel also nur die Commits, bei denen das Wort Task in der Commit-Nachricht steht Wir schreiben es, protokollieren, strichen eine Zeile, Dash Grab entspricht in Doppelcodes, wir schreiben Task Dabei wird auch zwischen Groß- und Kleinschreibung unterschieden, also sicher, dass Sie das richtige Wort schreiben Siehst du, hier bekommen wir kmtes welche Commit-Nachricht dieses Taskwort hat, und weil wir die Groß- und Kleinschreibung ignorieren, was wir hinzufügen werden, schreiben, fügen wir hier I. C hinzu, hier bekommen wir kmtes, das das Task-Wort in der Commit-Nachricht hat Jetzt wollen wir manchmal einen bestimmten Commit finden , der die Funktion oder Variable hinzufügt oder entfernt Zum Beispiel arbeiten wir an einem Todos-Projekt und möchten wissen, wann wir die Funktion Todos hinzufügen oder wann wir sie entfernen Also können wir so etwas machen. Git log, Strich eine Zeile, Großbuchstaben hier in Doppelcodes, wir müssen unseren Funktionsnamen, addTDS, schreiben Derzeit haben wir in diesem Projekt diese Funktion nicht Also suche ich hier. Siehst du, hier bekommen wir die Commits Stellen Sie sich jetzt vor, wir wollen manchmal nur die letzten drei Cometen oder fünf Kometen sehen Dann können wir Git Log schreiben, eine Zeile strichen, fünf Siehst du, hier haben wir die letzten fünf Kometen. Manchmal müssen wir auch den Verlauf einer bestimmten Datei sehen den Verlauf einer bestimmten Datei Zum Beispiel möchten wir den Indexpunkt stmlFlehtory sehen, wenn diese Datei Dann können wir so etwas machen . Git Log, eine Zeile strichen. Indexpunkt HTML, und hier können wir den Verlauf sehen. Wenn Ihr Dateiname wie Ihr Dateiprotokoll bereits in der Git-Bibliothek registriert ist , können Sie hier diesen Befehl und den Dateinamen mit einem doppelten Bindestrich trennen . Siehst du, hier bekommen wir das gleiche Ergebnis. Lassen Sie mich Ihnen jetzt eine Frage stellen. Was ist, wenn wir in diesem Befehl die Änderungen in dieser Datei sehen wollen? Richtig. Wir müssen eine gestrichelte Seite schreiben, aber wir müssen eine Seite vor diesem doppelten Gedankenstrich schreiben , weil dieser doppelte Gedankenstrich den Befehl vom Dateinamen trennt und wir hier die Dateiänderungen bekommen. 31. Alias für Befehle einrichten: Jetzt müssen wir manchmal mehrere Git-Befehle ausführen , die wir sehr häufig verwenden, aber sie sind wenig lang oder schwer zu merken. Wir können Abkürzungen für diese Befehle festlegen. Zum Beispiel führen wir häufig diesen einzeiligen Befehl Git log dash aus. Lassen Sie uns eine Abkürzung setzen oder in Git-Begriffen bedeutet Setzen eines Lias.ellas einfach Wir schreiben Git Config Dash Global Alias, Punkt. Hier müssen wir unseren Kurznamen für diesen Befehl schreiben . Also schreiben wir log für log. Stellen Sie sicher, dass Sie aussagekräftige Namen verwenden , denn am Ende des Tages müssen Sie sich die Namen der Abkürzungen merken, und danach müssen wir unseren ursprünglichen Befehl schreiben , der eine Zeile log ist. Hier müssen wir unseren Befehl mit doppelten Codes umschließen, weil wir ein Leerzeichen dazwischen haben, und die Eingabetaste drücken. Lassen Sie uns nun überprüfen, ob wir es erfolgreich eingestellt haben oder nicht. Also schreiben wir es configs global E und es öffnet unsere Config-Datei in unserem Standard-Code-Editor Siehst du, am Ende bekommen wir unseren Alias log, um eine Zeile zu protokollieren Wenn Sie etwas aktualisieren oder entfernen möchten, dann können Sie das von hier aus tun. Im Moment wollen wir nichts ändern, also schließen wir diese Datei. Lassen Sie uns jetzt unseren Alias verwenden. Schreiben Sie zu log und sehen Sie hier, wie wir unsere Befehlsausgabe erhalten So können wir Abkürzungen als unsere Abkürzungen festlegen, um Zeit und Speicher zu sparen , da wir uns nicht den ganzen langen Befehl merken müssen. Für den Rest dieses Kurses verwende ich diesen Alias nicht, verwende ich diesen Alias nicht denn wenn jemand von der Mitte des Kurses aus beitritt, wird er nicht verstehen, wie ich den Alias verwende. Aber du kannst das auf jeden Fall für deine Praxis verwenden. Es liegt ganz bei dir. 32. Spezifisches Commit im Detail anzeigen: Bis jetzt haben wir gesehen, wie wir alle Commits sehen können. Aber manchmal wollen wir die spezifischen Details sehen, wie zum Beispiel bestimmte Commit Bits, die Commit hat Dafür können wir Git, Show schreiben und hier unsere Commit-Referenz schreiben. Hier erhalten wir die Details zu diesem speziellen Commit. Hier können wir sehen, dass wir nur eine Datei geändert haben und unten haben wir die Änderungen. Wenn wir nun den letzten Commit haben wollen, können wir hier schreiben, wie der Kopf mit allen Großbuchstaben aussieht. Wenn wir in der Commit-Liste weiter nach unten wollen , ohne den Commit zu schreiben, können wir hier bis und wir können hier eine Zahl schreiben, sagen wir zwei. Also finde Git zuerst den Kopf und gehe dann zwei Schritte nach unten und gib uns Details zu diesem Commit. Sie können sehen, dass es sehr einfach und unkompliziert ist. Wenn wir nun die Dateinamen sehen wollen, die in unserem spezifischen Commit geändert wurden, dann müssen wir hier Git, show, head till two, name only schreiben . Siehst du, hier haben wir nur eine Datei, die sich in diesem Commit ändert. Lassen Sie mich Ihnen jetzt eine weitere Situation geben. Was ist, wenn wir den vollständigen Inhalt der bestimmten Datei in einem bestimmten Commit sehen den vollständigen Inhalt der bestimmten Datei in einem bestimmten Commit Also bekommen wir unseren vorherigen Befehl und fügen hier einfach eine Spalte hinzu. Und hier schreiben wir unseren Dateipfad wie file dot TXT, oder wenn wir einen Ordner haben, können wir Css detyle dot css schreiben Sehen Sie hier, wir erhalten den vollständigen Inhalt der spezifischen Datei in unserem letzten dritten Befehl diese Weise können wir den spezifischen Commit detaillierter sehen . In der nächsten Lektion werden wir sehen, wie wir im Vergleich zu Befehlen abschneiden können. 33. So vergleichst du zwei Commits: Wenn wir also zwei Commits vergleichen müssen , um zu sehen, was in unserem Code hinzugefügt , entfernt oder geändert Dafür werden wir den Befehl Git di verwenden. Dieser Befehl erklärt uns den Unterschied zwischen unserem Arbeitsverzeichnis und dem letzten Commit. Derzeit haben wir keinen Unterschied. Deshalb bekommen wir nichts. Hier können wir auch zwei spezifische Commits vergleichen. Sagen wir Kopf bis zwei Leertaste. Hier an beiden Stellen können wir auch eine Commit-Referenz hinzufügen. Siehst du, es hat mehrere Dateien und mehrere Änderungen. Nun, wenn wir nur eine bestimmte Dateiänderung zwischen diesen Commits sehen wollen nur eine bestimmte Dateiänderung , was werden wir dann tun? Am Ende dieses Befehls fügen wir einfach unseren Dateinamen, den Punkt CSS im CSS-Stil, Punkt CSS im CSS-Stil In der nächsten Lektion werden wir nun sehen, wie wir unseren Code auf den spezifischen Commit zurücksetzen können . 34. Zurück zu einer bestimmten Version: Jetzt möchten wir manchmal unseren Code auf eine der spezifischen MITs zurücksetzen. Zum Beispiel dieses Auslassen. Wir wollen unseren Code genau so machen , wie wir ihn in dieser Auslassung festgelegt Also schreiben wir Git, checken aus und hier fügen wir unsere Omit-Referenz hinzu Siehst du, hier wechseln wir zu diesem Met. Aber hier bekommen wir auch diese Warnung, die uns vor dem Zustand des gelösten Kopfes warnt. Jetzt sind viele Entwickler sehr verwirrt über den Status, aber es ist nicht sehr schwer. Lass es mich dir erklären. Hier haben wir unsere Commit-Struktur. Das ist die Anzahl der Kometen. Dies ist der erste Kommentar und ganz rechts haben wir uns zuletzt getroffen haben wir uns zuletzt Hier können wir sehen, dass all diese Commits vorherigen Commit verknüpft sind Wie wir in unserer Git Bash sehen können, befinden wir uns derzeit in unserem Master-Branch Branch ist das etwas fortgeschrittene Thema in Git. Das werden wir im nächsten Abschnitt sehen. Im Moment sollten Sie nur verstehen, dass Branch wie eine Linie ist , die Entwickler für individuelle Projektarbeit erstellen. Wenn der Manager Sie zum Beispiel mit der Arbeit an einem Anmeldeformular , erstellen Sie als Entwickler einen neuen Zweig für die Bearbeitung des Anmeldeformulars. Master oder Main ist ein Standardzweig in Git. Hier ist dieser Master eine Referenz, die unseren letzten Kilometer darstellt. Jedes Mal, wenn wir einen neuen Code übergeben, wechselt dieser Master zum letzten Kat Wie wir in Git wissen, können wir jetzt mehrere Branches erstellen. In diesem Fall weiß Git also, an welchem Branch wir gerade arbeiten. Um dieses Problem zu lösen, haben wir eine weitere Referenz namens head. Head weist auf den aktuellen Zweig hin , an dem wir gerade arbeiten. Wir haben das schon einmal gesehen. wir nun neue Commits hinzufügen, werden dieser Head und Master auch mit unserer neuesten Version weitermachen Wenn wir nun zu dem spezifischen Commit auschecken, wechselt unsere Hauptreferenz zu diesem Und das ist der Status „ Abgetrennter Kopf“. Idealerweise sollten wir, wenn wir uns zu diesem Zeitpunkt im Zustand des getrennten Kopfes befinden, dort keinen neuen Code festschreiben. Wenn wir einen neuen Commit erstellen, wird dieser Met hier hinzugefügt. Wenn wir nun irgendwann unseren Kopf zum Master bewegen, kann dieser Komet von keinem anderen Kometen Git deklariert diesen Commit als toten Commit und nach einiger Zeit entfernt es diesen Commit automatisch aus seinem Datensatz Es ist also besser, den Code nicht zu übergeben , wenn wir uns im Status „ Abgetrennter Kopf“ befinden. Wir können uns immer unseren Code ansehen und mit unserem Code experimentieren. Nun, wie wir hier sehen können, hat sich unser Git-Pass geändert. Vorher waren wir hier Master. Aber wenn wir zu einem bestimmten Befehl auschecken, erhalten wir hier den Commit-Hash unseres Checkout-Commits. zum jetzigen Zeitpunkt Wenn wir zum jetzigen Zeitpunkt alle unsere Befehle mit Git log in einer Zeile protokollieren, erhalten wir hier nur Kometen, die vor diesem bestimmten Kometen festgeschrieben wurden erhalten wir hier nur Kometen, die vor diesem bestimmten Kometen festgeschrieben Andere Kometen sind zu diesem Zeitpunkt unsichtbar. Keine Sorge, diese anderen Kometen werden nicht gelöscht. Es ist einfach unsichtbar. Außerdem ist unsere Hauptreferenz hier. Um diese unsichtbaren Kometen zu sehen, müssen wir hier eine weitere Variable hinzufügen, und das ist alles Sehen Sie hier, wir haben alle unsere Kometen und wir können sehen unsere Hauptreferenz hier ist und unsere Hauptreferenz hier ist. Um unseren Kopf zurück zur Haupt- oder Hauptreferenz zu bewegen , können wir hier Gate, Checkout Master schreiben und sehen, wir gehen zum Master über und sehen, wie unser Kopf auf den Master zeigt Und jetzt haben wir alle Comads. Auf diese Weise können wir unseren vorherigen Code in unserem Code-Editor oder im Datei-Explorer sehen unseren vorherigen Code in unserem Code-Editor oder im Datei-Explorer Und deshalb ist der Checkout-Befehl wichtig. 35. Erkennung des fehlerhaften Git Bisect Commits: Stellen Sie sich nun vor, etwas passiert in unserem Code und wir bekommen nnn Berg in unserer Anwendung, wie können wir dann herausfinden, in welchem Befehl ein Eine Lösung besteht darin, dass wir alle diese Befehle einzeln mit dem Checkout-Befehl überprüfen können , aber das wird viel Zeit in Anspruch nehmen In Git haben wir einen Befehl , um den Bug-Befehl schnell zu identifizieren, nämlich indem wir Git per Set verwenden. diesen Prozess zu starten, müssen wir Gate by Set, Start schreiben und Enter drücken. Hier können wir sehen, dass sich unser Gitbsh im Halbierungsmodus befindet. Jetzt, nachdem wir den Bisect-Prozess gestartet haben, müssen wir zuerst unseren aktuellen Commit als schlecht kommt markieren Wenn du wissen willst, welcher der aktuell aktive Mite ist, dann können wir von hier aus sehen, welcher unser Master-Commit ist Hier kennzeichnen wir das als schlechtes Fell weil wir auf Käfer in diesem Fell stoßen Hat sich schlecht halbiert. Außerdem, wenn du ein anderes Met als schlechtes Kit markieren willst, dann müssen wir am Ende seine Commit-Referenz schreiben Ich weiß, das ist etwas verwirrend, aber in nur einer Minute werden Sie das verstehen. Danach müssen wir die Gangart erklären, welches das letzte gute Spiel ist, das wir kennen Bis zu diesem Zeitpunkt wissen wir zum Beispiel, dass unsere Anwendung keinen Bug hat Dann müssen wir das so gut wie möglich machen. Also schreiben wir Gate, Bisect Good, und hier geben wir unsere Komitesreferenz Loggen wir jetzt einfach unsere Kometen ein, sehen Sie, jetzt bewegt sich unser Kopf zur Hälfte unserer Nun, hier ist der logische Teil des bisec-Befehls. Stellen Sie sich vor, wir haben diese zehn Kometen. Wir markieren unseren letzten Kometen als schlechten Kometen, und unser erster Komet ist der gute Komet In dem Moment, in dem wir unseren ersten Ameten als guten Kumto-Kopf einstufen, bewegen zum Mittelpunkt zwischen Da wir nun an dieser Stelle denken, wird unser aktueller Arbeitscode durch diesen Amet-Code ersetzt Wir können unsere Bewerbung hier unter überprüfen. Wenn wir einen Fehler in diesem Mantel haben, werden wir ihn als schlecht kennzeichnen . Wenn wir keinen Fehler in dieser Katze haben, werden wir diese Katze als gut markieren. Wir stellen zum Beispiel fest, dass dieser Amet kein Problem darstellt. Also werden wir dieses Met mit Git BSc als gut markieren. Jetzt, wo wir dieses Ass als gut markieren, bewegt sich unser Kopf zum Mittelpunkt zwischen unserem schlechten Kmt und unserem guten Kat bewegt sich unser Kopf zum Mittelpunkt zwischen unserem schlechten Kmt und unserem guten Kat Jetzt überprüfen wir erneut unseren Code. Wenn er gut ist, markieren wir ihn als gut. Und wenn wir diese Kamete für schlecht halten, dann markieren wir sie als schlechten Kometen Dieser Prozess wird die Liste weiter einschränken, und dann haben wir den Kometen, der Burg verursacht Das ist die ganze Idee des Bisec-Befehls. In unserem Commit können wir also unseren Code im Vas-Code überprüfen und sehen, ob er BG enthält oder nicht Stellen Sie sich vor, wir haben festgestellt, dass dieser Commit einen Fehler enthält. Dann markieren wir hier „ Get by sec“ als schlecht. Jetzt werden wir noch einmal unsere Liste überprüfen, um zu sehen, wie sie zu diesem Commit verschoben wurde. Wir überprüfen erneut unseren Code und stellen uns vor, dass dieser Commit keinen Schaden hat. Dann werden wir es mit Git Biseccd gut machen. Siehst du, hier bekommen wir diesen Commit als den, der die Burg zu unserer Anwendung hinzugefügt hat So funktioniert der Befehl bisec also. Es mag ein bisschen verwirrend aussehen, aber wenn Sie diesen Befehl einmal verwenden, werden Sie ihn danach so leicht verstehen Jetzt können wir hier sehen, dass wir uns immer noch im Halbierungsmodus befinden. Um diesen Modus zu verlassen, müssen wir get bisect reset schreiben und sehen, dass wir wieder bei unserem Hauptbefehl sind Auf diese Weise können wir Fehler in den Metes identifizieren , ohne alle Metes in der Zeile zu überprüfen 36. Die Liste der Mitwirkenden erhalten: Nun, wenn wir manchmal wissen wollen wie viele Commits von Benutzern vorgenommen wurden , um den Beitrag zu erfahren Dafür schreiben wir ein Git-Kurzprotokoll. Siehst du, hier bekommen wir Benutzernamen und die Anzahl der Commits dieses Benutzers Außerdem erhalten wir die Zusammenfassung der Commit-Nachrichten. Hier in diesem Projekt bin ich der einzige Mitwirkende Deshalb wird nur mein Name angezeigt. Jetzt können wir diesen Befehl sogar ändern , indem wir mehr Optionen verwenden. Hier schreiben wir es kurz log, H für schnelle Hilfe. Und sehen Sie hier, wo wir alle anderen Optionen haben. Zum Beispiel können wir N oder einen Gedankenstrich mit einer Strichzahl schreiben , um die Ausgabe nach der Anzahl der von jedem Benutzer ausgeführten Commits abzukürzen die Ausgabe nach der Anzahl der von jedem Benutzer ausgeführten Commits abzukürzen Wenn wir nun eine lange Liste von Commits haben, müssen wir für C für jeden Mitwirkenden scrollen Nach diesem N können wir einen Bindestrich schreiben, um die zusammenfassende Commit-Nachricht zu ignorieren Sehen Sie hier, wir erhalten nur die Anzahl der Kommas und den Benutzernamen. In der nächsten Lektion werden wir uns den Verlauf der Datei ansehen 37. Browserverlauf der Datei: Jetzt haben wir diesen Befehl schon einmal gesehen. Ich füge es hier nur hinzu , weil es Teil des Surfens im Verlaufsbereich ist. Wie wir wissen, können wir zum Ansehen des Verlaufs ihn schreiben und protokollieren, und um den Verlauf einer bestimmten Datei anzusehen, können wir den Dateinamen schreiben , der Indexpunkt-HTML ist. Hier erhalten wir die Liste der Codes , in denen sich diese Datei geändert hat Wenn wir diese Liste eingrenzen wollen, können wir hier den variablen Strich mit einer Zeile verwenden Siehst du, jetzt ist es lesbar. Nun, was ist, wenn wir sehen wollen, dass die Änderungen in dieser Datei geschehen? Wir können hier Daten verwenden, um die Statistik zu erhalten, oder wir können die Anzahl der Änderungen in dieser Datei angeben Siehst du, im ersten Commit haben wir 150 Änderungen. In ähnlicher Weise haben wir hier 35 Änderungen , davon 32 Einfügungen und drei Löschungen. Wenn wir nun die tatsächlichen Änderungen in der Datei sehen wollen, dann schreiben wir das, was wir direkt an der Stelle dieser DS-Daten tun , den Versand. Sie können sehen, dass Git-Befehle nicht schwer sind. Es ist nur eine Frage der Übung, und ich vertraue dir. Nachdem Sie diesen Git-Befehl in einem Projekt geübt haben, können Sie ihn in jedem anderen Projekt verwenden , ohne sich Sorgen machen zu müssen. 38. Autor jeder Zeile anzeigen [Git Blame]: Manchmal möchten wir in unserer Projektdatei wissen, wer der Autor einer bestimmten Zeile ist. Es passiert in meinem Projekt, ein neuer Entwickler tritt meinem Team bei und er schreibt einen sehr schlechten Code. Wenn ich jemanden frage, der diesen Code schreibt, wird niemand antworten, und ich weiß bereits , wer diesen Code schreibt. Deshalb bitte ich diesen Entwickler immer , zu überprüfen , wer diesen Code schreibt. Am Anfang habe ich mich nicht über diesen Entwickler lustig gemacht, wir sind alle auf diesem Niveau. Daran ist nichts falsch. Niemand wird am ersten Tag des Programmierens perfekt. Ist eine Reise, die lange dauert. Zurück zu unserem Git-Beispiel Wenn wir den Autor einer bestimmten Zeile wissen wollen, können wir git blame schreiben, und hier schreiben wir unseren Dateinamen oder Pfad. Siehst du, hier bekommen wir den gesamten Inhalt der Datei Zeile für Zeile mit den Details. Hier müssen wir zuerst die Referenz angeben, in der diese Zeile zurückgegeben wird. Dann bekommen wir den Autornamen und auch das Datum und die Uhrzeit. Nun, wenn unsere Datei manchmal viele Zeilen hat und wir nur eine bestimmte Zeile wissen wollen, dann können wir L hier schreiben und dann diese Zeilennummer schreiben, das Ende der Zeilennummer. Nehmen wir an, wir wollen nur drei und vier sehen. Dann schreiben wir hier 34. Wenn wir Zeile drei, vier und fünf sehen wollen , dann schreiben wir 35. Sehen Sie hier, wir bekommen nur drei, vier und fünfte Zeile. Damit Sie den Befehl blame verwenden können , um den Autor jeder Zeile zu ermitteln. In der nächsten Lektion werden wir sehen, wie wir einem Commit ein Tag geben können. 39. Commits mit Tags markieren: Stellen Sie sich nun vor, diese Hilfe ist bereit, in der Produktion zu starten, oder wir möchten diesen Commit-Code als Version 1.0 kennzeichnen Aber ich gebe das schon in Version 1.0 an. Ich muss hier Version 1.0 0.1 angeben. Also, dem Med einen Versionsnamen zu geben , heißt das in Git Tags geben. Lassen Sie uns dieses Amet als Version 1.0 0.1 markieren. Hier schreiben wir Git-Tag, Version 1.01. Hier können wir unsere Commit-Referenz schreiben und hier fügen wir keine Commit-Referenz hinzu, dann können wir dieses Tag standardmäßig unserem aktuellen Commit geben , das ist der Master-Commit Wenn wir nun unsere Commits protokollieren, sehen Sie, hier bekommen wir die Tag-Version 1.01 nach dieser Commit-Referenz Wenn wir nun unseren Code für diesen Commit auschecken wollen, müssen wir diese Commit-Referenz nicht schreiben Wir können einfach Git verwenden und Version 1.0 auschecken. So wie wir diese Commit-ID verwenden, können wir auch dieses Tag verwenden, Version 1.0. Nehmen wir nun an, ich möchte alle Tags sehen , die ich diesem Projekt gegeben habe. Dann schreiben wir einfach Git-Tag und sehen hier, dass wir alle Tags bekommen, die wir zuweisen. Nehmen wir nun an, wir fügen dieses Tag von mystisch hinzu, und jetzt wollen wir dieses Tag entfernen Also schreiben wir einfach Git-Tag D, wir schreiben unseren Tag-Namen , der Version 1.01 ist Jetzt können wir sehen, dass das Tag aus der Liste entfernt wurde. Hier haben wir dieses Versions-1.0-Tag, das wir als Lightweight-Tag bezeichnen, was bedeutet, dass wir unserem Amid nur eine Referenz als Version 1.0 geben . Jetzt haben wir auch das Tag mit Anmerkungen versehen. Jetzt fragen Sie sich vielleicht, was annotierte Tags sind? annotierte Tag wird also verwendet, um weitere Details wie den Namen, das Datum und die Uhrzeit des Taggers und die Commit-Nachricht hinzuzufügen Datum und die Uhrzeit des Taggers und die Commit-Nachricht In einfachen Worten, mit annotierten Tags können wir einfach mehr Details zu unseren Tags hinzufügen Hier ist der Befehl für kommentierte Tags. Wir schreiben das Gate-Tag A für die annotierte Version 1.01 M, was für Message steht Und in den Doppelcodes können wir unsere Nachricht wie Release-Version 1.01 eingeben weiß, dass diese Nachricht nicht sehr nützlich ist, aber ich zeige dir nur, ob du eine Nachricht mit diesem annotierten Tag hinzufügen möchtest , dann kannst du das auf diese Weise tun Wenn wir es nun als Tag schreiben, erhalten wir zwei Tags Wenn du eine Textnachricht sehen willst, dann müssen wir den Git-Tag N schreiben. Siehst du, hier bekommen wir die Tag-Nachrichten. Wenn unser Tag ein Lightweight-Tag ist, erhalten wir diese Commit-Nachricht als Tag-Nachricht. Verwechseln Sie das also nicht. Wenn wir nun unsere Version 1.01 mit dem Befehl Version 1.01 anzeigen sehen , dann sehen wir hier oben auch die Tagger-Details wie Name, E-Mail, Datum und Uhrzeit, zu der wir dieses Tag und diese Tagnachricht wir dieses Tag und diese Tagnachricht So verwenden wir Tags, um Versionen zu markieren. 40. Commit-Historie in Github Desktop: Sehen wir uns also die Geschichte unserer CIDs in der Github Extra-Anwendung Lassen Sie uns also dieses Abschnittsprojekt in der Github Extra-Anwendung öffnen in der Github Extra-Anwendung Gehe zur Datei und füge das lokale Repository hinzu. Und hier sehen wir den Pfad unseres Ordners. Und wählen Sie einfach diesen Ordner aus. In der vorherigen Lektion haben wir gesehen, wie Änderungen in der Github-Desktop-Anwendung angezeigt werden. Jetzt werden wir sehen, wie wir mit dieser Anwendung den Commit-Verlauf durchsuchen . Hier haben wir also eine Liste der Commits auf der linken Seite und hier bekommen wir auch unseren Text und hier oben bekommen wir die Commit-Nachricht, bekommen wir die Commit-Nachricht, Namen des Autors und die Commit-Referenz. Jetzt bekommen wir hier die Liste der geänderten Dateien. Wenn wir auf sie klicken, bekommen wir die Änderungen hier. Außerdem können wir von dieser Einstellung aus unsere Ansicht ändern Hier sehen wir, dass wir nur sehr wenige Optionen haben , um unseren Commit-Verlauf zu durchsuchen. Zum Beispiel können wir unsere Commits nicht filtern, können nicht nach einer bestimmten Funktion oder Variablen und vielen zusätzlichen Dingen suchen oder Variablen und vielen zusätzlichen Dingen Github-Desktop-Anwendung hat eine einfache Benutzeroberfläche, ist aber nicht die beste für die Verwendung von Git Dies ist ein Artikel , der mir gefällt. In diesem Artikel sehe ich, dass Entwickler sagen, dass sie die Github-Desktop-Anwendung nur dann mögen , wenn sie Git-Anfänger sind. Aber wenn sie Git genauer lernen, mögen sie die Github-Desktop-Anwendung nicht wirklich. Ich stimme dem ein wenig zu, aber das bedeutet nicht, dass Sie die Github-Desktop-Anwendung deinstallieren müssen . Sie können Github destra Publication verwenden , wenn Sie sich wohl fühlen Es liegt ganz bei dir. 41. Browserverlauf in VS Code und GitKraken: Lassen Sie uns nun sehen, wie wir den Verlauf mit unserem bevorzugten Code-Editor VS-Code durchsuchen können Verlauf mit unserem bevorzugten Code-Editor VS-Code Wie wir im vorherigen Abschnitt gesehen haben, können wir hier unsere Änderungen im Code sehen. Aber was ist , wenn wir die Geschichte unserer Mets und auch die Liste der Kometen sehen unserer Mets und auch die Liste der Kometen Wir können es im VS-Code sehen, aber wir können es mit einer Erweiterung namens Gitans sehen Dies ist eine der beliebtesten Git-Erweiterungen in VSCode, und das Lustige daran ist, dass diese Erweiterung von Git Kraken Sie verwenden Git Kraken anstelle von Github Desktop, dann sehen Sie dieselbe Oberfläche wie in dieser Erweiterung Hier finden Sie linken Seite zwei weitere Optionen für Git Lens Öffne das erste, lass mich ein bisschen herauszoomen, schließe das, schließe das auch. In dieser Hinsicht haben wir viele Optionen. Sehen Sie, zuerst haben wir den Commit-Graph. Dies ist eine der beliebtesten Methoden, um den Verlauf von Auslassungen anzuzeigen. Hier können wir sehen, dass wir eine Liste unserer Commits bekommen und hier können wir auch den Text abrufen , den wir den Commits geben Als Nächstes haben wir die Commit-Nachricht, den Namen des Autors, Änderungen an den Dateien, Uhrzeit und die Commit-Referenz Oben finden wir auch die Suchleiste für die Suche nach den Kometen Wenn wir hier etwas suchen, dann werden nur die Anzeigen hervorgehoben, deren Commit-Nachricht dieses Wort hat Für weitere Suchfilter haben wir hier ein kleines Drop-down-Menü. Zuerst erhalten wir meine Änderungen, die uns nur die Kometen zeigen die Sie verantwortlich sind Als Nächstes haben wir eine Nachricht für die Suche nach der Commit-Nachricht. Als Nächstes haben wir den Autor, nach dem wir Commits nach dem Autorennamen suchen können Danach haben wir Commit SHA, in dem wir Commits anhand der Commit-Referenz suchen können Als Nächstes können wir auch nach einer bestimmten Datei suchen. Zum Beispiel schreiben wir hier Indexpunkt-HTML. Siehst du, hier werden nur die Commits hervorgehoben. Und zu guter Letzt haben wir noch Änderungen , anhand derer wir nach Funktionen oder Variablen suchen können Wenn wir nun einen Befehl auf der rechten Seite auswählen, können wir weitere Details zu diesem Commit sehen. Oben erhalten wir die Commit-Referenz. Hier geben wir unseren Namen, die Uhrzeit und auch die Commit-Nachricht heraus . Jetzt unten haben wir einen Abschnitt für die geänderte Datei, und hier erhalten wir die Anzahl der hinzugefügten Dateien, die Null ist, die Anzahl der geänderten Dateien, die eins ist, und die Anzahl der entfernten Dateien, die Null ist. Und darunter erhalten wir die Liste der Dateien die hinzugefügt, geändert oder entfernt wurden. Wenn wir diese Datei auswählen, können wir den Unterschied sehen , den wir in dieser Datei machen. Sehr nützlich. Jetzt, nach den Commit-Graphen, haben wir mehr Optionen. Aber wie wir sehen können, gibt es viele Dinge, die wir hier nicht sehen können, und deshalb ist es wichtig, Git-Befehle zu lernen. Es liegt ganz bei dir , was du lernen möchtest. Meiner bescheidenen Meinung nach ist es für Sie vorteilhafter, beides zu lernen. Lassen Sie mich Ihnen zeigen, wie wir den Verlauf mit der Anwendung Git Kraken durchsuchen können Verlauf mit der Anwendung Git Kraken Wir öffnen unseren Projektordner, den wir öffnen möchten , und klicken einfach mit der rechten Maustaste hier und öffnen ihn mit Git Kraken Hier ist die Oberfläche der Git Kraken-Anwendung. Es ist der Git-Linsenerweiterung sehr ähnlich. Hier sehen wir die Liste der Commits, die wir oben gemacht haben. Wir haben auch Suchoptionen, Wir haben auch Suchoptionen mit denen wir nach Commit-Nachrichten suchen können Hier können wir Commits auch nach den Autoren filtern. wir nun den Commit auswählen, werden die Commit-Details auf der rechten Seite angezeigt Hier erhalten wir die Commit-Referenz, Commit-Nachricht, den Autor, Datum und Uhrzeit sowie die geänderten Dateien. Wenn wir Datei auswählen, erhalten wir hier die Änderungen. Wir können den Ansichtstyp auch auf Split ändern. Ganz oben können wir es auch vorwerfen, wenn wir den Autor des Commits sehen. Auf der rechten Seite haben wir auch eine Baumstruktur in Ordnern, und wir können auch alle unsere Projektdateien anzeigen. Sie können also sehen, dass wir mit der Kraken-Anwendung ganz einfach unseren Verlauf durchsuchen können Wir verwenden Git Lens, dann haben wir nicht so viel Speicherplatz Es ist sehr überlastet. Verwenden Sie also, was auch immer Sie verwenden möchten, es liegt ganz bei Ihnen Im nächsten Abschnitt werden wir uns nun mit dem wichtigsten Thema von Git befassen, nämlich Branches. Wir sehen uns im nächsten Abschnitt. 42. Abschnitt 04 Arbeiten mit Zweigen: Willkommen im vierten Abschnitt des ultimativen Git-Kurses. In diesem Abschnitt erfahren wir alles über Branches, wie man Branches erstellt, sie betrachtet, mit Branches vergleicht, wie man sie zusammenführt, Konflikte löst und vieles mehr Dies ist eines der wichtigsten Themen von Git. Ich weiß, dass du dich darüber freust, also lass uns diesen Abschnitt beginnen. 43. Was ist Branch: Wie wir wissen, ist unser Task-Track-Projekt das StmlNcsSpject, das ich zum Üben von Git erstellt habe Stellen Sie sich jetzt vor, wir fügen eine neue Funktion hinzu. Zum Beispiel die Drag-and-Rob-Funktion in diesem Projekt. Anstatt diese Funktion zu unserem Master-Branch hinzuzufügen, können wir einen neuen Branch erstellen. Git Branch ist wie eine neue Zeile in unseren Mets. Da wir also wissen, wann wir unseren Code übergeben, geben wir Master Pointer auf unseren letzten Commit wir nun entscheiden, dass wir unserem Projekt eine neue Funktion hinzufügen möchten , erstellen wir zunächst einen neuen Branch, sagen wir, eine Drag-and-Drop-Funktion oder eine DND-Funktion Jetzt hat dieser Zweig dieselbe Momentaufnahme unseres Codes. Hier können wir unseren neuen Feature-Code festschreiben, und wenn wir diesen Code festschreiben, hat das keinen Einfluss auf unseren Master-Branch-Code. Wir können isoliert an unserem Code arbeiten. Jetzt fragst du dich vielleicht, warum wir Branches erstellen müssen. Können wir unseren Code sogar in den Master-Branch übertragen? Nein, das können wir nicht tun, denn wenn wir Code schreiben, ist das nicht das Problem. Aber wenn wir mit unserem Code Mist gebaut haben, wollen wir den fehlerhaften Code nicht in unserer Code-Historie speichern in unserer Code-Historie Wenn wir einen Branch erstellen und unseren Code durcheinander gebracht haben, können wir diesen Branch einfach komplett entfernen, ohne dass sich dies auf unseren Master-Branch auswirkt Das ist die Idee. Jetzt fragst du dich vielleicht, woher Git weiß , an welchem Ast oder Mantel wir gerade arbeiten? Dafür hat Git einen weiteren Zeiger namens Head. Wir haben diesen Zeiger bereits gesehen. Standardmäßig befindet sich unser Kopfzeiger mit Master- oder Hauptzeiger. Wenn du an einem anderen Branch arbeitest, bewegt Git den Head-Zeiger nur auf diesen Branch-Commit. So funktionieren also Git-Branches. Denken Sie der Einfachheit halber daran, Sie, wenn Sie an etwas anderem arbeiten möchten, isoliert daran arbeiten können, indem Sie Branches erstellen. In großen Unternehmen arbeiten viele Teams in verschiedenen Branchen, sodass ihr Code keine Probleme mit dem Master-Branch verursacht, und wir haben einen stabilen Code in unserer Geschichte. 44. Einen neuen Zweig erstellen: die Zweige zu üben, werden wir nun unser vorheriges Projekt verwenden , den Kurs Task Track. Wenn Sie mit diesem Abschnitt beginnen, finden Sie diesen Task-Track-Projektordner in den Ressourcen dieses Videos. In diesem Projekt werden wir uns vorstellen, an der Dragon-Drop-Funktion zu arbeiten Dafür werden wir unsere erste neue Filiale gründen. Das Erstellen des Zweigs in Git ist sehr einfach. Wir müssen nur den Git-Branch-Feature-Slash DND schreiben, was Dragon Drop bedeutet Hier kannst du einen beliebigen Namen verwenden. Ich verwende Funktionen als DND um klarzustellen, dass wir an anderen Funktionen arbeiten, nicht um die Fehler zu beheben Es liegt ganz bei dir, wie du es nennen willst. Ich fand diesen Stil nützlicher, also verwende ich ihn. Um die Zweige zu sehen, können wir schreiben, ordnen, verzweigen und sie uns ansehen. Hier haben wir nur zwei Zweige mit dem Schrägstrich DND und unseren Standardzweig , Derzeit befinden wir uns im Master-Zweig, und deshalb bekommen wir den Stern vor dem Master-Zweig Und wir können hier auch den aktuellen Filialnamen sehen. Um nun am DND-Zweig zu arbeiten, müssen wir zuerst zu diesem DND-Zweig wechseln Ganz am Anfang müssen wir den Befehl Git checkout verwenden, um den Zweig zu wechseln müssen wir den Befehl Git checkout verwenden, um den Da dieser Befehl jedoch etwas verwirrend ist , führen wir einen neuen spezifischen Befehl zum Wechseln von Branches ein, nämlich Git Switch. Hier schreiben wir unseren Branch-Namen , der Feature-Slash DND lautet Sehen Sie hier, wie unsere Marke Lovely geändert hat. Lassen Sie uns dieses Projekt nun im VS-Code mithilfe der Codeperiode öffnen . Nehmen wir an, wir sagen voraus, dass wir eine Drag-and-Draw-Funktion hinzugefügt haben. Um das zu demonstrieren, öffne ich diesen JS-Ordner und in dieser Skriptpunkt-JS-Datei. Und oben füge ich Befehle hinzu, indem ich Control Slash oder Command Slash verwende und die Funktion ag und draw hinzufüge Unten im Punktprotokoll der Konsole befindet sich die Drag-and-Drop-Funktion Speichern Sie diese Datei und sehen Sie, wie wir hier die Änderungen erhalten. Jetzt können wir vorhersagen, wir schließen hier die Implementierung unserer Dragonrop-Funktion Wir können diese Änderungen mit Git add period zum Staging-Bereich Danach implementieren Git comt und message die Dragon-Drop-Funktion Siehst du, hier wird eine Datei geändert und zwei eingefügt. Nett. Schauen wir uns jetzt die Commits an. Protokoll abrufen, eine Zeile. C, oben haben wir den Feature-Slash DND-Commit und unser Headpointer befindet sich derzeit auf dem Feature-DND-Zweig Ich möchte also eines klarstellen: Die Änderungen, die wir in diesem Zweig vorgenommen haben , werden nur in diesem Zweig sichtbar Wenn wir mit Kit Switch Master zurück zum Master-Zweig wechseln, sehen Sie, hier bekommen wir die alte Version unseres Codes. Wenn wir nun unsere Commits protokollieren, bekommen wir hier nicht die Features Slush D und D coat , weil das unserer Masterin Kate einen Schritt voraus ist Wenn du alle Branches sehen willst, dann müssen wir hier schreiben: gate, log, d dash, one line, d dash Siehst du, hier haben wir den Zweig. In Zukunft werden wir diese Feature-Implementierung erfolgreich abschließen und wir wollen diesen Code mit unserem Master-Branch hinzufügen. Wir können diesen Code im Master-Branch zusammenführen. Das werden wir in den kommenden Lektionen sehen. Aber nachdem wir unseren Zweig mit dem Master-Branch zusammengeführt haben, müssen wir unseren Branch löschen Zum Löschen schreiben wir Git Branch D, hier schreiben wir unsere Branch-Namen-Features D und D. Nun, gibt uns einen Fehler oder wir können eine Warnung sagen, das gibt uns einen Fehler oder wir können eine Warnung sagen, was uns bedeutet, dass dieser Zweig nicht vollständig zusammengeführt ist , weil wir diesen Zweig nicht mit dem Master-Branch zusammengeführt Wenn Sie diesen Zweig wirklich löschen möchten, können wir denselben Befehl mit dem Großbuchstaben D schreiben . Derzeit entferne ich diesen Zweig nicht, entferne ich diesen Zweig nicht da ich Ihnen in den nächsten Lektionen zeigen werde, wie Sie mit Branch arbeiten und ihn zusammenführen können. Ich hoffe, du verstehst Zweige. In einfachen Worten: Get Branches helfen Entwicklern, isoliert zu arbeiten. 45. Änderungen zwischen Zweigen anzeigen: Jetzt können wir uns in unserem Projekt manchmal nicht wirklich erinnern, was wir in unserer Filiale ändern, besonders wenn wir zwei, drei Tage Pause einlegen. Wie können wir dann die Liste der Komats sehen , die wir nach unserer Hauptniederlassung spielen Dafür verwenden wir also Kit, Log, Master, Dot Dot Hier schreiben wir unseren Branchennamen , der Feature-Slash DND lautet Siehst du, hier bekommen wir nur einen davon , was wir in der letzten Lektion getan haben Wenn wir mehr als einen Commit gemacht haben, dann bekommen wir hier auch all diese Commits . Wenn wir nur die Commit-Nachricht sehen wollen, dann können wir natürlich einen Gedankenstrich in einer Zeile verwenden Jetzt fragst du dich vielleicht, was ist, wenn ich die tatsächlichen Änderungen sehen möchte , die wir zwischen unserem Master - und dem DND-Zweigcode vorgenommen haben zwischen unserem Master - und dem DND-Zweigcode Erinnerst du dich, welchen Befehl wir verwenden, um den Unterschied zwischen zwei Commits vorherzusagen Dafür verwenden wir den Befehl Diff. Wir schreiben Git, Dave, Master, Punkt, Punkt, das sind Schrägstriche D und D. Mit diesem Befehl sehen wir den Unterschied zwischen diesen beiden Zweigen Sehen Sie, hier ändern wir unsere Punkt-JS-Datei mit einem Skript, die sich im JS-Ordner befindet, und wir können sehen, dass diese beiden Zeilen hinzugefügt wurden Hier habe ich einen kleinen Shortcut-Trick für dich. Wenn wir an einem dieser Branches arbeiten, können wir nur die andere Commit-Referenz oder den Branch-Namen schreiben . In einfachen Worten, hier sind wir derzeit im Master-Branch. Wir können hier einfach so schreiben, Kate D und wir schreiben direkt unseren Filialnamen , mit dem wir vergleichen wollen. Feature Slash D und D. Siehst du, hier haben wir den Unterschied Nun könnte man sagen, dass diese beiden Ausgaben unterschiedlich sind, und das ist wahr Die Sache ist die, wir vergleichen Master Branch mit unserem Feature, Slash-DND-Zweig, und das ist der Grund, warum wir bekommen, dass diese beiden Zeilen eingefügt werden Jetzt vergleichen wir im Shortcut-Rig Feature, Slash-DND-Zweig mit unserem Master-Branch, und das ist der Grund, warum wir hier zwei Zeilen löschen Aber das spielt keine Rolle , weil wir nur den Unterschied sehen wollen Manchmal wollen wir nur die Dateien sehen , die geändert wurden. Dafür können wir also nur Get did name schreiben, oder wir können n status verwenden und unseren Features-DND-Zweig schreiben Siehst du, hier ändern wir nur eine Datei, nämlich eine Script Dot JS-Datei Wenn wir also diesen DND-Zweig mit unserem Master-Zweig zusammenführen, wird unsere einzige Datei geändert Wir verwenden die Option „Nur mit Bindestrich“, dann erhalten wir nur die Dateinamen Aber da wir den Namen Dash Status verwenden, erhalten wir die Dateinamen mit dem Status „Änderungen“, Einfügen“ oder „Löschen“. In der nächsten Lektion werden wir uns mit Sassing Git befassen. 46. Master-Stashing: Bevor wir anfangen, Verstauen zu lernen, lass mich dir eine Stellen Sie sich vor, Sie arbeiten an Ihrem wichtigen Projekt und Ihrem wichtigen Projekt und sind bei der Hälfte Ihres Codes Jetzt kommt plötzlich Ihr Manager zu Ihnen und fordert Sie auf, den Fehler in der Dragon-Drop-Funktion sofort zu beheben. Was werden Sie jetzt in dieser Situation tun? Eine Möglichkeit besteht darin, dass Sie die von Ihnen vorgenommenen Änderungen dann an der Dragon-Drop-Funktion arbeiten können. Aber wie ich dir schon gesagt habe, hast du die Hälfte deines Codes erreicht. Du kannst diesen Code nicht eintragen. Es sieht unprofessionell aus. Was ist nun die Lösung in dieser Situation? Zu diesem Zeitpunkt können wir unsere aktuellen Änderungen in der Ecke des Tores speichern , und wenn wir mit unserer anderen Aufgabe fertig sind, können wir zu diesen Änderungen zurückkehren. Auf diese Weise bleibt unser halber Code nicht in Kommas stehen und wir verlieren auch nicht unseren halben Code Dieser Vorgang, bei dem wir unseren halben Code in der Ecke speichern , heißt Atsing Sas, was bedeutet, ihn irgendwo zu verstecken Um den halben Code anzuzeigen, füge ich dem Skript den Punkt jslecs dot log Das ist halber Code. Ich will nicht verlieren. Speichern Sie die Änderungen, und wenn wir hier unseren aktuellen Status überprüfen, erhalten wir eine Änderung. Wenn wir versuchen, zu den Funktionen des DND-Zweigs zu wechseln, erhalten wir die Fehlermeldung, dass Ihre lokalen Änderungen an den folgenden Dateien beim Auschecken überschrieben würden Bitte bestätigen Sie Ihre Änderungen oder aktualisieren sie , bevor Sie die Filiale wechseln Im Grunde bedeutet es, dass wir diese Änderungen verlieren, wenn wir die Änderungen nicht festschreiben oder bereitstellen und versuchen, zu einer anderen Branche zu wechseln . Um den Code zu speichern, schreiben wir Git Push A und hier schreiben wir unsere Stressnachricht für die Zusammenfassung Nehmen wir an, wir arbeiten an Änderungen des Website-Designs. Siehst du, wir bekommen das Arbeitsverzeichnis und den Index auf Master gespeichert. Jetzt wollen wir alle Aufgaben sehen, die wir in unserem Projekt gemacht haben. Dann schreiben wir eine Git-Statistikliste. Siehst du, hier bekommen wir das Ss, markieren als bei Rot in der geschweiften Klammer Null im Master-Branch und unsere SS-Meldung Nun, hier ist eine Sache. Dieser Befehl git stash push fügt der Treppe keine Datei hinzu, die nicht verfolgt wurde Zum Beispiel erstelle ich hier im JS-Ordner eine neue Datei namens tamp dot js erstelle ich hier im JS-Ordner eine neue Datei namens tamp Und in dieser Datei füge ich temporäre Befehlsdatei hinzu. Speichere das. Und wenn wir Git Status schreiben, bekommen wir hier die Tempt-JS-Datei als nicht getrackte Datei Wenn wir hier also Git Push ausführen, wird Git diese Datei standardmäßig nicht zu unserem Stash hinzufügen Dafür müssen wir also hier schreiben, oder wir können A schreiben, dann für Stash-Nachricht Hier können wir sie auch kombinieren und dann unsere Stash-Nachricht schreiben, die eine temporäre Datei hinzufügt Wenn wir nun erneut Git Stash List ausführen, dann kommen wir hier Sehen Sie sich hier unseren ersten Strich an, gehen Sie zu den Statistiken Belüfter Eins über und unseren letzten Strich, der bei Statistik Belüfter Null hinzugefügt wurde Hier haben wir erfolgreich unsere aktuellen Änderungen veröffentlicht. Jetzt können wir mit Git Switch, Features DND Branch , zum Feature-DND-Zweig wechseln Sehen Sie, hier erhalten wir den aktuellen Branch-Namen, und in unserem Code-Editor auch unsere Skriptdatei wurde auch unsere Skriptdatei auf die Feature-DND-Version geändert Denken Sie daran, dass wir diese Konsolenzeile bearbeiten. Stellen Sie sich nun vor, wir beenden unsere Arbeit an diesem Zweig, sodass wir wieder zum Master-Zweig wechseln können. Jetzt wollen wir die Änderungen, die wir hinzugefügt haben, in den Stash aufnehmen Bevor wir diese Änderungen hinzufügen, möchten wir nun sehen, was diese Änderungen sind Um die Änderungen zu sehen, schreiben wir Git Show und hier schreiben wir den Namen unseres Stashs, der iteriert wird, in Ci-Klammern, Null Nun, wenn du diesen komischen Namen nicht schreiben willst, dann können wir nur diese Zahl Null schreiben Sehen Sie hier, wir bekommen nichts, weil wir in dieser Statistik nur untrackfle temp dot js hinzugefügt haben Standardmäßig wird die Track-Datei in diesem Befehl nicht angezeigt. Um also auch UntrackFle zu sehen, müssen wir hier U hinzufügen du, jetzt bekommen wir die Datei Temp dot js und eine Einfügung Wenn Sie diese Änderungen in unserem lokalen Arbeitsverzeichnis übernehmen möchten , können wir Git apply zero schreiben Siehst du, jetzt haben wir die Track-Datei und können sie auch in unserem Code-Editor überprüfen. Gut. Jetzt, wo wir diese Änderungen in unserem Arbeitsverzeichnis anwenden, brauchen wir diese Null nicht. So können wir den Stash entfernen und wollen nicht zu viel Vorrat in unserem Projekt ansammeln Es ist eine sehr gute Praxis, Stash zu entfernen , den wir nicht mehr benötigen Wir können Gates Drop Zero schreiben. Also, wenn wir die Liste der Beute sehen, kriegen wir den Vorrat nicht Jetzt wenden wir diesen Stash einfach in unser Arbeitsverzeichnis an. Wir schreiben Git, bewerben und was wir hier schreiben, schreiben Wir schreiben hier wieder Null, weil wir die erste Null entfernen und unsere Eins auf Null markieren. Siehst du, wir haben zwei Änderungen in unserem Projekt, eine in der Skriptdatei und eine Track-Datei. Lassen Sie uns auch diesen einen Stress entfernen. Also können wir es wieder auf Null schreiben. Oder wir können es auch klar verwenden. Dieser Befehl entfernt alle Stasen aus unserem Projekt. Siehst du, alle Stasen sind jetzt weg. 47. Merge in Git verstehen: Stellen Sie sich nun vor, wir sind mit unserer Drag-and-Row-Funktion fertig und möchten diesen Code mit unserem Master-Branch zusammenführen. Aber bevor wir etwas tun, müssen wir zuerst den aktuellen Zweig überprüfen. Siehst du, wir sind im Hauptzweig. Also müssen wir zuerst zum Feature Slash DND Branch wechseln Feature Slash DND Aber hier haben wir einige Änderungen in unserem Arbeitsverzeichnis, und das ist der Grund, warum wir uns für den Wechsel entschieden haben Aber hier wollen wir diese Änderungen nicht, also können wir gewaltsam zu unserem DND-Zweig mit Schrägstrich wechseln unserem DND-Zweig mit Schrägstrich Dafür müssen wir Gate, Switch, Four, Feature Slash DND Branch schreiben Switch, Four, Feature Slash DND Branch Überprüfen Sie Ihren Code noch einmal, bevor Sie diesen Befehl in Ihren Projekten ausführen , da Sie Ihre Änderungen dauerhaft verlieren werden Jetzt schreibe ich in unserer Scrap Dot JS-Datei hier in der Konsole fertig mit der Drag-and-Drop-Funktion und entferne diesen Befehl auch von oben. Lassen Sie uns diese Konsole entfernen Diese Datei und entferne auch diese Stempel-Dogs-Datei. Das wollen wir nicht. Jetzt zurück zum Terminal. Hier führen wir zunächst unsere Änderungen durch. Und dann können wir einfach Git Cate M, komplett, Drag-and-Drop-Funktion verwenden. Gut. Jetzt wollen wir unseren Feature-DND-Zweig mit unserem Master-Branch zusammenführen unseren Feature-DND-Zweig mit unserem Master-Branch Es gibt also zwei Arten der Zusammenführung in Git. Die erste Methode lässt sich schnell zusammenführen und die zweite Methode ist die Drei-Wege-Zusammenführung Sehen wir uns jede Art der Zusammenführung anhand eines einfachen Beispiels an. Zuerst werden wir uns das Fasten für unsere Zusammenführung ansehen. Hier haben wir also mehrere Amide und danach erstellen wir einen neuen Zweig namens Feature D&D. In diesem Zweig haben wir nun In dieser Phase der Hilfe sind wir mit unserem Feature fertig und beschließen, unseren Feature-Branch mit dem Master-Zweig zusammenzuführen Master-Zweig Zu diesem Zeitpunkt können wir diese beiden Zweige also direkt zusammenführen, ohne uns um irgendetwas kümmern zu müssen. Diese Verschmelzung nannten wir den schnellen Krieg gegen die Verschmelzung. Sehen wir uns nun die Drei-Wege-Verschmelzung an. Zuvor, nachdem wir den Branch erstellt hatten, haben wir in unserem Master-Branch nichts festgeschrieben In der realen Welt geschah dies jedoch sehr selten, da, wie wir wissen, viele Entwickler an einer einzigen Anwendung arbeiten. Es gibt eine Möglichkeit, sich andere Entwickler im Master-Branch engagieren. Zu dieser Zeit werden unsere Filialen immer vielfältiger. Wir haben also einige Änderungen im Master Branch , die wir in unseren Funktionen S D und D Branch nicht haben. Wenn wir hier merge ausführen, verschiebt Git unseren Master nicht auf den Feature-Slash-DND-Commit weil dadurch Änderungen aus dem Master-Branch entfernt werden Wenn wir also den Befehl here merge ausführen, erstellt Git einen neuen Commit, der die Änderungen aus diesen beiden Branches kombiniert Jetzt fragst du dich vielleicht, warum wir diese Zusammenführung als Drei-Wege-Merge bezeichnen , weil sie von den drei Commits abhängt Der erste ist der gemeinsame Verbindungspunkt zweier Zweige. zweite ist der letzte Punkt im Master-Branch , der als Spitze des Master-Branches bezeichnet wird, und der dritte ist die Spitze des Feature-Slash-DND-Zweigs und der dritte ist die Spitze des Feature-Slash-DND-Zweigs Git schaut euch diese drei Kometen und fügt unseren Code so zusammen , dass dieser neue Komet, der durch Gangart entstanden ist, Merge , dass dieser neue Komet, der durch Gangart entstanden ist, Camt heißt Um es noch einmal zusammenzufassen: Es gibt zwei Arten der Verschmelzung. der ersten Methode handelt es sich um die Option „Seite für“ oder „Zusammenführen falls sich unsere Zweige nicht voneinander unterscheiden, oder wir können sagen, dass wir unserem Hauptzweig keinen neuen Kometen hinzugefügt haben, nachdem wir einen neuen Zweig erstellt haben Die zweite Möglichkeit besteht darin, in drei Richtungen zusammenzuführen falls unsere Zweige voneinander abweichen, oder wir können sagen, dass wir im Master-Branch einen neuen Commit ausgeführt haben , nachdem wir den Branch erstellt haben In den nächsten Lektionen werden wir sehen, wie diese beiden Keine Sorge, es ist wirklich einfach. 48. Fast Forward Merging anwenden: Sehen wir uns nun das Tempo für unsere Zusammenführung an. Um es schnell für das Zusammenführen zusammenzufassen, haben wir einen linearen Commit-Pfad und get bewegt den Master-Zeiger direkt auf unsere Funktionen dndAskt Schauen wir uns an, wie wir das machen können. Zuallererst werden wir all unsere Codes protokollieren, und wie wir wissen, müssen wir, wenn Sie die Zweige sehen wollen, das Protokoll verwenden, wenn Sie die Zweige sehen wollen, das Protokoll verwenden, eine Zeile mit Strich, alle mit Strich und alle mit dem Strich. Und wenn wir mit Zweigen arbeiten, können wir hier die Option Dash Graph schreiben. Ich kann nur empfehlen, diese Grafikoption zu verwenden , da sie uns zeigt, ob es verschiedene Kometen gibt oder nicht Außerdem müssen Sie diesen langen Befehl nicht jedes Mal schreiben Sie können as dafür verwenden. Derzeit haben wir keine unterschiedlichen Kometen und deshalb können wir auch keine unterschiedlichen Graphen sehen, aber es sieht so aus Jetzt können wir sehen, dass wir uns gerade im Feature-DND-Zweig befinden , weil unser Kopfzeiger hier ist Um nun diesen Feature-DND-Zweig in unserem Master-Branch zusammenzuführen , müssen wir zuerst zum Master-Branch wechseln Gut. Jetzt können wir sehen, dass unser Kopfzeiger auf den Master-Branch bewegt wird. Um diese Zweige zusammenzuführen, schreiben wir Git Merge und dann schreiben wir unseren Branch-Namen , den wir in Master Branch zusammenführen wollen. Siehst du, hier kommen wir schnell zum Zusammenführen. Jetzt können wir mit unserem vorherigen Befehl wieder alle Kometen sehen mit unserem vorherigen Befehl wieder alle Kometen Sehen Sie hier, wir bekommen keinen neuen Kometen, sondern bewegen Sie sich einfach über den Master-Zeiger zum Feature SS DND-Zweig, weil wir lineare Kometen haben oder wir sagen können, dass wir nicht Was ist, wenn wir manchmal die Fast-Forward-Zusammenführung nicht anwenden wollen ? Es ist völlig in Ordnung. In Git können wir auch Non-Fast-Forward-Merge anwenden, und das werden wir in der nächsten Lektion sehen. 49. Nicht Fast Forward Merging: Lassen Sie mich Ihnen nun zeigen, wie wir eine schnelle Zusammenführung vermeiden können wir eine schnelle Zusammenführung vermeiden Um das zu demonstrieren, müssen wir einen neuen Zweig erstellen und dann zu diesem Zweig wechseln Das sind also zwei verschiedene Schritte. Lassen Sie mich Ihnen die Abkürzung zeigen, mit Sie diese beiden Schritte in einem Schritt ausführen können. Damit wir Gate Switch C für Create schreiben können , schreiben wir hier unseren Filialnamen. Nehmen wir an, es gibt Feedback. Siehst du, wir wechseln direkt zum Feedback-Bereich. Jetzt zurück zum VS-Code, und hier öffne ich den Indexpunkt stmlFle Wenn Sie sich fragen, wie ich die Datei öffne, drücken Sie einfach Strg+P oder Befehl+P und schreiben Sie hier den Dateinamen Jetzt füge ich unten, nach unserem Haupt-Tag, nach unserem Haupt-Tag, einen Kommentar für das Feedback-Formular hinzu. Stellen Sie sich vor, wir fügen hier ein Feedback-Formular hinzu, speichern die Änderungen und kehren zu unserer Git-Bash zurück Hier stellen wir zuerst alle Änderungen vor und übernehmen dann die Änderungen als Commit-Nachricht die Änderungen als Commit-Nachricht mit der Feedback-Funktion Gut. Schauen wir uns jetzt unseren Kommentarverlauf an. Siehst du, hier bekommen wir unseren letzten Commit. Lassen Sie uns nun diesen Feedback-Zweig mit unserem Master-Branch zusammenführen , indem wir das Zusammenführen nicht im Schnellvorlauf durchführen Was wir vor dem Zusammenführen tun werden, ist, zurück zum Master-Branch zu wechseln Jetzt schreiben wir hier Gate, Merge, Ff, um nicht schnell vorzuspulen, und schreiben hier einfach unseren Branch-Namen , der Feature-Slash-Feedback ist Mit diesem Befehl teilen wir Git mit, ob ein schneller Vorlauf bei dieser Zusammenführung möglich ist, tun Sie es trotzdem nicht und erstellen Sie einen neuen Befehl , der zwei Zweige kombiniert Der einfache Unterschied zwischen Fast-Forward-Merging und Non-Fast-Forward-Merging besteht darin, dass Git keinen neuen Commit erstellt, aber beim dass Git keinen neuen Commit erstellt, Non-Fast-Forward-Merging erstellt Git einen In dem Moment, in dem wir hier die Eingabetaste drücken, fragt Git nach einer Merge-Commit-Nachricht Standardmäßig erhalten wir hier diese Git generierte Commit-Nachricht. Wenn wir es ändern wollen, können wir es hier ändern. Speichern Sie die Datei und schließen Sie die Datei. Jetzt können wir in unserem Terminal sehen, dass die Zusammenführung abgeschlossen ist. Und wenn wir den Verlauf mit der Option Diagramm sehen, sehen Sie, hier bekommen wir das Diagramm unserer Commits Wir können unseren Master-Pointer sehen, aber unser Feedback-Zweig ist immer noch da, und Git erstellt einen Merge-Commid, der Feedback-Änderungen mit dem Master-Branch kombiniert Und wir erhalten dieses Diagramm, weil wir unserem Log-Befehl die Option graph hinzugefügt haben unserem Log-Befehl die Option graph hinzugefügt Jetzt fragen Sie sich vielleicht, was das Beste für die Zusammenführung ist? Schnelles Zusammenführen oder wir sollten non fast for oder merge verwenden. Schauen wir uns die Vor- und Nachteile der beiden Zusammenführungen an. Zuallererst können wir, wenn wir fast für die Verschmelzung verwenden, unsere Geschichte sehr deutlich erkennen da es bei den Kometen keine Divergenz gibt Wenn wir jedoch nonfast für die Verschmelzung verwenden, könnte unsere Geschichte etwas verwirrend aussehen Im Moment können wir das erkennen, weil wir nur einen Unterschied haben. Aber in der realen Welt haben große Projekte nicht nur einen Zweig Es gibt mehrere Branchen und viele verschiedene Branchen. Das ist der Grund, warum nicht schnell für Verschmelzung etwas verwirrend aussieht, was auch bedeutet, dass schnell für Verschmelzung mehr visuelle Klarheit bietet und wir andererseits weniger visuelle Klarheit über unsere Kometen haben Eine weitere Sache ist, wenn wir Fast Forward Merge verwenden, dann könnten wir einige Kontexte überspringen etwa wenn bestimmte Änderungen Aber wenn wir Non Fast für Merge verwenden, verlieren wir keine Kontexte. Bei jeder Zusammenführung von Kometen haben wir Informationen darüber, wann und wo wir Änderungen vornehmen Danach können wir in Fast Per Merging den Code unserer beiden Zweige nicht isolieren Aber in Non Fast for Our Merging können wir unseren Code für zwei Zweige isolieren, können wir unseren Code für zwei Zweige isolieren weil wir separate Merge-Gummets haben Dies sind die Vor- und Nachteile dieser beiden Zusammenführungen. Meiner Meinung nach haben diese beiden Optionen Vor- und Nachteile. Sie arbeiten als Einzelperson, dann können Sie einen beliebigen Zusammenführungstyp auswählen. Es liegt ganz bei dir. Aber oft wird Ihnen Ihr Team sagen, ob Sie Fast Forward Merge verwenden sollen oder nicht. Wenn wir im Fluss unserer Arbeit sind, vergessen wir vielleicht, die Option „ Kein Schnellvorlauf“ zu verwenden, und Ihr Unternehmen fordert Sie auf, nur die Option „Kein Schnellvorlauf“ zu verwenden. Die Lösung für diese Situation besteht also darin, dass wir Option „ Kein Schnellvorlauf“ für unser aktuelles Projektarchiv oder auch für das gesamte Projektarchiv in unserem System festlegen können . Dafür können wir es config, FF, no schreiben. Dieser Befehl deaktiviert den Schnellvorlauf in unserem aktuellen Repository. Wenn wir außerdem den Schnellvorlauf für das gesamte Projektarchiv deaktivieren wollen , können wir einfach den Eintrag Global hinzufügen. 50. 3-Wege-Zusammenführung verstehen: Sehen wir uns nun das Drei-Wege-Zusammenführen an. Wie wir wissen, wenn wir einen neuen Branch erstellen, einen Commit für diesen Branch durchführen und dann auch einen Commit für unseren Master-Branch, dann können wir diese beiden Branches aufrufen oder voneinander abweichen Schauen Sie sich in dieser Situation nun die beiden Spitzen dieser Zweige an und achten Sie auch auf den gemeinsamen Kometen durch den diese beiden Zweige auseinanderlaufen Es findet heraus, wie diese beiden Zweige am besten kombiniert und diese Veränderungen auf den neuen Kometen übertragen Um dies zu demonstrieren, erstellen wir erneut einen neuen Zweig. Verwenden Sie den Gate-Schalter C für Create und geben dann unseren Namen Feature-Slash-Benutzer Register Jetzt zurück zum VS-Code. Hier im Projektordner erstellen wir einen neuen Ordner namens Benutzerregister. Und in diesem Ordner erstellen wir eine neue Datei namens register form dot SGML Und darin füge ich schnell HTML-Snippet hinzu und ändere den Titel in „Als neuer Benutzer registrieren Speichern Sie diese Datei und kehren Sie zu unserem Terminal zurück. Hier speichern wir zuerst alle Änderungen und übernehmen sie dann auch in unserem Benutzerregister. Gut. Sehen wir uns unsere Geschichte an, indem wir Git Log, Dash One Line, Dash All, Des Dash Graph verwenden. Siehst du, hier bekommen wir unsere neue Filiale. Lassen Sie uns jetzt zurück zum Master-Branch wechseln. In der Punkt-JS-Datei des Skripts fügen wir hier die Zeile Console Dot Log hinzu, und hier lernen wir das Drei-Wege-Zusammenführen über Konsolen Speichern Sie die Datei, und in der Git Bash speichern wir zuerst unsere Änderungen und dann übernehmen wir einfach Git, aktualisiere die Punkt-JS-Datei für die dreiseitige Zusammenführung. Schauen wir uns jetzt noch einmal die Geschichte an. Hier können wir die Divergenz in unseren Filialen sehen. Wenn wir in diesem Zweig arbeiten, können wir direkt hier in den Master-Zweig gehen Dies wird als divergener Zweig bezeichnet. Lassen Sie uns nun diese beiden Zweige zusammenführen. Hier ist eine gute Nachricht für Sie. Wir haben keinen separaten Befehl für die dreiseitige Zusammenführung. Es ist derselbe Befehl, den wir für das Fast-Forward-Merging verwenden Wenn wir unterschiedliche Branches haben, was bedeutet, dass wir nach dem Erstellen eines neuen Branches COMES im Master-Branch hatten , dann wird das Drei-Wege-Zusammenführen automatisch angewendet Was ist der Befehl für das Zusammenführen? Richtig, Git Merge, und hier fügen wir den Feature-Slash-Benutzer hinzu und drücken Der Befehl wird automatisch abgeschlossen. Fragen Sie hier nach der Merge-Commit-Nachricht. Ich lasse es so wie es ist, schließe diese Datei und sehe, wie hier unsere Zweige zusammengeführt werden. Und wenn wir unser Verlaufsdiagramm sehen, dann können wir hier unseren Zweigkometen sehen, und hier haben wir Amid, was wir auf unserem Master-Zweig gemacht haben, und Gate verbindet diese beiden Kometen in diesem separaten Merge-Commit So funktioniert das Zusammenführen in drei Richtungen. Sie könnten fragen, dass Drei-Wege-Verschmelzung und Nicht-Fast-For-Verschmelzung dasselbe sind, und ich hatte dieselbe Frage, als ich das Zusammenführen in Gangart gelernt habe Die Antwort ist nein. Sie sind nicht identisch. Sie sehen vielleicht ähnlich aus, sind aber nicht identisch. Der Unterschied besteht darin, ob wir bei der Verschmelzung lineare Kometen haben und wir trotzdem Zweige in den neuen Verschmelzungskometen kombinieren wollen Zweige in den neuen Verschmelzungskometen kombinieren Dies wird als Verschmelzung ohne schnelle Vorwärtsbewegung bezeichnet. Aber bei der Verschmelzung in drei Richtungen haben wir immer auseinanderlaufende Kometen, und im neuen Verschmelzungskometen werden automatisch Äste kombiniert im Das ist der Unterschied zwischen einer nicht schnellen Verschmelzung und einer dreiseitigen Verschmelzung In der nächsten Lektion werden wir sehen, wie wir Merge-Branch aus unserem Repository entfernen können 51. Zweig löschen nach dem Zusammenführen: Ich weiß, wenn wir mit Branches im Git arbeiten, wenn wir die Arbeit an einem Branch abschließen und sie mit dem Master zusammenführen, dann brauchen wir diesen Branch nicht. Das wird bei uns und auch bei unseren Teammitgliedern für Verwirrung sorgen . Lassen Sie uns überprüfen, welche Branches wir mit Git Branch erstellt haben. Sehen Sie, hier haben wir vier Zweige, und jetzt möchte ich wissen, welche Zweige wir in unserem aktuellen Zweig, dem Master, zusammenführen. Wir schreiben Git Branch, Dash Merge. Siehst du, hier bekommen wir die Liste der Commits , die in unserem aktuellen Branch-Master vollständig zusammengeführt sind Hier erhalten wir alle Branches, weil wir all diese Branches in unserem Master-Branch zusammenführen Jetzt können wir die Branches mit Git Branch D entfernen und unseren Branch-Namen schreiben, sagen wir Feature D&D. Wenn wir nun die Historie unserer Namen sehen, dann wurde Feature DND aus der Historie entfernt Hier ist die Vorher - und Nachher-Geschichte. Siehst du, entferne einfach den Zweig von hier. Das Dienstmädchen wird dort bleiben, wie es ist. Derzeit entferne ich diese anderen Zweige nicht , weil ich sie in Zukunft benötige. Lassen Sie mich Ihnen jetzt einen Bonus geben. Anstatt die zusammengeführten Zweige zu beobachten, ist es einfach, die Zweige, die nicht zusammengeführt wurden, direkt zu sehen , sodass wir sie in Zukunft zusammenführen können. Wir können uns daran erinnern, diesen Zweig nicht versehentlich zu löschen. Dafür schreiben wir git branch, no, d merged. Sehen Sie hier, wir bekommen keinen Branch , weil wir alle Branches in unserem aktuellen Branch-Master zusammenführen . In der nächsten Lektion werden wir sehen, wie man Konflikte in Git löst. 52. Konflikte in Git lösen: Bevor ich mit dieser Lektion beginne, möchte ich Ihnen eine einfache Frage stellen. Stellen Sie sich vor, wir haben zwei Filialen. Einer ist Master und der zweite ist das Feature Slash Login. Stellen Sie sich nun vor, wir ändern die SM-Datei mit dem Indexpunkt in unserem Master-Branch und übernehmen die Änderungen Und auch im Feature-Login-Zweig ändern wir etwas im Indexpunkt stmlFle Kurz gesagt, in diesen beiden Zweigen unterscheidet sich Indexpunkt-SML-Datei Wenn wir diese beiden Zweige zusammenführen, wird Git verwirrt, welche Änderungen es vornehmen sollte und welche Änderungen es vermeiden sollte Und das wird in Git als Konflikte bezeichnet. Wenn wir also dieselbe Datei in verschiedenen Branches ändern und Git diese beiden Branches automatisch zusammenführen kann, wird das als Konflikt bezeichnet. Jetzt fragen Sie sich vielleicht, was die möglichen Lösungen sind , bei denen Konflikte auftreten. Der erste ist also Veränderung. Wir ändern dieselbe Zeile unserer Datei in beiden Zweigen. Danach löschen wir in einem Zweig eine Datei und in dem anderen Zweig ändern wir dieselbe Datei. Dort treten auch Konflikte auf. Außerdem benennen wir den Dateinamen in einem Zweig und dieselbe Datei in dem anderen Zweig um. Außerdem fügen wir Datei mit einem Punkt TXT in den ersten Zweig und wir fügen auch Datei mit einem Punkt TXT in den zweiten Zweig ein, aber der Inhalt der Datei ist anders, sodass auch Konflikte auftreten. Dies sind die häufigsten Situationen , in denen Konflikte auftreten können. Nun fragen Sie sich vielleicht, was es in dieser Situation bewirken wird? Und was ist die Lösung für die Lösung des Konflikts? Git fragt uns einfach und gibt uns Optionen, welche Änderungen wir vornehmen möchten Es wird sich nicht in den Konflikt einmischen. Es wird uns einfach fragen , was wir in dieser Situation tun wollen. Lassen Sie mich Ihnen das praktisch zeigen. den Konflikt zu demonstrieren, müssen wir zuerst einen Konflikt erzeugen. Schreiben wir Gate Switch C, Feature Login und was dieser Befehl schreibt. Es erstellt einen Feature-Login-Zweig und wechselt auch zu diesem Branch. Lassen Sie mich jetzt die ScraptGS-Datei ändern. Die zweite Zeile schreibe ich hier, Console Dot Log, Console for Feature, Slash Speichern Sie diese Datei und lassen Sie mich die Änderungen in Szene und diese Änderungen auch mit der Commit-Nachricht festschreiben, Punkt-JS-Datei des Skripts für die Feature-Anmeldung modifizieren. Erledigt. Jetzt wechseln wir zum Master-Branch und auch im VS-Code ändern wir auch die zweite Zeile und schreiben hier Console for Master Branch. Speichern Sie diese Datei. Und lassen Sie uns die Änderungen probieren. Und außerdem übergeben wir die Datei mit der Nachricht: Modify script dot js file for master. Versuchen wir nun, diese beiden Zweige zusammenzuführen. Also führen wir Gate Merge, Feature Slash Login aus. Sehen Sie, hier bekommen wir Conflict und Gate sagt Merge-Konflikt in der Script Dot JS-Datei Außerdem heißt es, automatische Zusammenführung fehlschlägt und der Konflikt behoben wird, und dann das Committer-Ergebnis Hier müssen wir die Änderungen also manuell vornehmen und wir können auch sehen, dass wir uns mitten in der Zusammenführung befinden Lass mich dir den aktuellen Status nach Git Status zeigen. Siehst du, hier haben wir einen nicht zusammengeführten Pfad. Lass mich dir etwas Cooles zeigen. Öffnen Sie den VS-Code und sehen Sie, hier haben wir die hervorgehobene Zeile geändert, was zu Konflikten führt. Lassen Sie sich von diesem Bildschirm nicht verwirren. Es ist wirklich einfach. Sehen Sie, zuerst erhalten wir den Header-Zeiger , der den aktuellen Zweig anzeigt, der Master ist , und darunter haben wir die Änderung, die wir im Master-Zweig festschreiben. Danach haben wir eine Zeile für die Trennung und dann haben wir die Änderung, die wir im Feature SS Login Branch vorgenommen haben. Siehst du? Hier haben wir ein paar Optionen , die uns der VS-Code bietet. Zunächst müssen die aktuellen Änderungen akzeptiert werden. Wenn wir auswählen, werden die aktuellen Änderungen akzeptiert, sodass die Änderungen aus dem aktuellen Zweig übernommen werden. Lassen Sie uns dies mit Control plus Set oder Command plus Set rückgängig machen . Wenn wir nun „ Die eingehenden Änderungen akzeptieren“ auswählen, werden die Änderungen aus dem zweiten Zweig übernommen, und wir können beide Änderungen übernehmen. Die letzte Option besteht darin, beide Änderungen zu vergleichen. Es wird unsere Dateien Seite an Seite vergleichen. Lassen Sie uns diesen Vergleich schließen. Hier haben wir Optionen nach VS-Code. Wir können die Datei auch manuell ändern. Lassen Sie uns also diese Funktion entfernen, den Anmeldezeiger mit Schrägstrich streichen und auch diese Zeilentrennung entfernen und auch diesen Kopfzeiger entfernen Wenn wir diese Zeilen nach oben und unten verschieben wollen, dann können wir das auch tun Aber denken Sie immer daran, dass wir hier keinen neuen Code hinzufügen , weil das Hauptziel der Zusammenführung darin besteht, den Code zweier Zweige zusammenzuführen, nicht darin, einen neuen Code hinzuzufügen, aber manchmal müssen wir neue Änderungen hinzufügen. Wenn es nicht vermeidbar ist, dann kannst du das auch tun Nachdem wir mit unseren Änderungen fertig sind, stellen wir die Datei bereit und kehren zum Terminal zurück Hier müssen wir die Änderungen zunächst per Git Add Period bereitstellen. Lassen Sie uns nun unseren aktuellen Status überprüfen. Siehst du, wir haben keinen unverschlüsselten Pfad. Wir können Git Commit schreiben und wir bekommen die Commit-Nachricht hier. Ich lasse es so wie es ist, schließe die Datei und sehe, wir führen unsere beiden Zweige zusammen, und auch der Zusammenführungsstatus ist weg 53. Konflikt in Merge abbrechen: Manchmal führen wir den Befehl zum Zusammenführen aus und es entsteht ein Konflikt, aber an diesem Punkt wollen wir diesen Konflikt nicht lösen , weil Konflikte versehentlich auftreten Anstatt also mit dem Zusammenführen fortzufahren, verwenden wir diesen Befehl zum Zusammenführen Aus diesem Grund werde ich keinen neuen Zweig erstellen und Konflikte verursachen Ich werde Ihnen meine vorherige Bildschirmaufnahme zeigen bevor wir unseren Konflikt lösen. Hier führen wir den Befehl Git Merge aus. Siehst du, wir haben einen Konflikt. Wir wollen nicht weiter gehen, wir können schreiben, gatten, zusammenführen und sehen, dass wir vom Zustand der Zusammenführung einen Schritt zurück sind 54. Den Merge-Commit zurücksetzen: A Manchmal, wenn wir zwei Branches zusammenführen und unser Code nicht mehr parkt oder abstürzt, kann das passieren, weil wir beim Zusammenführen von Branches einen Fehler gemacht Es gibt also zwei Lösungen für diese Situation. Erstens können wir unseren Merge-Commit vor dem Zusammenführen auf den vorherigen Wert zurücksetzen . Und die zweite Option ist, dass wir unseren Merge-Code rückgängig machen und ihn im neuen AT festschreiben können . Lassen Sie sich dadurch nicht verwirren, lassen Sie mich Ihnen jedes Szenario erklären. Also zuerst sehen wir den Comet Reset Merge. Also hier in unserem Caid unser Kopf- und Hauptzeiger auf unserem Merge-Met Das ist unser Branch-Pointer. In diesem Merge-Commit bekommen wir jetzt das Problem. Wir können unseren Kometen also zurücksetzen, indem wir diese beiden Zeiger auf den vorherigen Punkt bewegen , bevor wir mit der Verschmelzung beginnen Im Grunde setzen wir die Zusammenführungsschicht auf die vorherige Schicht zurück Jetzt fragst du dich vielleicht, was mit diesem Merge-Commit passieren wird ? wir also unseren Master - und Kopfzeiger auf das vorherige AT bewegen , wird diese Amid sinnlos Nach einiger Zeit wird diese Amid automatisch aus unserem Repository entfernt Wie wir jetzt indirekt sehen können, ändern oder schreiben wir den Commit-Verlauf neu, und das ist nur in Ordnung, wenn wir ein lokales Repository haben Aber wenn viele Teammitglieder an diesem Projekt arbeiten, ziehen wir diese Option nicht in Betracht In dieser Situation, wenn Teammitglieder an demselben Projekt arbeiten, müssen wir unseren Code rückgängig machen und ihn im neuen Befehl festschreiben Also wieder haben wir unsere Commit-Historie. Als wir unsere Zusammenführung rückgängig machten , war Git die Spitze der beiden Zweige Anstatt nun beide Zeiger mit dem vorherigen Kometen zu bewegen , nimmt Git die Änderungen vom vorherigen Amet, macht sie rückgängig und führt dann einen weiteren Kometen durch, nämlich den Commit für die Wiederherstellung Wir können sehen, dass dieser vorherige Commit-Code mit diesem Revert-Commit-Code identisch ist Diese Methode ist praktischer , da wir hier unseren Git-Verlauf nicht neu schreiben Lassen Sie mich Ihnen diese beiden Methoden nacheinander zeigen. Zuerst sehen wir die Reset-Option. Dafür schreiben wir Git Reset, Dash Dash Hard. Wir schreiben hier hart. Ich werde das in einer Minute erklären. Und hier schreiben wir unsere Commit-Referenz, die wir als Head-to-One bezeichnen können. Bevor Sie diesen Befehl ausführen, stellen Sie sicher, dass Sie den Commit ab diesem Merge-Ammt irgendwo in Ihren Knoten schreiben diesem Merge-Ammt irgendwo in Ihren Knoten Im Grunde genommen weist dieser Befehl Git an, den Master- und Headzeiger auf den vorherigen Commit zu verschieben Headzeiger auf den vorherigen Commit zu Hier fragst du dich vielleicht, was macht diese schwierige Option? Wenn wir also den Reset-Befehl ausführen, haben wir drei Optionen: Soft, Mixed und Hard. Lassen Sie mich Ihnen diese im Detail erklären. Hier haben wir also unseren Arbeitsverzeichniscode, Staging-Vorwahl und wir haben unseren Commit-Code Wenn wir jetzt den Reset-Befehl mit der Soft-Option ausführen, wird nur unser Commit-Code auf den spezifischen Commit zurückgesetzt , aber er wird unseren Arbeitsverzeichniscode für die Staging-Vorwahl nicht berühren Arbeitsverzeichniscode für die Staging-Vorwahl Unsere Änderungen im Arbeitsverzeichnis und im Staging-Bereich bleiben also im Arbeitsverzeichnis und im Staging-Bereich dieselben wie bisher Wenn wir nun die gemischte Option von DSD verwenden, was die Standardoption ist, wird der Commit-Code zurückgesetzt und auch der Staging-Bereichscode an diesen Und jetzt können Sie sich vorstellen, was diese schwierige Option bewirkt? Richtig, der Commit-Code, die Staging-Vorwahl und auch der Arbeitsverzeichniscode werden auf den jeweiligen Befehl zurückgesetzt Staging-Vorwahl und auch der Arbeitsverzeichniscode werden auf den jeweiligen Befehl Aus diesem Grund verwenden wir die Option hard mit dem Reset-Befehl. Lassen Sie uns also diesen Befehl ausführen. Siehst du, hier bekommen wir, dass der Kopf jetzt bei diesem Commit ist und wir können auch die Commit-Nachricht sehen. Schauen wir uns noch einmal unsere Geschichte an. Sehen Sie hier, dass unser Head und Master zum vorherigen Commit im Master-Branch verschoben wurden, und wir sehen unseren Merge-Commit nicht in dieser Liste, aber wir können trotzdem zu diesem Commit übergehen, weil Get diesen Commit sofort entfernt. Wir schreiben git reset dash had und hier schreiben wir den Merge-Commit , der E sieben, E sieben, d acht ist . Siehst du, jetzt ist unser Kopf auf den Merge-Commit gerichtet. Wir können in unserer Historie sehen, dass wir den gleichen Merge-Mit erhalten. In der nächsten Lektion werden wir sehen, wie das Zusammenführen besser rückgängig gemacht werden kann, nämlich durch Zurücksetzen 55. Den Merge-Commit zurücksetzen: Lassen Sie mich Ihnen nun die zweite Option zeigen, um die Zusammenführung rückgängig zu machen, nämlich die Merge-Änderungen rückgängig zu Dafür schreiben wir Git Revert, und hier schreiben wir unsere Commit-Has, die wir rückgängig machen wollen In unserem Fall ist es dieser Head-Commit. Also schreiben wir hier, gehen und drücken Enter. Siehst du, hier bekommen wir einen Fehler. Commit ist Merge, aber es wurde keine Option angegeben. Zurücksetzen ist fehlgeschlagen. Also, von welcher Option spricht Kit Also hier ist unser Merge-Commit. Wenn wir zu Merge-Commit zurückkehren sagen, hat Git zwei Optionen Zuerst setzt G den Commit auf den letzten Commit des Master-Branches zurück , und wir nennen diesen Commit als ersten Elternteil, weil wir uns im Master-Branch und wir nennen diesen Commit als befinden zweite Option ist nun, dass es zum letzten Kometen des Feature-Branches zurückkehrt , der als zweiter Elternteil bezeichnet wird Also schreiben wir hier git revert M one, das ist das erste Elternteil unseres aktuellen Zweigs, der Master ist, und welches Commit wir rückgängig machen wollen, wir wollen Head-Commit rückgängig machen das ist das erste Elternteil unseres aktuellen Zweigs, der Master ist, und welches Commit wir rückgängig machen wollen, wir wollen Head-Commit rückgängig machen. Wir wollen Änderungen als zweiten übergeordneten Befehl rückgängig machen, dann können wir hier M two schreiben, aber Ändern wir es auf eins und drücken die Eingabetaste. Fragen Sie jetzt nach der Befehlsmeldung. Ich möchte es nicht ändern, also schließe ich die Datei einfach. Sehen wir uns jetzt die Geschichte an. Oben sehen Sie, dass wir ein neues Commit haben, das ist das Revert-Commit dieses Merge-Commit Auf diese Weise können wir unsere Zusammenführung rückgängig machen , ohne den Commit-Verlauf neu zu schreiben Ich ziehe es immer vor, diese Option zum Zurücksetzen zu wählen , aber letztendlich liegt die Wahl Wenn Ihr Projekt lokal ist, können Sie verwenden, was Sie wollen Wenn Sie jedoch mit dem Team arbeiten, ist das Zurücksetzen die bessere Option 56. Squash-Zusammenführung in der Commit-Historie: Bevor ich nun das Squash-Merging, eine weitere Merge-Technik , lerne , möchte ich Ihnen Hier ist also unser Commit-Verlauf, und wir haben einen Zweig namens Fix Bergh In diesem Zweig beheben wir einen Fehler in unserer Login-Funktion. In diesem Zweig haben wir also ein paar Commits F eins, F zwei und F drei Wir sind mit der Behebung des Fehlers im Login-Formular fertig. Wir können diese beiden Zweige zusammenführen. Wie wir hier sehen können, sind F eins, F zwei und F drei Teil unserer Commit-Historie. Aber um den Fehler zu beheben, stell dir vor, wir hätten ein paar schlechte Commits gemacht, wie zum Beispiel dieses kleine bisschen zu ändern und es festzuschreiben Wir sind bei der Hälfte unserer Arbeit mit der Behebung des Fehlers angelangt, und nur für Checkpoints haben wir diese Kometen gemacht In diesem Fall wollen wir F eins, F zwei und F drei nicht zu unserer Commit-Historie hinzufügen zwei und F drei nicht zu unserer Commit-Historie Die Lösung besteht also darin, dass wir, bevor wir unsere Zweige zusammenführen, einen Squash-Kami erstellen Dabei handelt es sich um die Kombination von F eins, F zwei und F drei, alles in einem einzigen Und dann können wir einfach unseren Hauptzeiger auf diesen Kometen bewegen unseren Hauptzeiger Aber denken Sie daran, dass es sich hier nicht um den verschmolzenen Kometen handelt, weil dieser Komet keine zwei Elternteile hat und wir auch sehen können , dass er nicht mit dem Kometen F 3 verbunden ist Da wir hier alle Veränderungen dieses Zweigs haben, können wir diesen Zweig aus unserer Met-Historie streichen, und jetzt haben wir eine lineare Historie und wir haben keine schlechte Astschicht Das ist der Vorteil der Verwendung von Squash Merge. Jetzt fragen Sie sich vielleicht, sollten wir immer die Squash-Merge-Technik verwenden ? Die Antwort lautet nein. Wir werden Squash Merge nur verwenden, wenn unsere Zweigkometen schlecht sind oder wir die Kometen nicht in der Geschichte behalten wollen die Kometen nicht in der Geschichte behalten wollen Zum Beispiel verwende ich Squash Merging gerne, wenn ich daran arbeite, kleine Fehler oder sehr kleine Funktionen zu beheben, die ich in ein bis zwei Stunden fertigstellen kann Die Situationen, ich brauche diese Checkpoints nicht. Aber wenn das Feature oder der Bug groß ist, verwende ich Squash Merge nicht und behalte die Checkpoints in der Historie Sehen wir uns nun Squash Merge in unserem Projekt an. hier zunächst Lassen Sie uns hier zunächst schnell einen neuen Zweig mit dem Git-Switch C Fix Bugs Login erstellen C Fix Bugs Login Wir gehen zur Änderung zum VS-Code, ich entferne diese drei Konsolenzeilen und füge das neue Konsolenpunktprotokoll ein Login-Bug Checkpoint One behoben. Stellen Sie sich vor, hier sind Ihre Bürozeiten vorbei und Sie möchten den Fehler morgen beheben Deshalb CheckPoint eins. Speichern Sie diese Datei jetzt zurück auf unserem Terminal, und statt Stage und Comet in zwei Schritten können wir hier die Abkürzung Git AM verwenden und eine Commit-Nachricht schreiben, Pigs Bug in der Login-Funktion, Checkpoint eins Gut. Um das noch deutlicher zu machen, werden wir noch einen Commit in dieser Branche durchführen. In unserem Fall kommen wir am nächsten Tag ins Büro und beheben den Fehler komplett. Also vis Cd, und hier entfernen wir den Checkpoint eins, weil wir den Fehler komplett beheben Jetzt nochmal zurück zum Terminal, und hier schreiben wir gate com amfigBug in die Login-Funktion Gut. Schauen wir uns jetzt die Geschichte an. Sehen Sie hier oben, wir haben zwei Branch-Commits Aber wie du siehst, sieht es hässlich aus. Was ist dieser Checkpoint? Hier wenden wir Squash Merge an. Es ist wirklich einfach Im Grunde sind Befehle sehr einfach, sodass diese Situation hier nur mehr Zeit in Anspruch nimmt. Aber es ist wichtig, Ihnen das echte Beispiel zu zeigen. Jetzt fragst du dich vielleicht, können wir hier auf eine Zusammenführung drängen , weil wir keine unterschiedlichen Filialen haben Ja, wir können unsere Verschmelzung schnell erledigen, aber in diesem Fall wollen wir diese beiden Kometen nicht in der Geschichte retten Wir wollen nur die Änderungen speichern, und deshalb machen wir hier Squash Merge, wodurch die Änderungen dieser beiden Kometen kombiniert werden. Zuallererst müssen wir zu unserem Master-Branch wechseln. Bisher haben wir für Merge, Git Merge, Fixburg Login geschrieben Git Merge, Fixburg Login Aber für Squash Merge fügen wir hier einfach die Optionen Squash hinzu. Hier können wir also sehen, dass wir Squash Kammit gemacht haben. Und hier ist die Liste der Dateien, die sich geändert haben. In unserem Fall haben wir nur eine Datei, weil wir nur die Skriptpunkt-JS-Datei geändert haben, aber das Commit wurde dadurch nicht direkt in unsere Historie aufgenommen. Diese Änderungen befinden sich nur im Staging-Bereich. Lass es mich dir zeigen Wir führen Gate Status, C aus, hier bekommen wir die Script Dot JS-Datei, die geändert wurde. Jetzt können wir diese Änderungen festschreiben, Gate Commit. Hier schreiben wir eine Combine-Commit-Nachricht, die anzeigt, dass alle Änderungen in diesem Zweig Nehmen wir an, der Fehler auf der Anmeldeseite wurde behoben, indem Datentyp und der Endpunkt in der API-Anfrage Gut. Schauen wir uns jetzt die Geschichte an. Seht ihr, oben haben wir einen weiteren Kometen, aber er ist nicht mit dem Fix Buerg Slash Login-Zweig verknüpft dem Fix Buerg Slash Wenn wir also diesen Fix-Buurgs-Login-Zweig entfernen, erhalten wir einen klaren und linearen Commit-Verlauf Nun, hier fragst du dich vielleicht, was ist, wenn wir diesen Branch nicht entfernen Idealerweise sollten wir den Zweig nach dem Squash-Merge löschen , da dieser Zweig nicht als zusammengeführter Zweig deklariert ist Lass mich dir zeigen, was ich meine. Wenn wir Ket Branch schreiben, wird Dash zusammengeführt. Hier erhalten wir den FixBurg-Login-Zweig als nicht zusammengeführten Zweig. Aber wie wir wissen, haben wir diesen Filialcode bereits mit Squash Merge in unsere Geschichte aufgenommen diesen Filialcode bereits mit Squash Merge in unsere Geschichte Dies wird in unserer Geschichte für Verwirrung sorgen. Es ist also besser, diesen Zweig zu löschen , wenn wir Squash Merge machen Erinnerst du dich, mit welchem Befehl wir den Branch löschen Mach dir keine Sorgen. Wenn du dich nicht erinnern kannst, kannst du das Cheat-Set auch benutzen Wir schreiben Git Branch, D, und hier schreiben wir den Branch-Namen, der Fixburg Login lautet Hier erhalten wir eine Fehlermeldung, die besagt, dass die Zweige nicht vollständig zusammengeführt sind Also hier müssen wir diesen Zweig gewaltsam löschen. Du bringst den vorherigen Befehl und wir entfernen einfach dieses D und fügen hier D. C hinzu, unser Zweig wurde erfolgreich gelöscht Wenn wir nun unseren Commit-Verlauf überprüfen, werden wir in Ihrem Verlauf bereinigt. Wir verwenden Squash Merge , wenn wir schlechte Commits unserer Branches nicht speichern wollen 57. Wie man den Zweig herunterstuft: Also, was ist Rebasing in Git? Rebasing ist eine Technik , die verwendet wird, um den Basis-Commit des Branches in einen anderen Commit umzuwandeln Lassen Sie mich das anhand des Beispiels erklären. Hier ist unser Commit-Verlauf und wir arbeiten an einem Zweig namens Features OT. Während wir gerade am OT-Branch arbeiten, nehmen wir an, jemand hat sich für den Master-Zweig angemeldet. Jetzt wollen wir diese Änderungen am Master-Branch in unseren Feature-Branch zusammenführen , ohne unnötige Zusammenführungen zu erstellen Was ist hier die Lösung? Eine Lösung besteht darin, diese beiden Zweige zusammenzuführen und dann weiter an ihnen zu arbeiten. Aber dann müssen wir auch ein anderes Feature erstellen , abzüglich der beiden Verzweigungen. Das können wir machen. Eine andere Lösung besteht darin, Rebasing zu verwenden, was im Grunde bedeutet, dass wir die Basis unserer Filiale ändern können Derzeit ist dies die Basis unserer beiden Filialen. Wenn wir unsere Basis auf diesen neuesten Master-Commit ändern, wir Änderungen in unserem Oth-Branch vornehmen, ohne die Branches zusammenzuführen Das ist Rebase. Wir ändern einfach den Basis-Commit unseres Branches. Nun, hier ist eine Sache, die du bei dieser Rebasing-Technik beachten musst , nämlich unsere Met-Historie neu zu schreiben Wenn wir unsere Basis auf einen anderen Amet ändern, dann ändert Git nicht das ursprüngliche Es ist einfach, diese beiden Schichten zu nehmen und gleichen Amet wie sie zu erstellen und sie dann mit dem letzten Master-Coat zu verknüpfen dann diesen Verzweigungspunkt einfach hierher zu verschieben Nun, wie wir sehen können, sind diese Befehle nicht mit dem F verknüpft, das zu übernehmende F wird gelöscht, und F muss übergeben Aus diesem Grund wird beim Rebasing der Befehlsverlauf neu geschrieben, und aus diesem Grund werden wir Rebasing nur anwenden wenn wir lokal ohne Teammitglieder arbeiten Andernfalls wird unsere Geschichte zur Masse. Lassen Sie mich Ihnen jetzt zeigen, wie wir Rebasing durchführen können. Zuerst müssen wir einen neuen Branch mit Git Switch, der C-Funktion OT und zurück zum VS-Code erstellen der C-Funktion OT und zurück zum VS-Code Hier erstellen wir einfach eine neue Datei in Jsfolder namens auth dot Und hier konsolen wir einfach das Punktprotokoll, das an der Authentifizierung arbeitet Speichern Sie diese Datei. Jetzt weniger diese Änderungen. Und dann übergebe ich es mit einer Nachricht an North Dot Jspile Ich weiß, dass das keine richtige Nachricht ist, aber für die Demo Jetzt haben wir also eine Filiale mit einer Katze. Lass uns unsere Geschichte überprüfen. Hier müssen wir einen Kamite im Master machen, um diverge Kamits zu erzeugen Zuallererst werden wir also zurück zum Master-Branch wechseln Öffne den VS-Code und ich werde Änderungen an der JS-Datei des Skripts vornehmen. Also hier entferne ich einfach diese Konsolennachricht und genau hier einige Änderungen, und genau hier einige Änderungen für OT erforderlich sind , und speichere sie. Jetzt zurück zum Terminal und lassen Sie uns die Änderungen probieren, gut, und wir übernehmen sie auch. Git Commit M, Änderungen , die für OT erforderlich sind. Dann schauen wir uns jetzt unsere Geschichte an. Siehst du, jetzt ist unsere Geschichte divergiert. Wenn wir unsere Zweige nicht divergieren, wenden wir Gangart standardmäßig Fast-Forward-Merge Jetzt haben wir unsere divergierenden Zweige. Dann haben wir zwei Möglichkeiten. Wir können eine dreiseitige Zusammenführung anwenden oder wir können eine Rebase einrichten. Gegenwärtig ist unsere zweite Filiale auf diese Kunst ausgerichtet. Beim Rebasing werden wir nun unseren Oth-Zweig auf diesen Gipfel zeigen, der die letzte Amid im Master ist Beim Rebasing müssen wir zunächst zu der Filiale wechseln, für die wir eine Umbenennung vornehmen wollen Hier wollen wir unseren Feature-OT-Zweig rebasen, und danach werden wir Rebase anwenden Wir werden zuerst zum Feature-OT-Zweig wechseln. Was ist nun der Befehl für Rebase? Es ist wirklich einfach Schreiben Sie Git, Rebase und Master. Im Grunde sagen wir es Git. Wir wollen unseren aktuellen Branch auf den Master-Pointer umstellen , der sich derzeit auf dem neuesten Befehl im Master-Zweig Siehst du, wir haben unseren Zweig erfolgreich überarbeitet. In der realen Welt kommt es beim Rebasing oft zu Konflikten Ich werde Ihnen in der nächsten Lektion zeigen, wie wir mit Konflikten umgehen können in der nächsten Lektion zeigen, wie wir mit Konflikten Derzeit konzentrieren wir uns nur auf die einfache Rebase. Mal sehen, was wir in der Geschichte bekommen werden. Siehst du, hier haben wir eine lineare Geschichte. Wenn wir diese nun zusammenführen wollen, dann wechseln wir zuerst zum Master, dann führen wir einfach get merge, feature OT aus und fertig. Siehst du, hier kommen wir schnell zu unserer Zusammenführung, weil wir einen linearen Verlauf haben. Um Ihnen das klarer zu erklären, hier ist die Vorher - und Nachher-Geschichte. Wir können sehen, dass wir nicht den gleichen Astmantel bekommen. Wie ich dir schon sagte, hat er einen neuen Kometen geschaffen, der dem alten Zweigkometen entspricht. Wenn wir im zweiten Zweig drei Medikamente haben, können wir drei neue Schichten haben. In der nächsten Lektion werden wir sehen, was wir tun, wenn es beim Rebase zu Konflikten kommt 58. Konflikte während des Rebases lösen: Sehen wir uns nun an, wie wir mit Konflikten beim Rebasing umgehen können mit Konflikten beim Rebasing Daran ist nichts Besonderes. Wir werden den gleichen Prozess durchführen wie wir zuvor Konflikte gelöst haben. Aber es gibt zwei, drei nützliche Befehle , die wir dabei benötigen. Zuallererst müssen Sie also erneut einen neuen Zweig erstellen. Nehmen wir an, mir geht hier buchstäblich der Name aus. Sagen wir FixBugot. Lassen Sie uns nun einige Änderungen an unserer Indexpunkt-STML-Datei vornehmen. Hier ändere ich den Titel unserer Website. Dann schreiben wir einfach Fix Auth Bug. Sag die Änderungen und zurück zu unserem Terminal. Hier ist ein kurzer Tipp. Wenn Sie nicht zwischen zwei Fenstern wechseln möchten, können Sie das Terminal auch im VS-Code öffnen. Drücken Sie einfach Control plus Batak oder Command plus Batak. Ich benutze Itbash gerne, also wechsle ich dazu. Lassen Sie uns zunächst unsere Änderungen in Szene und uns auch auf die Änderungen festlegen Gate Commit Fixburg Gut. Jetzt müssen wir Änderungen im Master-Branch und in derselben Zeile festschreiben, um Konflikte zu verursachen. Wechseln wir also zurück zum Master-Branch und gehen wir zum VS-Code über. Und in der STL-Datei mit Indexpunkt ändern wir auch den Titel halten uns an mehr Ausrufezeichen Speichern Sie diese Datei. Lassen Sie uns die Änderung probieren und die Änderungen auch mit einer Nachricht bestätigen. Ändern Sie den Titel der Website. Schauen wir uns unsere Geschichte an. Siehst du, hier haben wir unterschiedliche Zweige. Jetzt richten wir diesen Zweig einfach auf den neuesten Master-Pointer um Was ist der erste Schritt der Rebase? Wir wechseln zu dem Zweig , den wir rebasen möchten. Wir wechseln zur FXBurgoth-Filiale. Was werden wir dann tun? Wir schreiben einfach Kit Rebase Master. Sehen Sie hier, wir bekommen den Konflikt in der Index-HTML-Datei. Lassen Sie uns den VS-Code öffnen, und hier können wir Konflikte sehen. Jetzt können wir hier aus diesen drei Optionen wählen. Ich wähle hier die erste Option, außer den aktuellen Änderungen. Speichern Sie diese Datei und kehren Sie zum Terminal zurück. Hier können wir sehen, dass wir uns im Rebase-Prozess befinden. Jetzt haben wir hier nur einen Konflikt. Wenn wir mehrere Konflikte haben, müssen wir sie alle lösen. Danach schreiben wir einfach git rebase, dash und setzen den Rebase-Prozess für den nächsten Zweigkometen fort Rebase-Prozess für den nächsten Zweigkometen Wenn es beim nächsten Commit ebenfalls Konflikte gibt, lösen wir sie erneut und führen erneut diesen Befehl git rebase, Wir machen weiter, bis alle unsere Konflikte gelöst sind. Wenn wir also für einige Amide die Konflikte überspringen wollen, dann können wir hier eine andere Option verwenden, Dash Dash Kip Dadurch wird der aktuelle Konflikt unserer Amid übersprungen. wir zum Beispiel einen Konflikt bekommen und diesen Konflikt nicht lösen wollen, dann verwenden wir hier Skip. Außerdem haben wir eine weitere Option, nämlich Dash About für den Rebase-Prozess, ohne die Konflikte zu lösen Das ist sehr nützlich, da wir so viele Konflikte haben und wir sie hier nicht lösen wollen In dieser Situation können wir also über diesen Rebase-Prozess sprechen. Siehst du, wir haben unseren Rebase-Prozess abgeschlossen. Jetzt führen wir hier kein Rebasing durch, weil es derselbe Prozess ist, den wir in der vorherigen Lektion gesehen haben Und ein weiterer Grund ist, dass wir unterschiedliche Zweige haben , die wir in der nächsten Lektion benötigen Deshalb habe ich diesen Rebase-Prozess übernommen. Wenn Sie ein Rebase durchführen möchten, können Sie das tun. In der nächsten Lektion müssen Sie jedoch unterschiedliche Zweige erstellen. Wie Sie also sehen können, schreibt Rebase buchstäblich die Geschichte neu Aus diesem Grund sollten Sie Rebasing bei lokalen Projekten verwenden. 59. Kirschpflücktechnik: Hier ist unsere Cate-Geschichte. Nehmen wir an, wir haben wie im WigberGoth-Zweig A eins und A. Jetzt wollen wir hier den gesamten Evan Camt kopieren und ihn zu unserem Hauptzweig oder einem anderen Zweig hinzufügen unserem Hauptzweig oder einem anderen Zweig Man könnte sagen, wir können diese beiden Zweige zusammenführen, aber hier Unsere Filiale in Fixburgoth ist noch nicht bereit, zusammenzuführen. In der Filiale in Wigberg Slash Oth haben wir noch einiges zu tun. Zu diesem Zeitpunkt werden wir eine Technik verwenden, die als Cherry Peg bezeichnet Wenn wir eine ganze Keimzelle von einem Zweig in einen anderen kopieren wollen , verwenden wir die Technik des Rosinenpflückens Hier in unserem Projekt können wir sehen, dass wir unseren Master-Zweig und wir haben einen FigburGoth-Zweig Zur besseren Veranschaulichung werden wir eine weitere Gamete im Auth-Zweig erstellen Derzeit sind wir in der Filiale Wix per South. Im VS-Code in der Datei scrip dot js fügen wir einfach eine weitere Konsolenzeile schreiben Änderungen für den zweiten Commit für FixBugot Diese Änderungen spielen keine Rolle , da wir nicht an dem eigentlichen Projekt arbeiten Hier besteht unser primäres Ziel darin, Git zu lernen, die Änderungen zu speichern und zu unserem Terminal zurückzukehren. Lasst uns gemeinsam inszenieren und uns engagieren. Gate AM behebt den Auth-Bug in der Scrape-Dot-JS-Datei. Jetzt wundern Sie sich vielleicht, warum ich diesen Befehl zusammen verwende und warum ich ihn manchmal getrennt verwende Der einzelne Befehl wird nur ausgeführt, wenn wir Updates haben. Wenn wir eine neue Datei hinzufügen, müssen wir diese Datei zuerst müssen wir diese Datei und dann müssen wir sie festschreiben. Gut. Sehen wir uns jetzt die Geschichte noch einmal an. Sehen Sie in dem einen Zweig, wir haben zwei Gameten und hier haben wir einen Gameten im Hauptzweig Lassen Sie uns nun das erste Mal die Kirsche herauspicken. Dieser Commit hat also den, den wir kopieren wollen. Für mich ist es e67 90d4, wo wir diesen Commit hinzufügen wollen, wir brauchen diese Commit-Kopie in unserem Zunächst wechseln wir in den Master-Branch. Jetzt schreiben wir es Cherry Pik hier schreiben wir unseren Commit , den wir kopieren wollen Siehst du, hier bekommen wir Konflikte, und deshalb habe ich dir in der vorherigen Lektion gesagt, dass du den Konflikt nicht lösen sollst, und wir können auch sehen, dass wir gerade dabei sind, die Kirschen herauszupicken Wenn wir einen Konflikt haben, gehen wir einfach zum VS-Code und lösen den Konflikt. Hier akzeptieren wir eingehende Änderungen. Speichern Sie diese Datei und kehren Sie zum Terminal zurück. Hier überprüfen wir unseren aktuellen Status. Sehen Sie hier, dass wir den zusammengeführten Pfad erhalten. Also müssen wir unsere Änderungen in die richtige Reihenfolge bringen, bis wir Zeit hinzufügen. Und jetzt lassen Sie uns noch einmal den Status überprüfen. Sehen Sie, der nicht zusammengeführte Pfad ist weg. Jetzt können wir also einen Commit, Gate, Commit und die Eingabetaste drücken Per Code öffnen und hier schreiben wir eine Commit-Nachricht. Am Ende schreibe ich einfach eine Kopie, damit wir uns schnell identifizieren können. Schauen wir uns unsere Amet-Geschichte an. Siehst du, hier bekommen wir das neue Exemplar von Kamet und unsere Filiale ist immer noch dieselbe wie zuvor Also kopieren wir die Änderungen dieses Ameets, ohne Fibergoth-Zweig in unserem Master-Branch zusammenzuführen Lassen Sie mich Ihnen nun erklären, warum diese Technik als Rosinenpicken bezeichnet wurde . Der Name Cherry Picking spiegelt also den selektiven Charakter dieses Prozesses wider. Wenn Sie also einen Kirschbaum an dem Baum sehen, haben wir viele Kirschen. Aber um die Süßkirsche zu essen, müssen wir eine bestimmte Kirsche vom Baum auswählen, und dann können wir die Kirsche genießen. Mein Mund füllt sich mit Wasser. Jetzt, wo wir in Git eine bestimmte Kirsche vom Kirschbaum pflücken , haben wir Mitre und wir suchen uns bestimmtes Commit aus und nutzen den Vorteil dieses Commit Genauso wie wir Kirschen pflücken. Deshalb hat Git diese Technik auch „ Cherry-Picking-Technik“ genannt . Ich hoffe dir gefällt das. Wir sehen uns in der nächsten Lektion. 60. Eine bestimmte Datei zu einem anderen Zweig hinzufügen: Denken Sie beim Rosinenpflücken daran, dass wir den gesamten Amet kopieren Aber was ist, wenn wir nur eine bestimmte Datei vom Kami kopieren wollen eine bestimmte Datei vom Kami Also hier, wie wir das machen können. Derzeit befinden wir uns also im Master-Zweig, und wenn wir uns unsere Skript-Punkt-JS-Datei ansehen, dann bekommen wir hier nur zwei Konsolenzeilen. Wenn wir nun zum FXBurgoth-Zweig wechseln und sehen, dass wir in unserer Skript-Punkt-JS-Datei zwei Konsolenzeilen erhalten Jetzt wollen wir diese Punkt-JS-Datei des Skripts aus der FXBurgothBranch kopieren und sie unserem Master-Branch hinzufügen und Wir wechseln wieder zum Master-Branch zurück, weil wir die Datei in den Master-Branch hinzufügen wollen Hier schreiben wir Git, stellen den Quellcode wieder her und hier schreiben wir unseren Markennamen, und hier schreiben wir von dem wir die Datei kopieren wollen, nämlich Vicksburg oth Danach schreiben wir unseren Dateipfad, den wir kopieren wollen Wir schreiben Js-Skript dot js. Stellen Sie sicher, dass Sie den Dateipfad schreiben, nicht nur das Skript dot js. Andernfalls erhalten Sie eine Fehlermeldung. Hier können wir unseren Dateinamen auch mit einem doppelten Bindestrich vom Befehl trennen . Das haben wir schon gesehen. Denken Sie daran, dass wir hier sagen, dass Sie die Datei mit dem Punkt JS, die neueste Version, aus dem WIGberGoth-Zweig kopieren neueste Version, aus dem WIGberGoth-Zweig und in unseren aktuellen Master-Branch einfügen Wenn wir nun unsere Punkt-JS-Datei im Skript überprüfen, erhalten wir hier zwei Konsolenzeilen, die identisch sind Jetzt können wir die Chins bereitstellen und wenn Sie einen Commit durchführen möchten, können wir auch Auf diese Weise können wir eine bestimmte Datei von einem Zweig in einen anderen kopieren eine bestimmte Datei von einem Zweig in einen anderen 61. Verzweigung und Zusammenführung in VS-Code: Sehen wir uns nun die Funktion zum Verzweigen und Zusammenführen in unserem VS-Code an. Als Erstes möchte ich klarstellen, dass VS-Code nicht alle Funktionen hat, was wir mit Git-Befehlen tun. Schauen wir uns also an, was wir in VSCode haben. Öffnen Sie die Quellcodeverwaltung. Hier bekommen wir unsere Stage- und Stage-Dateien. Das haben wir schon gesehen. Jetzt haben wir hier unten, nach der Ankunft, eine Sektion mit Filialen. Hier können wir alle unsere Filialen sehen. Wir haben Master Fix BouGot und wir haben einen Feature-Branch-Ordner Jetzt fragen Sie sich vielleicht, wir haben diesen Feature-Ordner nicht erstellt. Wer hat ihn dann erstellt? Lassen Sie mich Ihnen sagen, dass wir dies erstellen , weil wir einen Schrägstrich im Zweignamen verwenden, und für alle Feature-Branches verwenden wir den Feature-Slash im Zweignamen Deshalb finden wir hier den Feature-Ordner. Wenn wir mehr als eine Filiale mit Fix Berg haben, dann bekommen wir hier auch den Fix Berg-Ordner. Jetzt können wir hier sehen, dass wir uns derzeit im Master-Zweig befinden , weil wir hier Tick Mark haben. Außerdem können wir von hier aus die Filiale wechseln. Außerdem können wir von hier aus einen neuen Zweig erstellen. Außerdem haben wir den Zweig als Liste anzeigen und einige weitere Optionen. Wenn wir nun auf einen Zweig klicken, wir hier die Option vergleichen. Wählen Sie die aus, und hier schreiben wir unseren Markennamen , den wir vergleichen möchten. Sagen wir PisBurgot. Sehen Sie sich jetzt an, dass diese Option in ein Dropdown umgewandelt wurde. Wir können hier Dateien sehen, die geändert oder beeinflusst wurden. Derzeit haben wir hier keine Datei, aber wenn wir Dateien haben, , indem wir sie anklicken können wir die Änderungen sehen, indem wir sie anklicken. Lassen Sie mich Ihnen nun zeigen, wie wir die Zusammenführung durchführen können. Klicken Sie mit der rechten Maustaste auf Fix Burg Oth branch und wählen Sie In aktuelle Filiale zusammenführen. Hier stehen uns viele Optionen zum Zusammenführen zur Verfügung. Zuerst haben wir Merge, das ist der einfache Merge-Befehl wie Git Merge und Branch Name. Danach haben wir Fast Forward Merge. Hier können wir sehen, dass wir nur Schnellvorlauf haben. Damit sagen wir Gangart, wenn möglich, nur Fast Forward Merge verwenden Andernfalls lassen Sie es so, wie es ist, ohne Merge. Als nächstes haben wir Squash Merge, dann haben wir kein Fast-Forward-Merge, und endlich haben wir es ohne Fast Forward und ohne Commit, oder wir können auch abbrechen oder fast demerge Wählen wir einfach die Standardzusammenführung, schließen diese Commit-Nachrichtendatei und sehen, wie die Zusammenführung abgeschlossen Wenn wir nun unsere Amide sehen, dann kommen wir hier Merge Commit Wenn wir nun Leak auf den vorherigen Camt schreiben , bekommen wir hier die Option Revert. Hier wählen wir Simple Revert und sehen hier, dass wir die Revert-Turn bekommen Jetzt können wir auch unseren Camt zurücksetzen . Hier haben wir ein paar Optionen, Soft, Hard Lassen Sie uns das vorerst stornieren. Wie wir sehen können, ist diese Quellcodeverwaltung für Branches sehr verwirrend. Ich verwende diese Quellcodeverwaltung kaum für Filialen. Für Branches haben wir die Git Lens-Erweiterung installiert, die ein großartiges Tool ist. Klicken Sie hier auf das Git Lens-Symbol. Hier erhalten wir zunächst das Commit-Grafiksymbol. Klicken Sie darauf und sehen Sie, hier haben wir das Commit-Diagramm. Um das besser zu sehen, schließe ich diese Git-Lens-Erweiterung und schließe alle Dateien von oben und klicke auf die Option „Im Editor-Bereich öffnen“. Lassen Sie uns das Terminalfenster schließen. Sehen Sie, diese Grafik sieht klarer aus. Siehst du, zu Beginn dieses Projekts hatten wir eine lineare Geschichte. Dann erstellen wir unser Feedback zu den Branch-Features und führen sie dann mit dem Master-Branch zusammen. Danach erstellen wir einen weiteren Zweig und führen sie erneut im Master zusammen. Jetzt oben können wir hier sehen, dass wir eine Filiale haben. Wenn wir nun auf einen Zweig klicken, haben wir ein paar Optionen. Zuerst haben wir zu einem anderen Zweig gewechselt, Änderungen zurückgesetzt, den Zweig umbenannt, einen Zweig erstellt, ein Tag erstellt usw. Lassen Sie uns jetzt hier einen neuen Zweig erstellen. Geben Sie den Namen der Filiale ein. Nehmen wir an, Vicksburg Slash Registration. Drücken Sie die Eingabetaste, und hier haben wir drei Optionen. Erstellen Sie einen Zweig, erstellen und wechseln Sie und stornieren Sie. Also wählen wir Erstellen und wechseln. Öffnen wir nun eine Datei, drücken Strg plus P oder Befehl plus P und öffnen Sie die JS-Datei mit dem Punkt Hier nehmen wir einige Änderungen vor. Speichern Sie diese Datei und lassen Sie uns diese Änderungen übernehmen. Gehen Sie also zur Quellcodeverwaltung. Und hier schreiben wir unsere Commit-Nachricht. Nehmen wir an, wir arbeiten an der Registrierung für Fix Berg und fertig. Gehen wir nun zurück zum Commit-Diagramm. Hier können wir sehen unser derzeit aktiver Zweig FixBurglargistration ist, und wir haben Wenn wir nun mit der rechten Maustaste auf den Master-Branch klicken, erhalten wir hier weitere Optionen, wir wechseln zum Branch, führen mit dem aktuellen Branch zusammen, rebasen, umbenennen rebasen, umbenennen Siehst du, hier bekommen wir dieselben Optionen, die wir in der Quellcodeverwaltung haben In der nächsten Lektion werden wir sehen, wie wir in Github DeskTrapablication Zweige sehen und zusammenführen können in Github DeskTrapablication Zweige sehen und zusammenführen 62. Verzweigung und Zusammenführung in Github Desktop: Wie wir wissen, haben wir für grafische Benutzeroberflächen zwei Anwendungen. Der erste ist Github Desktop und der zweite ist Kraken. Wenn Sie sicher sind, dass Sie es Kraken verwenden möchten, können Sie diese Lektion überspringen und direkt zur Git Kraken-Lektion übergehen Hier ist die Oberfläche der Github-Desktop-Anwendung. Nun zu den Filialen haben wir hier eine Liste der Filialen. Sehen Sie, hier können wir unsere aktuelle Filiale sehen. nun die Filialen zu wechseln, müssen wir einfach auf diesen Zweig klicken. Siehst du, unsere Filialen haben sich geändert. Hier oben haben wir die Möglichkeit, einen neuen Zweig zu erstellen, was sehr einfach ist. Jetzt haben wir hier unten die Option, den Chooser-Branch mit dem Master-Branch zusammenzuführen Wählen wir das aus und hier müssen wir den Zweig auswählen, den wir zusammenführen möchten Sagen wir FixburgRegistration, das wir in unserer vorherigen Lektion erstellt haben Klicken Sie auf FixburgRegistration. Wählen wir Rate Merge Camt aus. Wenn wir einen Konflikt haben, können wir ihn anhand des VS-Codes lösen und dann die Zusammenführung fortsetzen Hier erhalten wir die Meldung, dass die Zusammenführung erfolgreich war, und wenn wir unseren Commit-Verlauf überprüfen, können Sie den Merge-Commit sehen. Wenn wir nun auf weitere Verzweigungsoptionen zugreifen möchten, haben wir dieses Zweigmenü. Hier können wir einen neuen Zweig erstellen, umbenennen, löschen, vergleichen, mit dem aktuellen Zweig zusammenführen, Squash Merge, Rebase usw. Lassen Sie mich Ihnen jetzt einen Vergleich zeigen. Also wie im Vergleich zur Branche, und hier haben wir Vergleichsoptionen. Aber wie du hier sehen kannst, können wir den Commit-Verlauf bei Branches nicht richtig sehen. Aus diesem Grund mögen viele Entwickler Gitub Desktop nicht. Wenn Ihnen der Gitub-Desktop gefällt, können Sie den VS-Code-Commit-Verlauf verwenden , um sich die Commits und den Branch anzusehen, und dann das Merge Tool in der Github-Desktop-Anwendung verwenden Merge Tool Das ist die bessere Option. Letztlich liegt die Wahl bei Ihnen. 63. Zweig und Zusammenführung in GitKraken: Lassen Sie uns nun die Anwendung Git Kraken öffnen. Das Geschichtsstrafrecht liegt mir immer noch am Herzen. Schau, wie schön es aussieht. Wir können die Branches und den Commit-Verlauf deutlich besser erkennen als mit dem VS-Code oder der Github-Desktop-Anwendung. Sehen Sie, hier haben wir ein klares Diagramm für Zweige, das wir leicht verstehen können. Oben sehen wir eine Liste der Filialen. Und wenn wir einen Zweig auswählen, können wir zu diesem Zweig wechseln. Sehr einfach. Lassen Sie mich Ihnen zeigen, wie wir eine neue Filiale erstellen können. Klicken Sie mit der rechten Maustaste auf den Zweig und hier haben wir eine Reihe von Optionen. Wählen wir Neuen Zweig erstellen aus. Hier geben wir den Namen der Filiale an. Sagen wir Feature Slash Log Out. Hier können wir sehen, dass wir Auto Switch zu diesem Zweig bekommen. Lass uns jetzt ein paar Amas in diesem Zweig machen. Zurück zum VS-Code, OpenScript, Punkt, Sple und ganz einfach. Endlich implementieren wir bei Console Dot Log die Logout-Funktion Die Änderungen und lassen Sie uns diese Änderungen übernehmen. Geben Sie die Commit-Nachricht ein. Nehmen wir an, implementieren Sie die Abmeldefunktion und übernehmen Sie sie. Kurzer Tipp hier: Wenn wir den aktuell aktiven Zweig sehen wollen, können wir das von hier aus im VS-Code sehen Auch von hier aus können wir zum anderen Zweig wechseln. Zurück zum Master-Zweig, und hier erstellen wir auch das Const Dot Log und fügen Updates in die Dot-JS-Datei des Skripts Lassen Sie uns auch mit der Nachricht bestätigen und GS-Datei des Skripts aktualisieren Wisst ihr, das ist keine gute Commit-Nachricht, aber das ist nur als Demo. Nun zurück zu Kraken und wir können sehen, wie Branch divergiert nun vor der Zusammenführung sehen, Lassen Sie uns nun vor der Zusammenführung sehen, wie wir zwei Zweige vergleichen können Wählen Sie den Abmeldezweig aus und halten Sie ihn sicher. Und wählen Sie den anderen Zweig aus, der Master ist. Sehen Sie auf der rechten Seite, wir haben den Unterschied zwischen zwei Zweigen, und darunter haben wir eine Liste der Dateien, die betroffen sind. Wenn wir die Datei auswählen, wird die Datei mit den Änderungen geöffnet. Ich ändere hier absichtlich dieselbe Zeile, sodass in Zeile drei ein Konflikt entsteht und wir die Zusammenführung durchführen. Wählen Sie den Master-Zweig und das rechte Bein des Abmeldezweigs aus , den wir zusammenführen möchten Hier haben wir Merge und wir haben auch Rebase Wählen wir Merge. Siehst du, hier haben wir Konflikte, und hier bekommen wir alle Dateien, die in Konflikt Wir wählen die JS-Datei Script Dot und hier bekommen wir dieses wunderschöne Merge-Tool Hier auf der linken Seite haben wir Änderungen vom Master und auf der rechten Seite haben wir Änderungen vom Logout-Zweig, und unten haben wir die endgültige Ausgabe Hier können wir die Zweige auswählen, indem wir das Kontrollkästchen aktivieren, und wir können auch beide auswählen Wir können sie auch von hier entfernen, und wenn wir mehr als einen Konflikt haben, können wir sie von hier aus mit dem Aufwärts- und Abwärtspfeil sehen. Wenn wir nun mit unseren Konflikten zufrieden sind, speichern wir die Änderungen einfach von hier aus. Jetzt haben wir auf der rechten Seite eine Liste der Staging-Dateien. Wir haben auch eine Commit-Nachricht bereit. Jetzt haben wir hier zwei Optionen, Comte und Merge, und kurz vor der Zusammenführung Gehen wir zu Commit and Merge. Sehen Sie hier oben, wir bekommen T Merge Comte Sehr einfach und leicht. Stellen Sie sich nun vor, wir erhalten durch diese Zusammenführung einen Fehler in unserem Code. Wir können unseren Commit auch rückgängig machen oder auf eine neue Basis setzen. Klicken Sie mit der rechten Maustaste auf Commit und wählen Sie die Option Commit rückgängig machen. Wir bitten Sie um eine Bestätigung für Sofort-Kat. Wir wählen ja, C, hier bekommen wir Revert Kumt Nun, wenn du das Amid auf diese Amid zurücksetzen willst , bevor wir zusammenführen, dann können wir schreiben, klicken Sie hier und wählen Hier haben wir drei Optionen: weich, gemischt und hart. Das haben wir schon richtig gesehen. Jetzt ist hier eine Sache. Stellen Sie sich vor, Sie haben die Git-Befehle nicht gelernt, bevor Git Kraken oder eine andere grafische Benutzeroberfläche verwenden, dann werden Sie definitiv in einen verwirrenden Zustand geraten Deshalb entscheide ich mich, dir zuerst Git-Befehle und dann grafische Benutzeroberflächen wie Git up Desktop und Git Cracon beizubringen dann grafische Benutzeroberflächen wie Git up Desktop und Git Cracon Hier machen wir einen Hard-Reset und unsere Befehle zum Zusammenführen und Zurücksetzen sind So können wir mit Branches und Merging im Git Kraken arbeiten Branches und Merging im Git Ich weiß, dass dieser Abschnitt etwas länger ist, aber das sind alles sehr wichtige Merge-Lektionen Du hast also einen tollen Job gemacht. Gönnen Sie sich etwas Leckeres, hören Sie Musik, spielen Sie ein paar Spiele oder machen Sie einen frischen Spaziergang. Wir werden unsere Reise in Sachen Kit-Meisterschaft im nächsten Abschnitt fortsetzen Kit-Meisterschaft im nächsten Abschnitt Wir sehen uns also im nächsten Abschnitt. 64. Abschnitt 05 Arbeiten mit dem Team: Willkommen im fünften Abschnitt des ultimativen Kit-Kurses. In diesem Abschnitt werden wir sehen, wie wir mit Git im Team arbeiten können. Derzeit ist unser Repository in unserer lokalen Umgebung, aber in der realen Welt müssen wir am Repository in der Cloud arbeiten. Sie fragen sich vielleicht, wie wir mit anderen Teammitgliedern in einem Unternehmen zusammenarbeiten können ? Wir haben gelernt, wie wir Änderungen von anderen Teammitgliedern abrufen , unsere Änderungen veröffentlichen, Anfragen und Probleme abrufen und vieles mehr Ich weiß, dass Sie sich auf diesen Abschnitt freuen, und ich freue mich auch darauf Lassen Sie uns also, ohne Zeit zu verschwenden, verstehen, wie wir mit Git im Team an einem einzelnen Projekt arbeiten 65. Übersicht über die Arbeit im Team: Wie ich Ihnen bereits sagte, arbeiten wir bis jetzt nur vor Ort. Aber in der realen Welt arbeiten wir nicht alleine. Es gibt viele Entwickler, die an einem einzigen Projekt arbeiten, und deshalb werden wir uns die Vogelperspektive ansehen, wie Entwickler damit an demselben Projekt zusammenarbeiten. Lassen Sie mich Ihnen also eine einfache Frage stellen. Hier ist unser Repository. Wie können Ihrer Meinung nach andere Teammitglieder mit diesem Repository arbeiten? Eine Lösung besteht darin, dass wir dieses Repository irgendwo auf einem Server hosten und alle Entwickler an dem einzigen Repository arbeiten. Dies wird als zentralisiertes Personenkontrollsystem bezeichnet. Was ist nun, wenn dieser Server, auf dem wir unser Repository hatten , offline geht oder in die Wartung geht? Dann müssen sich alle Entwickler hinsetzen und darauf warten, dass der Server nicht mehr gewartet wird. Dieser Ansatz funktioniert nicht richtig. Jetzt gibt es für jeden Entwickler eine andere Lösung Wir geben ihm ein Repository auf seinem eigenen PC oder Laptop. Sie sind von keinem Server abhängig. Sie können jederzeit an ihrem Repository arbeiten. Dies wird als verteiltes Vers- und Kontrollsystem bezeichnet, und Git ist das Beispiel für dieses verteilte Vs - und Kontrollsystem. Nun fragen Sie sich vielleicht, ob alle Entwickler an ihrem eigenen System arbeiten, wie können sie dann mit Teammitgliedern zusammenarbeiten? Für die Arbeit im Team halten wir ein zentrales Repository alle Entwickler fest. Alle Entwickler haben ihr eigenes Repository, aber wir haben auch ein zentrales Repository , das sie für die Zusammenarbeit verwenden. Lassen Sie mich Ihnen das anhand eines Beispiels aus der Praxis erklären. Angenommen, das bist du und das bin ich. Hier arbeiten wir an demselben Projekt, das, sagen wir, eine E-Commerce-Anwendung ist. Jetzt werden wir zunächst unser bestehendes Projekt für uns beide in unserem persönlichen System klonen unser bestehendes Projekt für . Nehmen wir nun an, Sie arbeiten an Ihrer Aufgabe, machen ein paar Kameras und wenn Sie bereit sind, übertragen Sie diese Änderungen in dieses Repository. Jetzt haben wir Updates im Projektarchiv, also werde ich darüber informiert. Ich öffne dieses Repository und ziehe die Änderungen in mein System. Jetzt sind mein Code und der Code dieses Repositorys identisch. Aber stell dir vor, ich bekomme hier einen Konflikt. Ich löse den Konflikt hier auf meinem Computer und schiebe dann meinen Code in dieses Repository. Jetzt können andere Entwickler und Sie diesen aktualisierten Code abrufen und weiter an diesem Projekt arbeiten. Dies wird als zentralisierter Workflow bezeichnet und natürlich müssen Sie diesem zentralisierten Workflow folgen. Lass dich nicht verwirren. Der zentralisierte Arbeitsablauf und das zentralisierte Vers - und Kontrollsystem sind nicht dasselbe. Es sind verschiedene Dinge, nur die Namen sind ähnlich. Verfolgen Sie diese zentralisierte Arbeit Jetzt verwenden einige Unternehmen ihren eigenen privaten Server, verwenden einige Unternehmen ihren eigenen privaten Server um dieses Repository in ihrem Unternehmen zu hosten, aber die Wartung eines eigenen Servers ist für neue Unternehmen wenig kostspielig. Neue Unternehmen verwenden daher gerne einen Cloud-basierten Server, auf dem ihr Repository privat gehostet werden kann. Dies ist eine günstige und gute Option für neue Unternehmen und Startups. Es gibt viele Unternehmen , die diese Art von Cloud-Diensten für das Hosten von Repositorys anbieten , und Sie erraten das Richtige. Github ist eine der Repository-Hosting-Plattformen. Wir haben auch Gitlab, Bitbucket, GIT und viele mehr Aber wir alle wissen, dass Github eine der beliebtesten Plattformen ist, also werden wir Github verwenden Sie verwenden eine andere Hosting-Plattform. Sie können diesen Kurs trotzdem fortsetzen, Sie können diesen Kurs trotzdem fortsetzen da wir über die Arbeit im Team sprechen. Es ist wirklich egal, welche Hosting-Plattform Sie verwenden. Was auch immer Sie auf Github tun, ich denke, alle Grundlagen können Sie einer anderen Repository-Hosting-Plattform erledigen. Was ist nun, wenn Sie ganz alleine arbeiten? In dieser Situation können Sie Gitub auch verwenden, um unseren Code als Backup zu speichern Sogar 20 bis 40% der Entwickler verwenden Gitub, um ihre Zeilen zu speichern und ihren Lebenslauf zu verwalten In Zukunft haben sie ihren Code nicht verloren. Es wird auch in ihrem Github-Konto verfügbar sein. Es ist von Vorteil für Sie, dies zu lernen. In der nächsten Lektion werden wir sehen, wie dieser Arbeitsablauf abläuft. Ich freue mich sehr darüber. 66. So lädst du ein Projekt auf github hoch: Bevor wir anfangen, ein neues Repository zu erstellen, fragen mich viele Studierende, wie kann ich unser bestehendes Git-Projekt auf Github hochladen? Lass mich dir zeigen, wie wir lokale Projekte auf Github hochladen können . Zuerst werden wir sehen, wie Projekte mit Github Desktop hochgeladen werden, und danach werde ich es Ihnen für Gate Cracon zeigen Also öffne ich zuerst Github Desktop hier, zuerst überprüfen wir, ob unser Repository Wenn es in dieser Liste nicht verfügbar ist, gehen wir zu der Datei im lokalen Repository und suchen einfach nach diesem Ordner und öffnen unser Projekt hier. Wenn wir jetzt keine Änderungen haben, erhalten wir hier die Option „Repository direkt veröffentlichen“. Ansonsten haben wir auch diese Option hier nach der Verzweigung. Hier können wir sehen, dass dieses Repository nur auf Ihrem lokalen Computer verfügbar ist. Indem Sie es auf GitHub veröffentlichen, können Sie es teilen und mit anderen zusammenarbeiten. Klicken Sie also auf diese Schaltfläche für das öffentliche Repository. Wir werden dieses Pop-up bekommen, das nach dem Namen des Repositorys fragt. Ich gebe ihm Tas Track für Git. Wenn du eine Beschreibung schreiben möchtest, kannst du sie hier schreiben. Von hier aus können wir unser Repository privat oder öffentlich machen. Wenn wir unser Repositorium zur Republik machen, kann sich jeder im Internet unseren Code ansehen. Eine Sache ist, wenn Sie mit anderen zusammenarbeiten wollen , müssen wir unser Repository veröffentlichen. Wenn wir es privat machen, müssen wir für ein privates Repository für die Zusammenarbeit bezahlen . Wenn Sie nur Code speichern möchten, können wir ein privates Repository verwenden. Ich deaktiviere dieses Kästchen für das öffentliche Repository und klicke einfach auf veröffentlicht Sieh es dir an, es zu veröffentlichen. Wenn du das verifizieren möchtest, können wir mit dieser Schaltfläche unser Repository auf Github überprüfen . So einfach ist es. Lassen Sie mich Ihnen nun zeigen, wie wir dasselbe mit der Anwendung Git Kraken tun können dasselbe mit der Anwendung Git Kraken Öffnen Sie die Git Kraken-Anwendung und wählen Sie unser Repository aus , das Sie veröffentlichen möchten Bevor wir das Repository veröffentlichen, müssen wir nun unser Github-Konto mit der Get Kraken-Anwendung verbinden Github-Konto mit der Get Kraken-Anwendung Klicken Sie also von hier aus auf diese Einstellungsschaltfläche und wechseln Sie zur Registerkarte Integration Hier haben wir ein paar Hosting-Dienste, standardmäßig ist Sec Github und hier sehen Sie, dass wir keine Verbindung herstellen. Lass uns eine Verbindung zu Github herstellen. Sie werden aufgefordert, sich mit Ihrem Github-Konto anzumelden. Ich melde mich mit meinem Konto an. Wir werden aufgefordert, uns anzumelden oder zu autorisieren. Ich autorisiere und hier schreibe ich mein Passwort und öffne es einfach Crack und Anwendung Schau hier bekommen wir unseren Account. Lassen Sie uns nun diese Einstellungen schließen. Wir brauchen es nicht. Um nun ein Repository zu veröffentlichen, müssen wir zuerst Remote hinzufügen, auf dieses Cloud-Symbol klicken, das für Remote steht, und hier können wir sehen, dass wir keine Remote haben. So können wir neue erstellen. Hier können wir sehen, dass wir Github ausgewählt haben, und es fragt nach dem Namen des Repositorys, dem Remote-Namen, den wir in dieser Remote-Liste sehen, und der Beschreibung des Repositorys . Wir können es auch öffentlich oder privat machen. Keine Sorge, klicken Sie einfach auf Create remote und drücken Sie auf Local Revs Und dann erhalten wir eine Erfolgsmeldung. Das können wir uns auch auf github.com ansehen. Das sieht ein bisschen kompliziert , weil wir alle unsere Camts auf einmal pushen Aber in der realen Welt erstellen wir zuerst unser Repository und arbeiten dann daran. Also mach dir darüber keine Sorgen. In der nächsten Lektion werden wir nun mithilfe der Github-Website ein neues neues Repository erstellen und die Abschnittskonzepte in ihrem Repository kennenlernen . Damit Sie sich von diesem Masterprojekt nicht verwirren lassen. 67. So erstellt man ein neues Projekt auf github: Öffnen Sie also github.com, und wenn Sie kein Github-Konto haben, können Sie ganz einfach ein neues Konto erstellen Es ist wirklich einfach und unkompliziert. außerdem sicher, dass Sie Ihr E-Mail-Konto verifizieren , bevor Sie ein neues Repository erstellen. Ich habe mich hier bereits mit meinem Konto angemeldet. Um nun ein neues Repository zu erstellen, klicken Sie auf dieses Plus-Symbol. Hier haben wir ein neues Repository, und wir können das Repository auch von einem anderen Ort importieren. Lass uns nach einem neuen Repository suchen. Hier geben wir zuerst unseren Repository-Namen ein , den wir angeben möchten. Nehmen wir an, CardWishGT, weil ich das Cardwisname-Repository Jetzt können wir hier eine Beschreibung dieses Repositorys schreiben . Als nächstes haben wir die Option öffentlich oder privat. Wie ich Ihnen bereits gesagt habe, müssen wir für die Arbeit im Team bezahlen, wenn wir privat wählen . Also wählen wir hier öffentlich aus. Jetzt haben wir hier ein paar Optionen. Sie können eine Ad-Me-Datei hinzufügen, in die wir eine lange Beschreibung für unser Projekt oder unsere Website schreiben können, und wir können auch die Datei Getting nor auswählen. Hier haben wir eine Liste von Sprachen. Im Moment wollen wir es nicht und klicken auf Create Repository. Und dann erstellen wir ein neues Repository. Hier oben können wir unseren Benutzernamen sehen und unseren Repository-Namen mit einem Schrägstrich Wenn dich jemand bittet, deinen Code zu sehen, kannst du ihm diese Github-URL geben Aber dafür brauchst du ein öffentliches Repository. Sonst werden die Leute es nicht sehen. Jetzt haben wir hier unsere Filialliste. Derzeit haben wir nur eine Filiale, nämlich die Hauptniederlassung. Dieser Hauptzweig ist derselbe wie unser Hauptzweig. Github hat Master Branch als Main bezeichnet. Danach haben wir die Anzahl der Filialen und wir erhalten auch die Anzahl der Tags. Hier können wir nach einer bestimmten Datei suchen. Außerdem können wir eine neue Datei erstellen und auch Dateien hochladen. In dieser quadratischen Box können wir jetzt unser Projekt sehen. Hier können wir unseren letzten Commit sehen. Jetzt fragst du dich vielleicht, wir haben nichts festgeschrieben. Dies ist der Commit, den Github für die Erstellung eines neuen Repositorys erstellt. Hier können wir sehen, dass Commit Zeit hat , wenn es festgeschrieben wurde und alle Commits. Lassen Sie uns das überprüfen Hier bekommen wir die Liste der Commits. Wir können es von hier aus nach Benutzern filtern und wir können es auch nach Zeit filtern Von hier aus können wir Commits nach Branches sortiert sehen, und wenn wir mehr Details zu Commit sehen wollen, können wir darauf klicken Hier bekommen wir den Zweig, der der Hauptzweig ist. Wir bekommen den Benutzernamen und wir bekommen auch die Zeit. Danach können wir die geänderte Datei mit zwei Hinzufügungen und keiner Löschung sehen und wir können diese Zeilen hier sehen. Gut. Zurück zu unserer Codepage. Hier erhalten wir die Liste der Projektdateien und auf der rechten Seite erhalten wir auch die Commit-Nachricht. In welchem Befehl wird diese Datei hinzugefügt oder geändert. Wir können den Inhalt der Datei auch von hier aus anzeigen. Es gibt eine kleine Einführung in das Github-Repository. In der nächsten Lektion werden wir nun sehen, wie wir Teammitglieder zu diesem Repository hinzufügen können. 68. Teammitglieder zum Projekt hinzufügen: Derzeit ist unser Repository öffentlich, aber immer noch kann niemand Commits in unser Repository pushen Du könntest sagen, dass wir unser Repository bereits öffentlich machen und trotzdem kann niemand Commits pushen Warum? Ein öffentliches Repository bedeutet, dass jeder unser Repository einsehen kann, aber wir müssen unsere Teammitglieder als Mitarbeiter zu diesem Repository hinzufügen als Mitarbeiter zu diesem Repository Hier gehen wir zur Einstellungsoption. Im Bereich „Zugriff“ finden Sie die Registerkarte „Mitarbeiter“ Hier können wir sehen, dass wir keine Mitwirkenden haben. Lassen Sie uns ein Teammitglied zu diesem Projekt hinzufügen. Hier fügen wir ein Mitglied und können das Konto von Teammitgliedern anhand des Benutzernamens, des vollständigen Namens oder des E-Mail-Kontos durchsuchen . Ich schreibe meinen zweiten Account. Dies ist mein neues Konto, das ich für diesen Kurs erstellt habe. Wenn ich Ihre Einladung nicht annehme, das leid, da ich wahrscheinlich in Zukunft nicht mehr auf dieses Konto zugreifen werde. Wenn du kein anderes Konto hast, kannst du ein zweites Konto für diesen Bereich erstellen oder deine Freunde einladen, oder deine Freunde einladen die ebenfalls Git lernen möchten. Auf diese Weise verstehst du diese Lektionen besser. Sehen Sie sich diesen Benutzer an und klicken Sie auf Zu diesem Repository hinzufügen. Hier haben wir einen Mitarbeiter, aber wie wir sehen können, steht die Einladung noch aus Wenn du jemanden zu deinem Repository hinzufügst, sendet Git dieser Person per E-Mail Anfragen zur Zusammenarbeit Wenn die Person die Einladung annimmt , dann herzlichen Glückwunsch. Sie haben einen Mitarbeiter. Diese Person hat aber auch die Möglichkeit, dies abzulehnen Auf diese Weise können wir Teammitglieder oder Mitarbeiter zu unserem Repository hinzufügen oder Mitarbeiter zu unserem Repository 69. Git-Repository in unserer Maschine klonen: Wie wir wissen, erstellen wir ein neues Repository von unserem Github-Konto aus. Aber wie können wir anfangen, an diesem Repository zu arbeiten? Weil wir dieses Repository nicht auf unserem Computer haben. Mal sehen, wie wir ein Repository von Github zu unserem Computer hinzufügen oder klonen können . Gehen Sie zur Code-Option und hier erhalten wir den Link unseres Repositorys auf Github. Kopieren Sie dies und öffnen den Ordner, in den Sie dieses Repository klonen möchten. Ich bin also in meinem Projektordner, öffne Gitwsh oder Terminal in diesem Hier schreiben wir einfach Gate, klonen und fügen unsere URL ein Wenn Sie Windows verwenden, funktioniert Control plus V nicht. Also klicken Sie mit der rechten Maustaste hier und sehen Sie, wir haben eine Seitenoption und wir haben auch eine Verknüpfung dafür. Wenn wir nun diesen Befehl ausführen, klonen wir dieses Repository mit dem Repository-Namen als Ordnernamen. Wenn Sie es ändern möchten, können wir das auch tun. Nehmen wir an, ich möchte nur Cartwish und drücke Enter. C, klone dieses Repository. Jetzt haben wir also alle Kometen, alle Zweige, buchstäblich alle Details über das Test-Repository Gehen wir in diesen Kartenordner. Also ändere das Verzeichnis zu Cartwis. Jetzt schauen wir uns die Mäntel an, also Git Log, Strich Pline, Strich alle, Strich Strich Graph Jetzt bekommen wir hier einen einzigen Befehl, nämlich den ersten Befehl. Hier können wir sehen, dass sich unser Kopfzeiger auf diesem Befehl befindet, aber wir haben hier noch zwei weitere Zeiger, Origin Main und Origin Head Wer hat das geschaffen und warum? Wie wir wissen, wird Headpointer verwendet, um zu wissen, auf welchem Commit wir uns befinden, und main ist unser Standard-Branch Wenn wir nun unser Projekt von GitHub klonen, erstellt Git einen Remote-Branch und benennt ihn als Origin Dies ist kein originaler Zweig. Das ist nur ein abgelegener Zweig. Wenn wir versuchen, zur Filiale zu wechseln, funktioniert das nicht. Wir können das auch mit Git Branch überprüfen. Sehen Sie hier, wir haben nur einen Hauptzweig. Lassen Sie mich Ihnen jetzt etwas Nützliches zeigen. Wenn wir Gate Remote schreiben, dann bekommen wir hier unser Remote-Repository, das Origin ist. Sie fragen sich vielleicht, was ist ein Remote-Repository? Ein Remote-Repository ist das Projekt oder Repository, das auf dem Server wie Github oder Beat Bucket gehostet wird. In einfachen Worten, ein Remote-Repository ist ein Repository, das sich nicht auf unserem lokalen Computer befindet. Unser aktuelles Repository befindet sich nicht nur auf unserem lokalen Computer, es wird auch an einem entfernten Ort wie auf Github gespeichert. Dieses Remote-Repository, das als Origin bezeichnet wird, wird zur Bereitstellung von Informationen über unser Github-Projekt verwendet . Zum Beispiel, an welcher Branche Entwickler gerade arbeiten und mehr. Aus diesem Grund erstellt Git nun zwei weitere Zeiger Origins main oder master und origins head Lass mich dir das anhand des Beispiels erklären. Angenommen, ich und Sie arbeiten an demselben Projekt und wir klonen beide unser Projekt von Github. Wenn wir nun unser Projekt von GitHub klonen, erstellt Git diese beiden Zeiger Origins Main und Origin Head Nehmen wir nun an, ich arbeite an einem Feature und schiebe die Cam in unser Repository Bewegen Sie diesen ursprünglichen Hauptzeiger auf den späten Treffpunkt im Hauptzweig. Origin Main wird uns also im Wesentlichen sagen, wo die neuesten Änderungen in unserem Github-Repository vorgenommen wurden. Wenn also jemand anderes einen weiteren Kometen erzeugt, der Ursprungszeiger auf diesen Kometen Ihr könntet sagen, ihr wisst von Origins Main, die die letzten Änderungen in unserem Projektarchiv repräsentieren Aber warum bewegt sich dieser Schrägstrich auch mit diesem Ursprung als Hauptteil Ehrlich gesagt bewegt es sich nicht. Es befindet sich in derselben Filiale. Origins Head wird verwendet , um uns mitzuteilen, welcher Zweig als letzter zur Kasse gegangen ist, oder, in einfachen Worten, welcher Zweig von einem Teammitglied zuletzt angesehen oder bearbeitet wurde. Nehmen wir an, wir haben hier diesen Seitenzweig mit Feature-Produkten. Wenn Sie ich oder ein anderer Entwickler sind zu einem der anderen Zweige wechseln, dann wird dieser ursprüngliche Leiter auf diesen Zweig verweisen. So funktioniert dieser Zeiger also. Zusammenfassend lässt sich sagen, dass nur der Kopfzeiger verwendet wird , um uns mitzuteilen, an welchem Commit wir gerade arbeiten Origin Min oder Origins Master sagen uns, wo die neuesten Änderungen in unserem Github-Repository Auf diese Weise können wir die neuesten Änderungen in unserem Github-Repository ermitteln. Origins HAD teilt uns mit, welche Branche von einem Teammitglied zuletzt angesehen oder bearbeitet wurde. Mach dir darüber keine Sorgen. Ihr alle Zweifel fühlt euch klar, wenn ihr das alles in Aktion seht. 70. Änderungen abrufen: Wie wir wissen, ist dies unser GitHub-Repository, und dies ist unser lokales Repository, das wir vom Github klonen Jetzt sind diese beiden Repositorien nicht miteinander verbunden Wenn also jemand die Änderungen in dieses Gitub-Repository einfügt , erhalten wir diese Commits nicht Wir müssen den Befehl Git fadge ausführen die neuen Commits in unser lokales Repository zu bekommen Hier müssen wir aufpassen. Derzeit arbeiten wir in unserem lokalen Repository am Kometen C One Unser Hauptzeiger, oder wir können sagen Hauptzeiger befindet sich immer noch auf diesem Kometen Aber wie ich Ihnen in der vorherigen Lektion gesagt habe, unser Quell-Hauptzeiger vorwärts , weil er die letzten Änderungen im Remote-Repository darstellt im Remote-Repository den Befehl Git patch verwenden, erhalten wir decommit, aber unser Master- oder Hauptzeiger befindet sich immer noch auf unserem C-One-Commit Wir erhalten also decommit in unserer Historie, aber unser Arbeitsverzeichnis ist immer noch nicht betroffen, und dadurch treten keine Konflikte Wenn Sie nun damit einverstanden sind, diese Änderungen auf Ihr Arbeitsverzeichnis anzuwenden , können wir git merge und diesen Zeigernamen ausführen , der origin Min ist Hier haben wir also keine verschiedenen Zweige. Welche Art von Zusammenführung führt Git durch. Absolut richtig. Git führt Pass-For oder Merge durch. Und wenn wir Konflikte bekommen, dann lösen wir sie so, wie wir es zuvor gelöst haben und dann fertig sind . Lassen Sie uns diesen Git-Patch praktisch sagen. In diesem Browser melde ich mich also mit meinem anderen Github-Konto an. Und in dieser Maschine habe ich mein ursprüngliches Konto, nämlich Gott segne dich. Hier haben wir nur meine Akte. Also lass uns diese Datei ändern und sie einfach festschreiben. Klicken Sie auf diese Datei und von hier aus können wir diese Datei bearbeiten und diesen Text ändern. Dies ist für den zweiten Commit und die Änderungen werden einfach übernommen. Hier können wir die Commit-Nachricht schreiben. Ich lasse es so wie es ist. Stellen Sie hier sicher, dass wir Commit to main branch auswählen. können wir von hier aus auch einen neuen Zweig erstellen diesem Commit können wir von hier aus auch einen neuen Zweig erstellen. Aber wir werden diese Option in der nächsten Lektion sehen. Klicken Sie einfach auf Commit. Nun zurück zu unserem Codefenster, sehen Sie, hier haben wir zwei Kometen Nun, wenn wir in unserem lokalen Repository sehen, dann bekommen wir hier nur einen Treffer. Lassen Sie uns nun sehen, wie wir das Repository aus unserem Remote-Repository abrufen können Repository aus unserem Remote-Repository Wir schreiben Git Fetch und dann schreiben wir unseren Remote-Namen, der origin ist Wir schreiben nichts, dann nimmt Git standardmäßig den Ursprung Siehst du, es patcht. Schauen wir uns jetzt unsere Geschichte an. Siehst du, wir kommen zu Kometen und wir können auch sehen, und wir können auch sehen der Ursprung und der Ursprung zu diesem Kometen bewegt werden, aber unser Kopf ist immer noch Schauen wir uns nun an, wie wir diese Änderungen in unser Arbeitsverzeichnis aufnehmen können diese Änderungen in unser Arbeitsverzeichnis Schlage vor, dass wir Git Merge schreiben und unseren Zeigernamen Origins Main schreiben. Und wir haben es getan. Sehen Sie hier, wir werden schnell zusammengeführt und wir können auch in unserer Historie sehen , dass der Headpointer zu unserem zweiten Befehl verschoben wurde und wir auch die IDM-Datei im VS-Code öffnen, dann erhalten wir die aktualisierte RDM-Datei 71. Die Änderungen ziehen: In der vorherigen Lektion haben wir gesehen, dass wir, um die neuesten Änderungen aus dem Remote-Repository abzurufen, den Befehl patch verwenden müssen und dann, um Änderungen in unser Arbeitsverzeichnis hinzuzufügen , müssen wir sie zusammenführen. Wie wir sehen können, handelt es sich dabei um einen zweistufigen Ansatz. Wir können das auch in einem einzigen Schritt tun, und wissen Sie, mit welchem Befehl es abgerufen wird? Angenommen, wir haben diese AMDs im lokalen Repository und im Remote-Repository Hier schreiben wir in unser lokales Repository ein und hier fügen andere Teammitglieder Amid ebenfalls zum Remote-Repository Wenn wir nun den Befehl git pool ausführen, fügt Git diesen Sit-Commit in unser lokales Repository ein und Origin Min Pointer wechselt zu diesem Amid. Nun füge Git diese beiden Änderungen zusammen und erstelle einen neuen Mantel. Viele Entwickler mögen diesen Ansatz nicht , weil wir sehen können , dass er ein neues Merge-Kamit erzeugt und wir auch unterschiedliche Befehle bekommen. Die andere Lösung: Anstatt Merge durchzuführen, können wir auch Rebasing durchführen Wir können also den Befehl git, pull, rebase ausführen, und das wird unser Komitee auf diesen ursprünglichen Schrägstrich als Haupt-Commit umbasieren , und so erhalten wir einen linearen und klaren Was ist nun die beste Option für Pull Merge oder Rebase? Ehrlich gesagt hängt das wirklich von unserer Situation ab. Höchstwahrscheinlich wird Ihnen Ihr Manager sagen, dass Sie Merge oder Rebase verwenden sollen. Machen Sie sich darüber keine Sorgen Ich persönlich verwende lieber Rebase statt Merge, weil unser Commit-Verlauf dann sauber bleibt Schauen wir uns das also in unserem Repository an. Für Pull-Requests müssen wir also zuerst einige Änderungen in unserem lokalen Repository sowie im Remote-Repository festschreiben. Also öffne ich unser lokales Repository im VS-Code und erstelle eine neue Datei, sagen wir, scrap dot js, genau hier, Console Dot Log Das ist eine gescrapte Datei. Speichern Sie die Änderungen, und lassen Sie uns diese Änderungen übernehmen. Zurück zu Git Bash it Ed Period, c Staging und Gitatm createscript c Staging und Gitatm createscript dot Jsfile for JavaScript. Schauen wir uns jetzt unsere Geschichte an. Siehst du, hier haben wir drei Camits und unser Kopf wird zu unserem letzten Amit bewegt und Origin Main und Origin Head immer noch in diesem Lassen Sie uns nun Cait in unserem Remote-Repository erstellen. Gehe zum zweiten Konto. Und hier erstelle ich von hier aus eine neue Datei, und hier schreiben wir unseren Dateinamen. Nehmen wir an, Pläne sind TxD. Physisch werde ich Pläne in diese Datei schreiben. Schritt Nummer eins: Erstellen Sie ein grundlegendes Website-Layout für dieses Projekt. Lassen Sie uns das nun festschreiben, also die Änderungen festschreiben. Ich lasse diese Commit-Nachricht unverändert und entscheide mich für Commit. Erledigt. Siehst du, hier haben wir drei Commits Jetzt zurück zu unserem Git Bash. Hier führen wir den Befehl git pull aus, sodass unser Remote-Repository-Commit zu unserem Projekt hinzugefügt und dann zusammengeführt wird unserem Projekt hinzugefügt und dann zusammengeführt wird Es wird nach einer Commit-Nachricht gefragt. Ich möchte es nicht ändern, also schließen Sie das. Siehst du, die Zusammenführung ist abgeschlossen. Schauen wir uns unsere Geschichte an. Siehst du, hier bekommen wir den Merge-Commit und auch die verschiedenen Mäntel. Lassen Sie mich Ihnen jetzt zeigen, wie wir mit Pull rebasen können. Lassen Sie uns vorher diesen Merge-Commit rückgängig machen. Also Git Reset, Dash Hard und wir wollen einen Schritt vor Kopf gehen. Also geh bis eins. Schau in unserer Geschichte nach. Siehst du, wir setzen unsere Zusammenführung und bekommen diesen separaten Zweig. Lassen Sie uns also Git Pull, Rebase ausführen. Im Grunde sagen wir Git, unser aktuelles Commit auf den ursprünglichen Hauptzeiger umzubauen und sehen, dass wir eine Erfolgsmeldung erhalten Schauen wir uns noch einmal unseren Verlauf an. Siehst du, wir haben eine lineare Geschichte, und dieser Ursprung ist der Umzug hierher. In der nächsten Lektion werden wir einen weiteren sehr nützlichen Befehl sehen, nämlich den Befehl push. 72. Änderungen an das Remote-Repository übertragen: Derzeit haben wir in unserem lokalen Repository vier Kometen, aber in unserem Remote-Repository haben wir nur drei Kamets Wir haben diesen nicht bei. Wenn wir diese Kamide zum Remote-Repository hinzufügen wollen, müssen wir den Befehl Git push verwenden Nun, wie wir wissen, wird dieser Hauptteil zu unserem neuesten Kamid, der sich ebenfalls in unserem Repository befindet, Origin Main wird ebenfalls zu diesem Kometen verschoben Wir schreiben es Push. Hier müssen wir Namen unseres Remote-Repositorys eingeben, der origin lautet. Danach das Fell, das wir schieben wollen, das ist das Wichtigste. Aktuell sind wir auch auf Main, also können wir dieses Haupt-Repository entfernen und wir können Origin entfernen, weil das das Standard-Remote-Repository ist. Jetzt kann es dich manchmal nach deinem Github-Benutzernamen und Passwort fragen deinem Github-Benutzernamen und , bevor der Code übertragen wird. Du musst es schreiben, wenn es danach fragt und wir sind fertig. Lass uns unsere Geschichte überprüfen. Sehen Sie hier, dass unser Ursprung Min in unser Hauptkommando verschoben wurde. Wenn wir das überprüfen möchten, können wir unsere GitHub-Seite überprüfen. Sehen Sie hier, wir bekommen vier Amets und wenn wir es hier überprüfen, dann bekommen wir Camets Wir übertragen unseren Code erfolgreich in unser Remote-Repository. Lassen Sie mich Ihnen jetzt eine andere Situation zeigen. Nehmen wir an, wir haben drei Gameten und im entfernten Depot haben wir nur zwei Ameten Bevor wir diese Kamera in die Fernbedienung schicken, schiebt unser Teammitglied noch einen Kamit hierher. Wenn wir unseren Code übertragen, schlägt unser Push-Befehl fehl Kannst du mir sagen warum? Richtig. In dieser Situation unterscheiden sich unser lokaler Repository-Verlauf und der Remote-Repository-Verlauf. Wenn Git uns immer noch erlaubt, zu pushen, können wir den Commit dieses Teammitglieds verlieren. Und das ist der Grund, warum Git unseren Push-Befehl nicht bestanden hat. Jetzt verwenden manchmal viele Entwickler Git Push F, um unseren Code gewaltsam zu pushen Wenn wir also diesen Befehl ausführen, entfernen wir diesen Amit und fügen unsere Amid in Aber das ist keine gute Methode, denn im Grunde nehmen wir unseren Teammitgliedern die Arbeit ab Wenn Sie also keinen Hauptgrund haben, sollten Sie meiner Meinung keine Druckkraft einsetzen. Was ist nun die Lösung dafür? Wenn also unsere Push-Anfrage fehlschlägt, führen wir zuerst eine Pull-Anfrage durch. Dadurch wird dieser Gummit zu unserem lokalen Repository hinzugefügt, und dann können wir mithilfe von Merge oder Rebase Änderungen in unserer Amid hinzufügen und unsere Änderungen dann per Push auf Remote Jetzt sind unser lokales Repository und Verlauf unseres Remote-Repositorys identisch Die nützlichsten Befehle für Git sind also git pull und Git push, da diese beiden Befehle häufig für die Arbeit im Team verwendet werden. 73. Tags auf die Remote-Seite schieben: Nehmen wir an, unsere Anwendung ist zu diesem Zeitpunkt bereit für Version 1.0. Erinnerst du dich an den Befehl zum Hinzufügen von Tags? Keine Sorge, du kannst mein Git-Chitsheet sehen. Also hier schreiben wir Git-Tag Version 1.0. Mit diesem Befehl fügen wir unserem aktuellen Commit ein Tag hinzu. Wenn wir dieses Tag einem bestimmten Commit geben wollen, dann können wir hier schreiben, was der Pointer oder Commit hat. Lassen Sie uns vorerst ein Tag zu unserem letzten Commit hinzufügen . Lassen Sie uns das überprüfen. Git-Protokoll. Siehst du, unser letzter Commit ist als Tag-Version 1.0 markiert. Jetzt bin ich hier, ich möchte dir etwas sagen. Dieses Tag ist nur in unserem lokalen Repository sichtbar. Dies ist im Github-Remote-Repository nicht sichtbar. Wie können wir also unsere Tags in das Remote-Repository übertragen? Dafür müssen wir Git Push schreiben. Hier schreiben wir unseren Remote-Namen, der origin ist. Hier schreiben wir unseren Tag-Namen , den wir pushen wollen , nämlich Person 1.0. Erledigt. Lassen Sie uns nun auf der Github-Website überprüfen, wir unser Tag erhalten oder nicht. Siehst du, hier bekommen wir einen Tag. Sehen wir uns das genauer an. Hier können wir den Namen und die Uhrzeit des Autors sehen und wir können auch den vollständigen Quellcode von hier herunterladen. Ich benutze es oft, wenn ich an großen Projekten arbeite. So können wir also Tags pushen. Nehmen wir nun an, wir wollen dieses Tag entfernen, damit wir den gleichen Befehl hier schreiben können, wir fügen Dash Delete hinzu. Siehst du, es wurde erfolgreich gelöscht. Wenn wir nun unseren Verlauf überprüfen, können wir sehen, dass das Tag immer noch da ist, weil dieser Befehl das Tag einfach aus unserem Remote-Repository entfernt. Wenn wir dieses Tag auch aus dem lokalen Repository entfernen wollen, schreiben wir Get tag, D, wir schreiben unseren Tag-Namen. Siehst du, es wird auch aus unserem lokalen Repository entfernt. 74. Releases für Github erstellen: In der vorherigen Lektion haben wir also gesehen, wie wir Tags vergeben können. Aber hier ist eine Sache mit Tags. In Tags können wir nicht beschreiben, was in der Version 1.0 enthalten ist. Wenn also ein neuer Entwickler unserem Team beitritt, müssen wir ihm oder ihr erklären , was in dieser Version enthalten ist. Andernfalls müssen wir ihnen sagen, dass sie alle Änderungen sehen sollen. Aber keine Sorge, Github bietet eine sehr nützliche Lösung für diese Situation. In Github können wir Releases hinzufügen , um zu beschreiben, was in dieser Version enthalten ist. Also gehen wir zum Abschnitt, und hier haben wir Veröffentlichungen. Derzeit haben wir keine Version, also erstellen wir eine neue Version. Jetzt haben wir oben die Möglichkeit, das Tag auszuwählen. Derzeit haben wir kein Tag, da wir es in der vorherigen Lektion gelöscht haben. Genau hier, unser Tag-Name Version 1.0, und wir erstellen ein neues Tag Danach wählen wir einen Zweig aus, der der Hauptzweig ist. Hier können wir den Titel unserer Veröffentlichung schreiben. Meist schreiben wir den gleichen Namen wie unseren Tagnamen, aber du kannst auch deinen Namen angeben. Es liegt ganz bei dir. In diesem Textbereich können wir jetzt unsere Änderungen und Funktionen beschreiben. Also wählen wir zuerst die Überschrift von hier aus und genau hier unsere Überschrift, sagen wir, Release-Details. Sie möchten eine Vorschau sehen, dann können wir das auch sehen. Außerdem haben wir viele Optionen. Lassen Sie uns Aufzählungspunkte für Details hinzufügen. Lassen Sie uns ein grundlegendes Website-Layout erstellen, den Layoutfehler beheben und die Homepage entwerfen. Sehen wir uns die Vorschau an. Siehst du, wir bekommen unsere Daten. Unten können wir nun auch Binärdateien an diese Version anhängen. Wenn Sie eine kompilierte Version Ihrer Anwendung oder eine Binärdatei, die Sie hinzufügen möchten, haben, können Sie sie hier bearbeiten. Wenn Ihre Version noch nicht zur Veröffentlichung bereit ist, können wir diese Version als Vorabversion überprüfen. Die Teammitglieder wissen, dass dies noch nicht produktionsbereit ist. Nehmen wir nun an, wir sind bereit für die Veröffentlichung. Ich deaktiviere dieses Kästchen und klicke auf Veröffentlichen. Hier bekommen wir unsere neue Version und wir können Details sehen, einige grundlegende Informationen, und als unseren Text bekommen wir hier auch unseren Quellcode Die Veröffentlichung ist eine sehr schöne Funktion für die Arbeit im Team, und wir können sie auch als Dokumentation unserer Anwendungsreise verwenden . Wenn wir auf die Startseite gehen, finden wir auf der rechten Seite alle Versionen dieses Repositorys. Eine Sache, die ich Ihnen sagen möchte, ist Release die Funktion von Github ist, nicht Git. Wir können nur Releases sehen, die Github verwenden, nicht über die Befehlszeile. In der nächsten Lektion werden wir sehen, wie man mit Branch im Team arbeiten kann. 75. Arbeiten mit Zweigen: Lassen Sie uns nun sehen, wie Sie mit Zweigen im Team arbeiten können. Hier erstelle ich einen neuen Branch mit Kit Switch C Feature Slash und in den Warenkorb Schauen wir uns jetzt unsere Filialliste an. C. Hier haben wir zwei Filialen, Main und Add to Cart. Dieser neue Zweig ist jedoch nur in der lokalen Umgebung verfügbar. Nun, wenn unsere Teammitglieder derselben Filiale arbeiten wollen, wie können sie das dann tun? Dafür müssen wir diesen Branch in unser Remote-Repository verschieben . Oder das, was wir verwenden, zu pushen, richtig. Wir verwenden Git Push Origin Mean, um Änderungen an den Ursprung zu übertragen. Aber hier bringen wir alles auf den neuesten Stand, weil dieser Befehl nur Codes an die Fernbedienung überträgt, keine Branches. Wir schreiben hier, gate, push, hier bekommen wir diesen Petal-Fehler, der besagt, dass das aktuelle Branch-Feature Schrägstrich von Kopf zu Karte keinen Upstream-Zweig hat Außerdem gibt es uns einen Vorschlag zur Lösung dieses Fehlers. Dieser Befehl legt diesen Upstream-Zweig auf unserem Remote-Repository-Ursprung fest. Aber warte, was ist dieser Upstream-Zweig? Was passiert, wenn wir einen Upstream-Zweig einrichten? Setzen eines Upstream-Branches bedeutet, eine Verbindung zwischen unserem lokalen Branch und einem Branch im Remote-Repository aufzubauen zwischen unserem lokalen Branch und . Lassen Sie mich das anhand des Beispiels erklären. Derzeit ist dies unser Zweig in unserem lokalen Repository. Wenn wir unserem Branch vorgeschaltet sind, was bedeutet, dass wir eine Verbindung zu, sagen wir, einem Zweig namens Origin aufbauen sagen wir, einem Zweig namens , der Schrägstrich Ed auf Karte Keine Sorge, das ist nur ein Beispiel. Wenn du deine Filiale pushen willst, dann hat sie den gleichen Namen, den du ihr gibst. Jetzt sind diese beiden Zweige miteinander verbunden und wir können auch sagen, dass der Upstream-Zweig auch als Remote-Tracking-Zweig bezeichnet wird. Sie könnten sagen, wir verstehen, dass die Einstellung eines Upstream-Branches eine Verbindung zwischen lokalen Zweig und einem Zweig im Remote-Repository herstellt. Aber warum brauchen wir diese Verbindung? Was ist der Vorteil, das zu tun? Der erste Vorteil der Einstellung eines Upstream-Branches besteht darin , dass Git weiß, wo die Änderungen aus dem lokalen Zweig veröffentlicht werden sollen. Wenn wir also die Änderungen vom lokalen Branch aus übertragen, diese Verbindung, erfahren wir über diese Verbindung, wo diese Änderungen im Remote-Repository hinzugefügt werden, und dasselbe gilt auch für das Abrufen der Änderungen. Wenn unser Teammitglied etwas in diesen Branch überträgt wir diese Änderungen abrufen, erfahren Sie, von wo die Änderungen abgerufen werden müssen Es holt also die Änderungen von dieser Funktion mit Schrägstrich, Schrägstrich, der zur Karte hinzugefügt wird, in unsere lokale Filiale zur Karte hinzugefügt Insgesamt macht es unser Workflow durch die Einrichtung eines Upstream-Branches einfach, Änderungen zwischen lokalem und Remote-Repository zu übertragen und abzurufen Änderungen zwischen lokalem und Remote-Repository zu übertragen und Schauen wir uns an, wie wir einen Upstream-Branch für unseren lokalen Branch einrichten können . Und hier bietet uns Git auch eine Lösung. Schauen wir uns vorher unsere aktuellen lokalen und Remote-Tracking-Filialen an. Im Grunde sehen wir den Namen der Upstream-Niederlassung. Git-Zweig, V C, hier bekommen wir Min und sein Upstream-Zweig ist Origins Main. Aber was die Funktionen von Kopf zu Karte angeht, haben wir keinen Upstream-Zweig, oder wir können sagen, dass wir keinen Remote-Tracking-Zweig haben. Wenn wir die Liste der Remote-Tracking-Filialen sehen wollen, können wir auch einen Befehl dafür haben. Git-Zweig R für Fernverfolgung. Sehen Sie, derzeit haben wir nur diese beiden Zeiger Origins Main und Origin Slash Head Lassen Sie uns den Upstream-Branch oder den Remote-Tracking-Zweig mit Git Push, Dat, Upstream einrichten Remote-Tracking-Zweig mit Git Push, Dat , oder hier können wir eine Abkürzung schreiben , die dU oder Upstream ist, hier schreiben wir unseren Remote-Namen, der origin ist Danach schreiben wir unseren lokalen Filialnamen , der Feature-Slash Head-to-Cart ist Denken Sie daran, dass wir diesen Befehl nur schreiben müssen , wenn wir unseren Branch zum ersten Mal pushen C, der Zweig wird gedrückt. Wenn wir nun unsere Upstream-Branches überprüfen, erhalten wir den Zweig V C. Jetzt können wir hier den Upstream-Zweig für unseren lokalen Zweig sehen, was ein Origin-Feature ist, Schrägstrich von Kopf bis Fuß. Wenn wir Git Branch R, C ausführen, wird außerdem der Remote Tracking Branch hinzugefügt Lassen Sie uns es auch auf GitHub überprüfen. Im Grunde haben wir einen Zweig, aktualisieren Sie die Seite und sehen Sie, hier haben wir zwei Zweige. Jetzt können wir mit der Arbeit an diesem Head-to-Card-Zweig beginnen, genauso wie wir an unserem Hauptzweig arbeiten. Wenn wir unsere Gammas erweitern wollen, können wir das auf diesen Zweig übertragen, und andere Teammitglieder können sehen, wie sich das verändert Wenn wir diese Verbindung zwischen der lokalen Filiale und der Remote-Tracking-Filiale entfernen wollen , können wir einen Befehl wie diesen schreiben D zum Löschen pusht Hier schreiben wir unseren Remote-Namen, der Origin ist. Und dann schreiben wir unseren Filialnamen , der als Feature-Slash von Kopf zu Karte lautet Also entfernen wir jetzt den Remote-Tracking-Zweig. Wenn wir Git Branch, R und dann C ausführen , erhalten wir wieder diese beiden Zeiger Und wenn wir Git Branch, VV, ausführen, dann können wir hier sehen, dass das Origin-Feature Slash Head to Card weg Origin-Feature Slash Head to Card Lassen Sie uns diesen Branch auch aus unserem lokalen Repository entfernen. das zu tun, müssen wir zuerst zurück zum Hauptzweig wechseln. Hier schreiben wir Git Branch D, und hier schreiben wir unseren Branch-Namen mit Schrägstrich T auf die Karte und fertig, so können wir den Branch in unserem Remote-Repository veröffentlichen , indem wir den Upstream-Zweig setzen In der nächsten Lektion erfahren wir nun in der realen Welt, wie Teammitglieder mit Branch arbeiten 76. Reales Szenario für die Arbeit mit Branch: Lassen Sie uns die Arbeit mit Filialen anhand eines realen Szenarios verstehen . Sie können es klarer verstehen, ohne Zeit zu verschwenden Das ist nicht das Beispiel, das ist eine echte Geschichte Als ich meiner ersten Firma beitrat, hatte ich die Gelegenheit, an einem Feature zu arbeiten, nämlich am Homepage-Design. diesem Feature muss ich mit Unati zusammenarbeiten und sie ist die derzeitige Mitarbeiterin dieser Firma Wir müssen die Homepage für die Unternehmenswebsite entwerfen. Dieses Unternehmen erstellte eine Website wie Stackoverflow für Sie erzählte mir, dass sie am Design der Fragenkarten arbeitet und ich an der Kopf- und Fußzeile sowie an der Seitenleiste arbeiten muss Fußzeile Zuallererst hat sie einen neuen Zweig namens Feature S Home Page eingerichtet und angefangen, an der Gestaltung der Qi-Karte zu arbeiten Aber hier bin ich ahnungslos. Was passiert hier? Wie kann ich mit Branch arbeiten? Ich kenne die Grundlagen von Git, habe aber keine wirkliche Erfahrung. Ich klone zuerst das Projekt vom Github und führe zuerst die Pull-Anfrage aus, um die neuesten Änderungen aus dem Remote-Repository abzurufen. Ich fange auch an, an der gleichen Funktion wie der Sless-Homepage-Branch zu arbeiten der gleichen Funktion wie der Sless-Homepage-Branch Wir arbeiten beide unabhängig voneinander an derselben Branche. Jetzt ist sie mit ihrem Entwurf fertig, also schreibt sie den Code fest und überträgt die Änderungen dann in das Remote-Repository. Jetzt erzählt sie mir, dass sie den Code weitergegeben hat. Auch hier rufe ich die Anfrage ab und hole mir die neuesten Änderungen und füge sie mit meinem Code zusammen. Jetzt, nach einiger Zeit, bin ich mit meinen Entwürfen fertig, also übertrage ich die Änderungen und informiere sie. Sie führt eine Git-Pull-Anfrage aus und führt sie mit ihrem Code zusammen. Nach 5 Stunden Pull-and-Push sind wir mit dem Homepage-Design fertig. Schließlich mache ich alle Änderungen rückgängig und sage es ihr. Sie nimmt alle Änderungen in der Filiale vor, und wenn es zu Konflikten kommt, setzen wir uns miteinander in Verbindung und lösen das Problem. Jetzt wird dieser Code getestet und unser Manager überprüft den endgültigen Code. Wenn alles in Ordnung ist, dann wird dieser Code im Hauptzweig oder Rebase oder Squash-Kms zusammengeführt im Hauptzweig oder Rebase oder , was auch immer die beste Option Dann wird dieser Feature-Slash-Homepage-Branch von der Fernbedienung entfernt Wenn wir den Branch aus dem lokalen Repository entfernen. Das ist das Szenario der Zusammenarbeit, oder Sie können sehen, wie wir als Team an derselben Filiale arbeiten können. 77. Praktisches Showcase der Arbeit mit Branch: Schauen wir uns das praktische Beispiel der Arbeit mit Filialen an. Sie fragen sich vielleicht, warum ich mich so auf die Arbeit mit Filialen konzentriere? Weil dies das am häufigsten verwendete und wenig verwirrende Konzept für Entwickler ist, und deshalb zeige ich es Ihnen Schritt für Schritt. Nach Abschluss dieses Kurses beherrschen Sie die Arbeit mit Branchen. Um das zu simulieren, zeige ich euch beiden die Arbeit von BC. Ich arbeite auf meinem PC und werde auch den Bildschirm vom Nati-PC aus teilen. Das ist Nats PC. Jetzt erstellt C hier in diesem Projekt einen neuen Zweig Zuvor haben wir gesehen, wie man Branches mithilfe von Befehlen erstellt, aber wir können auch Branches mit Github erstellen. Oder öffnen Sie diesen Zweig, gehen Sie nach unten und von hier aus können wir einen neuen Zweig erstellen. Nehmen wir an, wir entwerfen die Homepage und wählen, aus der Hauptseite einen Zweig erstellen und fertig. Wir erstellen unseren neuen Zweig und sehen hier dass dieser Zweig mit dem Hauptzweig auf dem neuesten Stand ist Der Branch befindet sich im Remote-Repository. Wir müssen es in unserem lokalen Repository abrufen. Also hier in diesem Terminal schreiben wir git fetch, um diesen Branch abzurufen Siehst du, hier bekommen wir eine neue Slash-Startseite im Branch-Design. Lass mich dir jetzt etwas zeigen. Wenn wir Git branch schreiben, sehen Sie, hier bekommen wir nicht den neuen Branch, aber wir können sehen, dass Git diesen Branch in unserem Remote-Repository findet . Hier schreiben wir den Git-Zweig R. Dann haben wir diesen Remote-Tracking-Zweig. Wenn wir Git Fetch ausführen, erhalten wir immer den Remote-Tracking-Zweig Jetzt erstellen wir einen neuen privaten Zweig in unserem lokalen Repository und verknüpfen ihn dann mit dem Remote-Tracking-Zweig Dafür schreiben wir ihn switch, C oder create, hier schreiben wir unseren lokalen Branch-Namen, wie auch immer wir ihn nennen wollen. Wir können es beliebig nennen, aber meistens nennen wir es genauso wie den Namen der Remote-Tracking-Filiale. Wir müssen uns also nicht daran erinnern. Homepage gestalten. müssen wir den Namen unserer Remote-Tracking-Filiale schreiben, die wir verlinken möchten, nämlich die Origin Design-Homepage. Wir bekommen hier den Namen der Remote-Tracking-Filiale. Wenn wir nun Git Branch VV, C schreiben, erhalten wir hier den Branch, und er ist auch mit der Origin-Design-Slash-Startseite verknüpft der Origin-Design-Slash-Startseite Wenn jemand anderes einen Branch erstellt und den Branch im Repository verschiebt, müssen wir zuerst den Befehl fetch ausführen Dadurch erhalten wir den Remote-Tracking-Zweig, und dann müssen wir einen lokalen Zweig erstellen und ihn mit unserem Remote-Tracking-Zweig verknüpfen , indem wir Kit Switch, C, den Namen der lokalen Filiale und den Namen der Remote-Tracking-Filiale Jetzt können wir hier unsere Änderungen übernehmen und sie an unseren Ursprung übertragen. Also öffne ich dieses Repository im VS-Code, und hier erstelle ich eine neue Datei namens Index Dot DML und füge hier einfach Boilerplate-Code Speichern Sie das und stellen Sie die Änderungen einfach bereit und übernehmen Sie diese Änderungen Gated M, erstellt und indexiert Punkt-DML für die Startseite. Lassen Sie uns die Änderungen auch auf die Fernbedienung übertragen. Git Push, fertig. Lassen Sie uns jetzt sehen, wie ich auf meinem Bildschirm arbeite. Hier haben wir unser Repository auf meinem PC. Wenn wir das nicht haben, müssen wir unser Projekt klonen. Lassen Sie uns zuerst alle Änderungen mit Git Fetch abrufen. Wenn wir unser Log überprüfen, sehen Sie, hier bekommen wir einen neuen Zweig Jetzt wechsle ich zu diesem Zweig, indem Slash-Startseite von Kit Switch Design Bevor wir mit der Arbeit an unserem Code beginnen, ist es immer besser, Änderungen aus der Ferne abzurufen Aber hier holen wir uns einfach die Änderungen, sodass wir sie nicht benötigen, sodass wir direkt mit der Arbeit daran beginnen können Hier nehme ich einige Änderungen an der Datei script dot js vor und speichere die Änderungen Stellen wir uns nun vor, ich habe meine Arbeit an diesem Zweig abgeschlossen. Lassen Sie uns die Änderungen in die Phase bringen und den Code auch mit der Commit-Nachricht festschreiben, Arbeit an der JS-Datei des Skripts abschließen, ich pushe die Änderungen, Gate-Push. Wie ich Ihnen bereits sagte, liegt die Schließung dieser Filiale nun in der Verantwortung von Nati. Kehren wir zur Nato-Spezifikation zurück. Hier sehen Sie zuerst, wie ich meine Änderungen mit Git Pull importiere. Gut. Hier geht's schnell zu unserer Zusammenführung. Schauen wir uns unsere Geschichte an. Hier kommen wir zu den Commits. Jetzt haben wir unseren Filialcode fertig und auch unser Design-Homepage-Pointer befindet sich vor dem Hauptzweig Hier müssen wir unseren Code im Hauptzweig zusammenführen. Wir haben das schon so oft gemacht, hier wechseln wir zuerst zurück zum Hauptzweig. Danach schreiben wir Gate, Merge, Design Home Page. Siehst du, hier kommen wir schnell zu unserer Zusammenführung, weil wir lineare Verzweigungen haben. Aber hier gibt es keine Konflikte. Weil das nur eine Demo ist. Höchstwahrscheinlich werden Sie jedes Mal Konflikte bekommen, und wir wissen bereits, wie man Konflikte löst. Sie müssen es also mit Ihren Teammitgliedern lösen. Sehen wir uns jetzt hier unser Logbuch an. Wir können jetzt sehen unser Hauptzeiger und unser Design-Homepage-Zeiger auf demselben MIT befinden. Aber der Ursprung von Min ist auf dem vorherigen Amid. Also müssen wir die Änderungen in das Remote-Repository übertragen und wie wir das machen können, richtig, indem wir Git Push verwenden. Schauen wir uns jetzt noch einmal unseren Verlauf an. Jetzt hat Origin Min dieselbe Gangart. Lass uns das jetzt auch auf Github überprüfen. Gehe zu den Gameten. Sehen Sie hier wir bekommen unseren neuesten Camite , Merge Gamit Da unser Design-Homepage-Zweig nun im Hauptzweig zusammengeführt ist, können wir diesen Design-Homepage-Zweig entfernen Andernfalls wird es zu Verwirrung führen. Holen Sie sich also die Homepage von PhD Origin und Design. C, Zweig aus dem Remote-Repository gelöscht. Aber wenn wir die Zweige C sehen, erhalten wir hier immer noch den Homepage-Zweig, also müssen wir ihn auch löschen. Holen Sie sich Branch D Design Homepage. Jetzt gibt es auch unsere Filiale vor Ort. Nun zurück zu meinem PC. Ich werde zuerst die Änderungen für den Merge-Commit abrufen. Jetzt haben wir beide den gleichen Commit-Verlauf. Lassen Sie uns zunächst den Remote-Tracking-Zweig mit Git BanchR überprüfen den Remote-Tracking-Zweig mit Git BanchR Sehen Sie hier, ich erhalte den Origin-Design-Slash-Home-Zweig. Bisher haben wir den Remote-Tracking-Zweig entfernt , der in Remote nicht verfügbar ist, wir schreiben Git Remote Prune Origin Dieser Befehl entfernt alle Remote-Tracking-Branches, die im Remote-Repository nicht verfügbar sind im Remote-Repository nicht verfügbar Lassen Sie mich jetzt die lokalen Filialen überprüfen. Siehst du, ich habe noch hier, ich muss auch die Filiale vor Ort fallen lassen. Auch hier, git branch D Design-Startseite, und hier erhalten wir die Fehlermeldung, Branch-Design-Slash-Startseite kann nicht gelöscht werden, weil wir uns gerade auf der Design-Slash-Startseite befinden, wir wechseln zum Master-Branch Gate, um beispielsweise den Befehl git pull zu verwenden , um den lokalen Zweig zu aktualisieren Sehen Sie hier, wir kommen schnell zu unserer Zusammenführung, und wenn wir unsere Historie überprüfen, sehen Sie hier, wir haben immer noch diesen Design-Homepage-Branch. Wir führen Git Branch D Design Slash Home Page und es heißt den Branch löschen So arbeiten wir mit Zweigen im Team. Wenn Sie etwas verwirrt sind, Sie sich keine Sorgen, lassen Sie mich diesen Teil noch einmal zusammenfassen Zuerst erstellen wir einen neuen Zweig und um diesen Zweig zu pushen , müssen wir einen Upstream-Zweig einrichten Es weiß also, welcher lokale Zweig mit dem entfernten Zweig verbunden ist. Danach können wir mit der Arbeit an der Filiale beginnen. Wenn wir etwas pushen wollen, dann schreiben wir es zuerst fest und dann können wir es an den Ursprung weiterleiten. Aber bevor wir pushen, empfiehlt es sich, Pull zu verwenden. Wir erhalten die neuesten Änderungen und nachdem wir die Arbeit am Commits-Zweig abgeschlossen haben, führen wir ihn mit dem Hauptzweig zusammen und entfernen dann den Remote-Tracking-Zweig und auch den lokalen Zweig Wenn der Remote-Tracking-Branch bereits von einem anderen Teammitglied gelöscht wurde, müssen wir Git Remote und Prune Origin ausführen und schon sind wir fertig 78. Pull-Requests auf Github erstellen: Nehmen wir an, Sie arbeiten an einem Zweig und möchten zwischendurch im Code einige Vorschläge von den Teammitgliedern erhalten. Dann kannst du auf Github Vorschläge annehmen oder Diskussionen zu einem bestimmten Thema eröffnen. In diesem Fall können wir eine Pull-Anfrage für eine offene Diskussion über unseren Code erstellen . Bitten Sie andere Teammitglieder um Vorschläge oder Bewertungen . Lassen Sie mich Ihnen das praktisch zeigen. Hier ist der NathiPC. Lassen Sie uns einen neuen Zweig erstellen und Änderungen in diesem Zuerst schreiben wir eine Git Switch Design Slash Q&A-Seite. Lassen Sie uns diesen Code im Vias-Code öffnen. Hier im Indexpunkt sdmlFle im Hauptteil füge ich das Haupt-Tag hinzu Darin füge ich Du hinzu, ein weiteres DU und hier H ein Tag. Das ist Frage eins. Das ist nur eine Demo. Speichere das und lass uns diese Änderungen kommunizieren und posten. In unserem Terminal schreiben wir Tight AM und fügen eine Q-Karte hinzu. Eins. Gut. Jetzt müssen wir diese Änderungen in unser Remote-Repository übertragen. Und wie können wir das machen? Wir können Gate, Push schreiben. Aber sehen Sie hier, wir bekommen einen fatalen Fehler. Kannst du mir sagen warum? Ja, weil wir keinen Upstream-Zweig eingerichtet haben. Oder in einfachen Worten, wir verknüpfen unseren lokalen Zweig nicht mit dem Remote-Branch. Hier schreiben wir einfach Git Push u Origin, hier schreiben wir unseren lokalen Branch-Namen , also Design Slash Q&A-Seite und fertig Hier pushen wir unsere Änderungen mit der Einstellung Upstream branch. Lassen Sie mich dieses Konto auf der GitHub-Website eröffnen. Sehen Sie auf der Homepage, hier bekommen wir Design SQ und Page, H DSN Push, und wir bekommen auch D Compare und Pull Request Hier können wir die Diskussion für diesen Zweig der Q & A-Seite eröffnen und Mitwirkende kann einige Vorschläge machen oder den Code diskutieren Außerdem können wir über diesen Pull-Request-Tab eine Pull-Anfrage erstellen diesen Pull-Request-Tab eine Pull-Anfrage Klicken Sie auf Neue Pull-Anfrage. Jetzt können wir hier zwei Zweige auswählen, um Änderungen zu vergleichen. In den meisten Fällen wählen wir den Hauptzweig als Basiszweig aus, und hier wählen wir unseren Zweig auf der Q & A-Seite Siehst du, hier bekommen wir die Commits für diesen Zweig. Wir haben einen Commit, eine Dateiänderung und auch einen Mitwirkenden Hier erhalten wir eine Liste der Commits und darunter können wir die Änderungen in unseren Dateien sehen Hier können wir auch die geteilte Ansicht auswählen, sodass wir das Vorher und das Nachher sehr deutlich sehen können Lassen Sie uns nun die Diskussion für diesen Zweig eröffnen. Klicken Sie auf Pull-Request erstellen. Hier können wir unseren Diskussionstitel schreiben. Lassen Sie uns diese in Vorschläge für das Telefon mit der Fragenkarte ändern. Im Folgenden können wir beschreiben, was wir besprechen möchten, was wir beheben möchten usw. Nehmen wir an, wir fügen zuerst benötigten Titelvorschläge hinzu und danach Stichpunkte, schlagen einige semantische Tags für die Karte vor und geben einen Überblick über diesen Hauptcode. Jetzt können wir einfach eine Pull-Anfrage erstellen oder sie auch entwerfen Gehen wir zu Pull-Anfrage erstellen. Sehen Sie hier, wir befinden uns in der Konversation und dieser Pull-Request-Status ist offen. Wie können nun andere Teammitglieder wissen, dass wir diese Diskussion eröffnet haben? Dafür müssen wir sie zu den Rezensenten hinzufügen. Klicken Sie auf dieses Zahnradsymbol und hier haben wir die Liste der Mitwirkenden, die wir zu Beginn dieses Abschnitts in unser Repository aufgenommen Beginn dieses Abschnitts in unser Repository Dieser Account gefällt uns. Sobald wir den Benutzer ausgewählt haben, sendet Github eine E-Mail an diesen Benutzer und teilt ihm mit, dass es eine neue Diskussion gibt. Lassen Sie mich jetzt das Fenster wechseln und Ihnen zeigen , wie dieses Teammitglied unseren Code überprüfen kann. Das ist also mein ursprüngliches Konto. Wir gehen zum Pull-Request und sehen hier, dass wir diese Diskussion haben. Öffne das. Schau oben, hier bekommen wir diese Nachricht. Dieser Benutzer hat deine Bewertung zu diesem Pull-Request angefordert. Klicken Sie also auf Bewertung hinzufügen. Hier erhalten wir eine geteilte Ansicht dieser geänderten Datei. Wenn Sie die gesamte Datei sehen möchten, können wir hier auf Alle erweitern klicken. Jetzt habe ich hier ein paar Änderungen, die ich vorschlagen möchte. Zuerst können wir in diesem Haupt-Tag wie Abschnitt-Artikel gehen, und dann H ein Tag, und dann H ein Tag, nicht das einfache De. Außerdem möchte ich es im Unterricht für einen Fragenkartenartikel sagen, damit die Entwickler wissen, dass es sich um Unterricht für einen Fragenkartenartikel eine Fragenkarte handelt. Hier sehen wir vor jeder Zeile diese Plus-Icons. Auf diese Weise können wir für jede Zeile eine Bewertung schreiben. Aber momentan möchte ich nur Texthierarchie und den Klassennamen angeben. Also klicke ich auf dieses Plus-Symbol und wir schreiben hier unsere Bewertung. Also füge ich zuerst einen Aufzählungspunkt hinzu, füge das semantische Tag, den Hauptabschnitt, den Artikel und H eins hinzu und füge danach dem Artikel-Tag die Unterstrichkarte Klasse entspricht Frage hinzu Und starte einfach die Rezension. Hier können wir die Überprüfung und die Details sehen . Derzeit befindet sie sich im Status „Ausstehend“, und wir beenden diese Überprüfung einfach. Hier müssen wir eine grundlegende Beschreibung für unsere Bewertung schreiben. Also können wir diese Vorschläge für diesen Code schreiben, die Änderungen vornehmen und sie pushen. Unten haben wir jetzt drei Optionen. Zuerst können wir das als Befehl einreichen. Wir können auf Genehmigen setzen und die Änderungen beantragen. Derzeit bitten wir um zwei Änderungen, sodass wir diese auswählen und die Bewertung einfach einreichen können. Siehst du, wir befinden uns im Konversations-Tab dieses Pull-Requests und können von hier aus sehen, was hier unten passiert Wir erhalten unsere Bewertung, die gerade sehr systematisch eingereicht wurde . Und darunter können Sie sehen, dass wir eine Änderungsanfrage haben. A Auf der rechten Seite haben wir dieses Symbol, das diesen Benutzer auf Wunsch über Änderungen informiert. Wechseln wir nun wieder zu dem Nadis-Account , von dem aus ich diese Diskussion gestartet habe Zuerst haben wir die Vorschau auf der Registerkarte Konversation erstellt. Und dann nehmen wir Änderungen an unserem Code vor. Also öffne ich den Indexpunkt sdmlFle. Zuerst ändere ich das zuerst aufgrund des Abschnitts und zweitens von DU zum Artikel Wenn du dich fragst, wie ich öffnende und schließende Tags zusammen ändere, dann musst du die Erweiterung Autor Nam Tag in deinem VS-Code installieren , sehr zu empfehlen. Außerdem müssen wir hier die Unterstrichkarte Klasse zur Frage hinzufügen Unterstrichkarte Klasse zur Frage Speichern Sie die Änderungen und lassen Sie uns diese Änderungen übernehmen. Also werden die semantischen Tags und der Klassenname von GTMTAm und der Klassenname Ich weiß, das ist eine schlechte Commit-Nachricht, aber sie Dann lass uns das auch pushen. Da wir nun mit unseren Änderungen fertig sind, müssen wir dem Mitglied mitteilen, dass es sich unsere Änderungen ansehen und überprüfen soll . Auf der rechten Seite haben wir die Option, eine Überprüfung erneut anzufordern. Klicken Sie darauf. Dadurch wird erneut eine E-Mail an Benutzer gesendet , in der er aufgefordert wird, Updates zu sehen. Ich wechsle erneut zu meinem Konto und hier kann ich sehen, und hier kann ich sehen dieser Benutzer Ihre Bewertung zu dieser Pull-Anfrage angefordert hat. Klicke auf Deine Bewertung hinzufügen. Überprüfe unsere Änderungen und wenn wir nicht zufrieden sind, können wir erneut eine Bewertung schreiben und diese Bewertung einreichen. Hier sind wir mit den Änderungen zufrieden, dann können wir auf „Angesehen“ klicken und dann einfach auf diese Bewertungsänderungen klicken. Hier schreibe ich, perfekt, das ist in unserer Hauptniederlassung zusammengelegt. Von unten können wir eine Bewertung auswählen, genehmigen und einreichen. Hier sehen Sie, dass die Änderungen genehmigt wurden und diese Diskussion ihren Zweck erfüllt . Wir können oben sehen, dass wir den Status der genehmigten Änderungen haben. Unten haben wir nun Optionen zum Zusammenführen dieser Pool-Anfrage Hier ist nun eine Debatte , die Entwickler wenn es darum geht, Pool-Anfragen zu schließen Fragen Sie, wer diese Pull-Anfrage zusammenführen soll? Derjenige, der diese Pull-Anfrage gestartet hat, oder einige Reviewer sollten die Pull-Anfrage zusammenführen Einige Entwickler entscheiden sich für diese erste Option, weil sie glauben, dass die Person, die die Pull-Anfrage startet, mehr darüber weiß Also muss derjenige, der diese Pull-Anfrage erstellt hat, sie zusammenführen. Einige Entwickler sagen also, dass die Person, die zu MR beiträgt , der Prüfer zusammenführen sollte. Ehrlich gesagt müssen Sie sich darüber keine Sorgen machen. Fragen Sie einfach Ihre Teammitglieder oder Ihren Manager danach , denn einige Unternehmen folgen ersten Option und andere der zweiten. Tun Sie also, was Ihre Teammitglieder vorschlagen. Wir können diesen Pull-Request von hier aus zusammenführen und haben drei Optionen: Merge, Simple Merge, Squash and Merge und Rebase and Wir kennen diese Option bereits, also gehen wir zur einfachen Zusammenführung über und bestätigen die Zusammenführung Siehst du, wir bekommen die Pull-Anfrage erfolgreich zusammengeführt und geschlossen. Jetzt können wir diesen Zweig von hier entfernen. Wir können den Zweig wiederherstellen. Lassen Sie mich jetzt zum NathIPCF-Switch zurück zum Haupt-Do-Gate gehen und ziehen, um den Merge-Commit zu bekommen Sehen Sie, wir sind schnell bei unserer Zusammenführung und wenn wir unseren Verlauf überprüfen, sehen Sie, hier haben wir eine Q&A-Seite und auch eine Remote-Tracking-Filiale Wir müssen diesen Zweig aus dem lokalen Zweig entfernen und auch den Remote-Tracking-Zweig entfernen Dieser Zweig wurde also bereits aus dem Remote-Repository entfernt, und wir möchten ihn aus unserem lokalen Repository entfernen , und wie wir das tun können. Wir können Git Remote schreiben, Origin bereinigen. Lassen Sie uns jetzt auch diesen lokalen Zweig entfernen. Git Branch D, Designs Q & A-Seite und fertig. Sie können sehen, ob wir irgendwelche Git-Befehle zwei- oder dreimal verwenden , dann lassen wir uns davon nicht verwirren Wie ich dir schon gesagt habe, hier dreht sich alles um Übung. Ich weiß, dass diese Lektion etwas lang ist, also kannst du fünf bis zehn Minuten Pause machen, frische Luft schnappen und danach diesen Kurs fortsetzen. 79. Konflikte während Pull-Requests lösen: Bisher haben wir gesehen, dass bei Zusammenführung von Pull-Requests keine Konflikte auftreten Aber was ist, wenn wir Konflikte bekommen? Eine Möglichkeit ist, dass wir VS-Code verwenden können, aber das ist ein wenig langer Weg. Wenn wir in unserer lokalen Niederlassung zusammenführen, müssen wir VS-Code verwenden. Wir können Konflikte aber auch mit Github lösen. Es ist nur nützlich, während wir Pull-Requests zusammenführen. Lass uns das sagen Zuerst erstelle ich einen neuen Zweig von Una auf diesem PC und mache eine Gangart und schiebe die Kat Holen Sie sich die Homepage mit den Funktionen von Swish C. Hier im Indexpunkt sdmlFle ändere ich den Titel für die Demo in den Titel der Startseite Und ändere auch die erste Zeile in der Skriptpunkt-Gs-Datei. Das ist ein Skript für die Homepage. Speichern Sie die Änderungen und lassen Sie uns das Gtms AM, Update-Titel und das Skript für die Home-Funktion Lassen Sie uns nun diesen Zweig auf Github pushen . Erinnerst du dich daran? Richtig, verwende Git Push, um die Slash-Startseite der Upstream-Branch-Origin-Funktion einzurichten Slash-Startseite der Upstream-Branch-Origin-Funktion Jetzt, um Konflikte zu erzeugen, öffne ich ein Github-Konto von meinem PC aus und öffne einfach Indexpunkt stmlFle. Wir wählen Bearbeiten und ändern diesen Titel in Titel im Hauptzweig Lassen Sie uns die Änderungen übernehmen und mit diesem Commit fortfahren. Lassen Sie uns nun eine weitere JS-Datei mit Konfliktinskripten erstellen. Also ändern wir wieder die erste Zeile auf das Skript pro Hauptzweig und kommen zu Vertauschungen Lassen Sie mich jetzt einen Pull-Request erstellen. Gehen Sie also zu Github und wir gehen zum Bereich Pull-Requests. Hier erstellen wir eine neue Pull-Anfrage. Base ist der Hauptzweig, und wir vergleichen ihn mit der Funktion SLS-Startseite. Siehst du, hier können wir nicht automatisch zusammenführen. Keine Sorge, du kannst trotzdem einen Pull-Request erstellen. Lass uns eine Pull-Anfrage erstellen. Hier wird automatisch eine Commit-Nachricht ausgewählt, und wir können eine Beschreibung für die Pull-Anfrage, eine Pull-Anfrage für die Feature-Slash-Startseite schreiben Pull-Anfrage für die Feature-Slash-Startseite und eine Pull-Anfrage erstellen Sehen Sie, hier bekommen wir, dass dieser Branch Konflikte hat, die gelöst werden müssen Hier können wir also die Befehlszeile verwenden, um die Konflikte zu lösen. Das können wir auch mit Github machen . Wir klicken einfach auf Konflikte lösen. Hier auf der linken Seite erhalten wir die Liste der Dateien , bei denen Konflikte auftreten. Hier können wir den Konflikt sehen. Wir haben diese Hinweise bereits gesehen. Ich möchte diesen Homepage-Titel behalten. Wenn der Konflikt in dieser Datei behoben ist klicken Sie für diese Datei auf Als gelöst markieren. Nun zur nächsten Datei, hier behalte ich diesen Hauptzweigcode. Sehen Sie hier, wo alle Konflikte weg sind. Wir können diese Datei auch als Resolve markieren und einfach den Commit-Merge-Vorgang durchführen. Und sehen Sie, jetzt hat dieser Zweig keinen Konflikt mit dem Basiszweig. Und wenn Sie Prüfer hinzufügen möchten, können wir das genauso tun, wie wir es in der vorherigen Lektion getan haben Jetzt können wir die Pull-Anfrage zusammenführen und die Zusammenführung bestätigen. diese Weise können wir Konflikte beim Erstellen einer Merge-Anfrage lösen. 80. Probleme in Github erstellen: Da wir jetzt auf Github eine Pull-Request-Funktion haben, erhalten wir auch die Option „Probleme“. Auch dies ist die Funktion von Github, nicht von Git. Was sind diese Probleme? Probleme sind wie Sticky Nodes, die wir in unserem Buch verwenden. Sticky Nodes werden verwendet, um Knoten schreiben, etwas zu korrigieren oder Fragen zu schreiben usw. Genauso wie wir Probleme verwenden können, um Aufgaben und Bugs nachzuverfolgen , oder wir können auch über unser Projekt diskutieren . Lass mich dir das zeigen. Klicken Sie also auf Neue Ausgabe. Hier können wir den Titel unserer Ausgabe schreiben. Nehmen wir an, eine Diskussion über Kartenfunktionen. Und hier schreiben wir unsere Beschreibung für dieses Problem. Lassen Sie uns über die Funktionen der Fragenkarte für dieses Projekt sprechen . Hier können wir auch das Demo-Bild unseres Karten-Basisdesigns bestätigen das Demo-Bild unseres Karten-Basisdesigns Anlagen sind sehr nützlich. Wenn wir Probleme bei der Behebung der Fehler haben, können wir den Screenshot oder die Bildschirmaufnahme bestätigen der die Fehler angezeigt werden Auf der rechten Seite können wir das Problem unseren Teammitgliedern zuweisen das Problem unseren Teammitgliedern Im Moment habe ich gerade mein anderes Konto hinzugefügt. Danach haben wir Labels. Github hat so viele relevante Labels für fast alle Arten von Problemen. Hier finden Sie eine Fehlerdokumentation, ein Duplikat, Verbesserung, ein gutes erstes Problem, ein ungültiges Problem, eine Frage und einen Vance-Fix Außerdem können wir unsere eigenen Labels erstellen. Lassen Sie uns diese Labels bearbeiten. Und erstelle ein neues Etikett. Wir können über Namen diskutieren. Von hier aus können wir die Farbe ändern. Also lass mich etwas versuchen. Ja. Ich mag das und kreiere ein Label. Jetzt zurück zu unserer Seite. Und ich wähle dieses neue Label aus. Hier können wir auch unsere Projekte verlinken. Außerdem haben wir derzeit keine Meilensteine. Meilensteine werden wir in der nächsten Lektion sehen. Machen Sie sich darüber vorerst keine Sorgen. Außerdem haben wir derzeit keine Pull-Anfrage, andernfalls können wir das Problem auch mit der Pull-Anfrage verbinden. Und wenn wir diesen Pull-Request zusammenführen, werden alle verbundenen Issues automatisch geschlossen und wir können ein neues Problem einreichen. Sehen Sie hier, wie wir dieses Problem öffnen. Jetzt werden die Zuweiser zu diesem Thema Stellung nehmen und darüber diskutieren, was sie denken, und ihre Vorschläge unterbreiten Jetzt, nachdem wir die gesamte Diskussion abgeschlossen haben, können wir dieses Thema auch schließen So können wir Probleme mit Github nutzen. Deshalb lieben Entwickler Github. 81. Meilensteine in GitHub hinzufügen: Jetzt wollen wir in unserem Projekt manchmal einen Meilenstein schaffen Meilenstein können wir als kurzfristiges oder langfristiges Ziel betrachten , das wir zu einem bestimmten Zeitpunkt erreichen möchten. In unserem Projekt möchten wir beispielsweise eine Benutzerauthentifizierungsfunktion hinzufügen. So können wir einen Meilenstein erstellen und Datum für den Abschluss dieses Meilensteins festlegen. diesem Meilenstein können wir verschiedene Arten von Problemen hinzufügen, z. B. die Gestaltung der Anmeldeseite, Gestaltung der Anmeldeseite, den Plan für Optionen zum Zurücksetzen des Passworts usw. Nehmen wir an, ich löse dieses Problem mit der Design-Anmeldeseite, sodass ich dieses Problem als abgeschlossen markieren kann, und in unserem Meilenstein haben wir 33,3% Fortschritt Wenn alle Probleme gelöst sind, die mit diesem Meilenstein zu tun haben, fließt unser Meilenstein automatisch weiter Dies ist sehr nützlich, um den Fortschritt unserer Projekte zu planen , zu organisieren und zu verfolgen. Mal sehen, wie wir Meilensteine auf Github erstellen können. Hier sind wir im Themenbereich. Ganz oben erhalten wir die Meilensteinoption. Derzeit haben wir keine Meilensteine Erstellen Sie einen neuen Meilenstein Hier schreibe ich den Titel für diesen Meilenstein. Sagen wir Benutzerauthentifizierung. Hier können wir den ungefähren Zeitpunkt auswählen, an dem wir diesen Meilenstein erreicht haben, und schließlich können wir eine Beschreibung für die Beschreibung dieses Meilensteins schreiben Beschreibung für die Beschreibung dieses Implementieren Sie also Funktionen zur Benutzerauthentifizierung, einschließlich der Funktionen zur Anmeldung und zum Zurücksetzen des Passworts, und wir erstellen einen und wir Dies ist unsere Liste der Meilensteine. Hier haben wir grundlegende Informationen zum Meilenstein und hier können wir unsere Fortschritte sehen Um Ihnen den Fortschritt zu zeigen, fügen wir diesem Meilenstein ein Problem hinzu. Gehen Sie zu den Ausgaben und erstellen Sie eine neue Ausgabe. Fügen Sie hier Titel, Design, Anmeldeseite und Zuweiser hinzu, damit wir uns auch selbst zuweisen können Ich wähle das Label für die Erweiterung aus und von hier aus können wir den Meilenstein auswählen Sehen Sie, hier haben wir einen Meilenstein für die Benutzerauthentifizierung. Dies ist eine weitere Möglichkeit, Probleme zum Meilenstein hinzuzufügen. Deshalb reiche ich vorerst nur eine neue Ausgabe ein. Jetzt zurück zur Problemseite. Hier wählen wir unsere Ausgaben aus allen offenen Ausgaben aus. Und hier haben wir die Option Meilenstein. Hier wählen wir den Meilenstein für die Benutzerauthentifizierung aus und sehen, hier erhalten wir unseren Meilensteinnamen. Sehen wir uns unseren Meilenstein an. Wir können sehen, dass wir in diesem Meilenstein noch ein Problem offen haben. Klicken Sie also auf den Meilenstein und nachdem wir das Problem abgeschlossen haben, können wir dieses auswählen und es als abgeschlossenes Problem markieren Und sieh hier, unser Meilenstein ist zu 100% abgeschlossen. So können wir Meilensteine in Github verwenden. 82. Workflow der Arbeit an einem Open-Source-Projekt: Bis jetzt sehen wir, wie wir mit unseren Teammitgliedern an unserem Projekt arbeiten können . Auf Gitub können wir auch an einem Open-Source-Projekt arbeiten. Sehen wir uns den Workflow eines Open-Source-Projekts an. Hier ist zum Beispiel ein Open-Source-Projekt, zu dem Sie gerne beitragen möchten. Dies ist das Projekt auf meinem Gitub-Account, aber Sie können nicht direkt mit der Arbeit an diesem Projekt beginnen , da Sie nicht als Mitwirkender hinzugefügt wurden Deshalb können Sie Ihren Code auch nicht auf dieses Projekt übertragen Also, was ist hier die Lösung? Wie können wir anfangen, an diesem Projekt zu arbeiten? Zunächst müssen Sie dieses Projekt zu Ihrem eigenen Github-Konto hinzufügen . Dies wird als Erstellen von Fork bezeichnet. Jetzt haben wir hier vollständigen Zugriff auf dieses Repository. Wenn Sie jetzt mit Ihrem Beitrag fertig sind, können Sie Ihre Änderungen in Ihr Repository übertragen. Danach können Sie eine Pull-Anfrage erstellen , um Ihren Code zusammenzuführen. Und sobald du eine Pull-Anfrage erstellst, Github, schicke mir das per E-Mail. Jemand erstellt eine Pull-Anfrage für dieses Open-Source-Projekt. Ich überprüfe deinen Code. Wenn ich Ihnen einige Vorschläge machen möchte, gebe ich Ihnen diese und wenn ich mit dem Code zufrieden bin, kann ich diesen Code direkt aus Ihrer Pool-Anfrage in mein Projekt einbinden. Hier können Sie die Änderungen in meinem Repository nicht zusammenführen , da nur ich die Änderungen in mein Projekt übertragen kann. Zusammenfassend finden wir zunächst ein Open-Source-Projekt, an dem Sie gerne arbeiten Dann forken wir das Repository. Dadurch wird das Open-Source-Projekt zu Ihrem Github-Konto hinzugefügt . Wenn Sie mit Ihren Änderungen fertig sind, können Sie die Änderungen zur abschließenden Überprüfung an Ihrem Projekt weitergeben und eine Pull-Anfrage erstellen. Nun überprüft der Autor dieser Anfrage Ihren Code, gibt einige Bewertungen zu Ihrem Code ab oder schlägt Ihnen vor, einige Änderungen vorzunehmen und diesen Code dann einfach mit seinem Open-Source-Projekt zusammenzuführen . So können wir an dem Open-Source-Projekt arbeiten. In der nächsten Lektion werden wir das nun praktisch sehen. 83. Wie man an einem Open-Source-Projekt arbeitet: Wenn wir also zu einem Projekt beitragen möchten, können Sie hier das Repository durchsuchen. Angenommen, ich möchte an der Suchfunktion in React arbeiten . Also suche ich hier React Search. Hier bekommen wir die Liste der Repositorien, und so können wir das Repository finden Und in diesem Repository haben die Entwickler einige Probleme hinzugefügt, Entwickler einige Probleme hinzugefügt die sie zur Diskussion oder zur Mitarbeit Sie können an diesem speziellen Problem arbeiten. Hier wähle ich mein eigenes Projekt aus, das ich vor drei Jahren erstellt habe. Und hier können wir sehen, dass ich auch eine Ausgabe für dieses Repository öffne. Nun, dieses Repository wird von meinem alten Account übernommen, nicht von Cod bless you Account. Und in diesem Browser habe ich mich mit Cod Blessu angemeldet , damit ich zu diesem Projekt beitragen kann Der erste Schritt zur Arbeit an einem Open-Source-Projekt besteht darin, dass wir das Repository in unserem Konto forken Klicken Sie also auf der rechten Seite einfach auf dieses Nebelsymbol. Hier können wir diese Details ändern, wenn wir möchten, und einfach auf Nebel erstellen klicken. Siehst du, hier bekommen wir die Kopie dieses Repositorys und wir können sehen, wie es sich aus dem ursprünglichen Repository zusammensetzt. Hier können wir sehen, dass dieser Zweig mit unserem ursprünglichen Repository-Zweig auf dem neuesten Stand ist . Jetzt können wir dieses Repository auf unserem Computer schließen und mit der Arbeit daran beginnen. Lass mich dir das zeigen, damit du nicht verwirrt wirst. Kopieren Sie diesen Repository-Link und öffnen Sie das Terminal, in dem Sie dieses Projekt hinzufügen möchten. Hier schreiben wir Git Clone und fügen den Repository-Link ein. Gut. Gehen wir in diesen Ordner und erstellen hier einen neuen Zweig. Holen Sie sich Switch als C Design Home und öffnen Sie das im VS-Code. Hier nehme ich eine kleine Änderung an der App Dot JS-Datei vor. Speichern Sie die Änderungen und lassen Sie uns diese Änderungen übernehmen. Also Git, komm um 8:00 Uhr und aktualisiere die F-Datei. Und um diesen Branch zu pushen, schreiben wir zum ersten Mal Git Push U für Upstream Origin Design Home. Gut. Jetzt, wo wir mit unseren Updates fertig sind, kehren wir zu unserem Repository zurück und aktualisieren die Seite. Siehst du, hier holen wir uns dieses Design nach Hause, Harris, und drücken. So können wir vergleichen und Anfragen abrufen, genau wie zuvor. Aber hier ist ein kleiner Unterschied. Wir vergleichen unseren Design-Home-Zweig mit unserem Fog-Repository unserem Fog-Repository und wir vergleichen ihn mit diesem ursprünglichen Repository-Master-Branch. Hier können wir einen Titel für den Pull-Request schreiben und auch eine Beschreibung schreiben. Im Moment wähle ich direkt Pull-Anfrage erstellen aus. Sehen Sie, hier haben wir eine Pool-Anfrage erstellt, und dabei haben wir keine Konflikte. Aber hier ist eine Sache. Wir können diese Pool-Anfrage nicht zusammenführen, nur der Maintainer oder Eigentümer kann sie zusammenführen Von meinem alten Konto kann ich die Änderungen akzeptieren und sie in diesem Haupt-Repository implementieren Hier ist mein altes Konto, das der Besitzer dieses Repositorys ist, und hier können wir die Pull-Anfrage sehen. Öffne das und hier können wir das Bett von unten sehen, hier dieses Konto sehen, Merge, Pull Request abrufen, also Pull Request zusammenführen und Merge bestätigen. Diese Änderung wird dem Haupt-Repository hinzugefügt. So tragen wir zum Open-Source-Projekt bei. 84. Lokal und Fork mit Basis-Repository synchronisieren: Wenn wir ein Repository forken, ist dieses Fog-Repository nicht wirklich mit dem Basis-Repository verbunden. Wenn wir also in diesem Fog-Repository an diesem Basis-Repository arbeiten , kann jemand Änderungen übernehmen. Zu diesem Zeitpunkt müssen wir Fog also mit diesem Basis-Repository synchronisieren . Aber wie können wir das machen? Es ist wirklich einfach. Also gehen wir zum Nebel-Repository. Siehst du, hier bekommen wir, dass dieser Zweig zwei Zweige hinter dem Basis-Repository-Zweig liegt, was bedeutet, dass nach unserem aktuellen Code zwei kommen . Auf der rechten Seite erhalten wir also die Option Sync Fog. Hier können wir diese Änderungen vergleichen oder einfach den Branch aktualisieren. Dann haben wir hier eine aktuelle Filiale. Wir können es also einfach in unserem lokalen Repository abrufen. Also starte Git, Fetch. Siehst du, hier bekommen wir einen neuen Commit. Jetzt können wir es einfach mit unserem Master-Commit zusammenführen. Zuallererst werden wir zum Master-Branch wechseln. Gut. Derzeit sind wir im Master-Branch und schreiben Git Merge Origin Master. Und fertig. Wir haben alle Änderungen in unserem lokalen Repository sowie im Fog-Repository. Das ist sehr einfach und es geht nur darum, an einem Open-Source-Projekt zu arbeiten. Dafür gibt es kein Hexenwerk, wir müssen es zwei- bis dreimal üben. 85. Tools für die Zusammenarbeit in VS Code: Sehen wir uns nun einige Tools für die Zusammenarbeit im VS-Code an. In unserem Projekt können wir also sehen, dass wir uns derzeit in der Hauptniederlassung befinden. Lassen Sie mich zur anderen Filiale wechseln. Lassen Sie mich Ihnen jetzt zeigen, wie wir Änderungen auf unsere Fernbedienung übertragen können. In der ReadMe-Datei ändere ich diesen Titel, sagen wir, um mit VSCode zu beginnen Speichern Sie das und jetzt gehen wir zur Quellcodeverwaltung. Schreiben Sie eine Commit-Nachricht, aktualisieren Sie Read Me für VSCode und Commit Jetzt können wir hier sehen, dass wir die Option zum Synchronisieren von Änderungen erhalten. Und wenn wir mit der Maus darüber fahren, heißt es: Push one commit to Origins Design Slash Home Von hier aus können wir also auch pushen. Wenn wir auf diese drei Punkte klicken, erhalten wir auch die Push-Option. Damit erhalten wir auch Pull, Clone Checkout, Fetch und viele weitere interessante Optionen Wenn wir zum Beispiel zu CDs gehen, können wir hier ganz normales Commit machen, nur Stagedateien übergeben, festschreiben, den letzten Commit rückgängig machen und auch über Rebase Wir haben Changes, Pull, Push, Branch, Remote, Stairs, Tags und fast alle Optionen, die häufig in Git verwendet werden Ich möchte dich nicht langweilen, indem ich dir jede einzelne Option zeige. Wir haben diese Optionen bereits über die Befehlszeile gesehen. Also hier drücke ich einfach. Und fertig. Wir veröffentlichen die Änderungen. Ich verwende diese Optionen, wenn ich das Terminal nicht öffnen möchte. Ansonsten verwende ich gerne die Befehlszeile , weil das für mich übersichtlicher ist und ich beim Codieren auch nicht gerne die Maus verwende. Ich weiß nicht warum. Wenn Sie diese Optionen verwenden möchten, ist das auch in Ordnung. Es hängt wirklich von Ihrer persönlichen Wahl ab. Ich bin niemand, der dir sagt, benutze dieses oder jenes nicht. Die Wahl liegt bei dir. Außerdem können wir in der Quellcodeverwaltung unten unsere Kometen, Zweige, Fernbedienungen, Stasis, Tags und den Arbeitsbaum sehen Fernbedienungen, Stasis, Tags und den Arbeitsbaum . Unten sehen wir die Liste der Mitwirkenden dieses Repositorys der Mitwirkenden dieses Repositorys Außerdem können wir von hier aus Mitwirkende hinzufügen. Wenn Sie die Github-Website nicht verwenden möchten. 86. Zusammenarbeit mit Github Desktop: Sehen wir uns nun die Optionen für die Zusammenarbeit in der Github-Desktop-Anwendung an. Deshalb ändere ich hier auch den Titel der Read Me-Datei in Erste Schritte mit der Github-Desktop-Anwendung. Speichern Sie das und lassen Sie mich das mit der Nachricht, Update und der Readme-Datei für Github Dextop Gut. Gehen wir nun zur Github-Desktop-Anwendung über. Derzeit habe ich unser Fog-Repository-Projekt nicht unser Fog-Repository-Projekt in der Github-Desktop-Anwendung geöffnet, also muss ich es öffnen. Also gehe ich zur Datei, füge das lokale Repository hinzu, wähle meinen Ordnerpfad und füge das Repository hinzu. Sehen Sie hier, wir bekommen direkt die Option Push Origin. Sie können dieses Projekt auch mit dieser Schaltfläche auf Github öffnen . Sehr nützliches Tool. Jetzt haben wir oben das aktuelle Repository. Danach haben wir den aktuellen Branch und dann können wir sehen, dass wir die Schaltfläche „Zum Ursprung drücken“ haben, und darunter erhalten wir Details zum Abrufen In der realen Welt, wenn wir bereit sind, unsere Änderungen zu pushen, ist es eine gute Praxis, zuerst Änderungen vom Ursprung zu Auf der rechten Seite haben wir also einen Button. Sehen Sie hier, wir bekommen Patch Origin. Klicke darauf. Und wenn wir Änderungen haben, werden diese Änderungen in unserem Repository gespeichert. Und wenn wir Konflikte haben, können wir unsere Konflikte lösen, bevor wir sie vorantreiben. Und damit müssen wir Merge Kat nicht noch einmal pushen. Mit dieser Methode können wir unseren Cat-Verlauf bereinigen. Jetzt haben wir oben das Repository-Menü und darin wir viele grundlegende Optionen für Git, wie Push, Pull, Fetch, Remove, und unten finden wir die Repository-Einstellungen Ich mag diese Option nur, weil wir hier unser Remote-Repository einfach ändern können Diese Optionen sind also im VS-Code sehr ähnlich. Lustig ist, dass der VS-Code viel mehr Optionen bietet als die Github-Desktop-Anwendung. Und deshalb sage ich Ihnen, dass Github-Desktop-Anwendung eine einfache, grundlegende und anfängerfreundliche Anwendung ist . Lass uns einfach zum Ursprung springen und fertig. Jetzt können wir hier sehen, dass wir eine Vorschau der Pull-Anfrage anzeigen können und wir können auch eine Pull-Anfrage erstellen. Und wenn wir eine neue Pull-Anfrage erstellen, können wir das auf unserer Repository-Seite sehen. Jetzt werden wir in der nächsten Lektion weitere Optionen mit Git Crack und Anwendung sehen . 87. Zusammenarbeit mit GitKraken: Sehen wir uns nun Tools für die Zusammenarbeit an, die Git Kraken verwenden. Zuallererst müssen wir in Git Kraken das Fog-Repository öffnen , da es derzeit nicht geöffnet ist Gehen Sie also hier zur Datei OpenRPO, wir wählen Opener Repository und wählen unseren Repository-Ordner und wählen unseren Jetzt können wir hier sehen, dass wir uns derzeit in der Design-Slesome-Filiale befinden Auf der linken Seite sehen wir den Namen der lokalen Filiale, Remotes und die aktuell aktive Pull-Anfrage, die Von hier aus können wir auch eine Pull-Anfrage erstellen. Danach haben wir Probleme, wählen Sie hier Github aus und wir bekommen die Probleme. Hier können wir auch eine neue Ausgabe erstellen und danach haben wir viel mehr Optionen. Lass mich dir jetzt etwas wirklich Cooles zeigen. Hier haben wir Repositorien. Danach haben wir eine Liste von Branchen , die wir bereits im vorherigen Abschnitt gesehen Danach haben wir ein paar Schaltflächen, die sehr nützlich sind. Als Erstes bekommen wir Undo, was dazu dient, den letzten Anstrich rückgängig zu machen Wenn wir den Mauszeiger über diese Schaltfläche bewegen, können wir sehen, was diese Schaltfläche bewirkt Also machen wir die letzte Mitte rückgängig. Also, hier ist es weg. Lass mich das wiederholen Danach haben wir den Pull-Button, und hier im Pull haben wir viele Optionen Alles abrufen, ziehen, wenn ein Schnellvorlauf möglich ist, nur Schnellvorlauf und Rebase Danach haben wir die Drucktaste und diese Verzweigungsschaltfläche, mit der aus dem aktuell ausgewählten Commit ein Branch erstellt aus dem aktuell ausgewählten Commit ein Branch Jetzt klicken wir hier auf diesen Branch-Namen. Wir können sehen, dass wir auch einen Pull-Request, einen Push-Upstream erhalten , den wir so eingestellt haben , dass der Branch beim ersten Mal gepusht wird. Ebenfalls unten können wir einen Pull-Request für diesen Branch und viele weitere Optionen starten . Hier haben wir nicht viele Optionen, weil wir am Fog-Repository arbeiten und wir nicht direkt zum Basis-Repository pushen können. Lass uns den Pull-Request starten. Hier können wir unseren Zweig aus unseren beiden Ursprüngen auswählen. Aus unserem Fog-Repository, Zweig Design Home, und ihn mit unserem Master-Zweig unseres Basis-Repositorys vergleichen . Jetzt schreiben wir hier den Titel des Pull-Requests, also das Aktualisieren von Read Me in Design Home. Hier können wir auch eine Beschreibung schreiben und von hier aus können wir einfach eine Pull-Anfrage erstellen. Außerdem haben wir die Möglichkeit, die Bearbeitung auf Github fortzusetzen und hier sehen wir, dass wir die Github-Website erhalten. Klicken Sie einfach auf Pool-Anfrage erstellen. Und fertig. Wenn wir einen Konflikt haben, können wir diesen Konflikt hier lösen. Danach können wir diese Änderungen vom Basis-Repository aus mit dem Basis-Repository zusammenführen. Das haben wir schon richtig gesehen. Jetzt gehen wir von meinem zweiten Account aus , der Autor dieses Repositorys ist, zur Pull-Anfrage. Hier haben wir keine Konflikte, also können wir es mit Branch zusammenführen. Und fertig. So können wir mit den darin enthaltenen Corabation-Tools arbeiten, Kraken Aber hier ist meine persönliche Meinung. Wenn wir wissen, was Push, Pull, Upstream-Einstellung, Merge, Rebase und all die Begriffe sind, dann ist die Verwendung der Git-Befehlszeile viel einfacher als die Verwendung einer grafischen Benutzeroberfläche In GUIs können wir den Verlauf deutlich erkennen. Aber für diese Optionen halte ich persönlich die Befehlszeile für eine viel bessere Option Kann unser Chit Sheet jederzeit öffnen und diesen Befehl schreiben. So einfach ist das Wir müssen keine Optionen finden oder wir müssen keine Git Kraken- oder Github-Desktop-Anwendung im Hintergrund öffnen Git Kraken- oder Github-Desktop-Anwendung im Hintergrund Stattdessen können wir einfach das Git Bash-Terminal oder das VS-Code-Terminal verwenden Git Bash-Terminal oder das VS-Code-Terminal Hier dreht sich also alles um Zusammenarbeit in Git. Ich hoffe, du lernst viel aus diesem Abschnitt. Nach dieser Lektion habe ich eine Zusammenfassung als PDF hinzugefügt, und Sie können sie zu Ihrem Chit-Blatt hinzufügen 88. Abschnitt 06 Bereinigung und Organisation der Geschichte: Willkommen zum letzten Abschnitt des ultimativen IT-Kurses. In diesem Abschnitt werden wir sehen, wie wir die Gehhilfen reinigen und organisieren können die Gehhilfen reinigen und organisieren Wir werden also sehen, wie man Commits macht, Kinder belohnt, verlorene Commits wiederherstellt, Commits löscht, Kommandobotschaften ändert, splittet, zerquetscht In einfachen Worten: Wir werden die Commit-Historie oder den Verlauf der Gits neu schreiben. Fangen wir also mit diesem Abschnitt an. 89. Die Commit-Historie neu schreiben: Nun die Frage, die Sie sich vielleicht stellen, warum wir unseren Verlauf neu schreiben müssen Der Grund, warum wir die Historie unseres Projekts schreiben oder speichern , ist, dass wir sehen wollen, wie sich unsere Anwendung im Laufe der Zeit weiterentwickelt Anhand der Historie können wir in diesem Jahr sehen, welche Funktionen wir auf den Markt bringen, welche Fehler wir beheben und wer zu welcher Funktion beigetragen hat und vieles mehr. Stellen Sie sich nun vor, wir sehen zu dem Zeitpunkt, an dem wir unseren Verlauf sehen, eine schlechte Commit-Nachricht. Manchmal übernehmen wir kleine Änderungen, was in einzelnen Commits geschehen kann, oder wir haben wirklich große Amide gemacht , in denen wir zwei Funktionen zusammen implementieren, was nicht gut ist Manchmal möchten wir vielleicht unerwünschte Commits löschen, dann müssen wir dann unseren Commit-Verlauf neu schreiben Aus diesem Grund ist dieser Abschnitt nützlich, um unseren Verlauf sauber und übersichtlich zu gestalten, was ein Zeichen für professionelle Entwickler ist Jetzt fragst du dich vielleicht, ob wir die Commit-Historie von Projekten, die remote sind, neu schreiben sollen Commit-Historie von Projekten, die remote sind, Die Antwort lautet nein. Wir sollten Commits nicht umschreiben, die wir auf Remote übertragen, weil das unser Projekt für andere durcheinander bringt und wir am Ende ein großes Problem In vielen Unternehmen wird nur die höhere Autorität die Geschichte neu schreiben Aber zuerst bringt er oder sie ein Treffen oder informiert alle Teammitglieder darüber, die Geschichte neu zu schreiben Aber als Entwickler können wir die Commit-Historie neu schreiben, lokal sind und nicht per Push an die die Historie neu schreiben, können wir sie übersichtlicher und übersichtlicher gestalten übersichtlicher In der nächsten Lektion beginnen wir mit der Erstellung der Commit-Historie 90. Den Commit im Detail rückgängig machen (RESET): Zuallererst habe ich für diesen Abschnitt ein IT-Projekt namens Course Cartwis entworfen Sie erhalten das Projekt im Ressourcenordner, den Sie Beginn dieses Kurses heruntergeladen haben Sie können diesen Ordner also in der Git Bash oder im Terminal öffnen der Git Bash oder im Terminal Sehen wir uns die Geschichte dieses Projekts an. Siehst du, hier haben wir eine Liste von Commits. Hier wollen wir das Amid rückgängig machen. Das haben wir bereits in den vorherigen Abschnitten gesehen, aber ich möchte nur sichergehen, dass wir kein Thema verpassen. Wie wir für Undo the Amid wissen, verwenden wir den Befehl git reset, und dieser Reset hat drei Optionen LSD soft, LSDs mix, was die Standardeinstellung ist, und hard Lassen Sie mich Ihnen jede Option einzeln erklären. Stellen Sie sich vor, dies ist unser Arbeitsverzeichniscode und wir möchten diesen Code in unserer Git-Historie speichern. Zuerst stellen wir unsere Änderungen vor und dann machen wir Commit. Jetzt, nach einiger Zeit, arbeiten wir daran, einen Fehler im Layoutdesign zu beheben. Wir stellen die Änderungen erneut vor und übernehmen sie. Jetzt wollen wir Commit B rückgängig machen und zu Commit A zurückkehren. Wenn wir Git schreiben und den Softhead auf eins zurücksetzen, macht Git den Commit in der Git-Historie rückgängig. Hier erhalten wir Commit A, aber es wird unseren Arbeitsverzeichniscode und die Staging-Vorwahl nicht berühren unseren Arbeitsverzeichniscode und die Staging-Vorwahl Sie werden dieselben bleiben wie zuvor. Sie wissen, dass diese aktuelle Situation welcher Zustand ist? Wenn wir Änderungen im Arbeitsverzeichnis vornehmen und unsere Änderungen speichern, sie aber nicht festschreiben. Nehmen wir nun an, an der Stelle das Soft ist, schreiben wir mixed, dann macht es unseren letzten aktuellen Commit bis zu einem rückgängig , was ein Commit in der Commit-Historie ist. Außerdem wird unsere Staging-Vorwahl durch einen Com-A-Code ersetzt unsere Staging-Vorwahl durch einen Com-A-Code Trotzdem wird es den funktionierenden Verzeichniscode nicht berühren. Wissen wir, dass dieser Zustand welcher Zustand ist? Richtig. Wenn wir Änderungen im Arbeitsverzeichnis vornehmen, diese Änderungen aber nicht bereitstellen, es Ihnen wirklich gut. Nun, wenn wir den Dash hart schreiben, dann macht es den gesamten Bereich im Head-Bereich rückgängig, bis einer kommt vor dem Head-Commit, was A ist. Kennen Sie diesen Zustand? Richtig. Wenn wir nur Commit A ausführen, befindet sich unser gesamter Code im vorherigen Zustand. Sehen wir uns diese Optionen in Aktion an. Nehmen wir an, wir möchten unseren letzten Commit mit dem vorherigen Commit rückgängig machen . Schauen wir uns zunächst an, was wir bei diesem Commit gemacht haben. Holen Sie sich die Show-Commit-Referenz, also head. Sehen Sie hier in diesem Commit, dass wir den Stil der Punkt-CSS-Datei ändern. Und hier fügen wir diese Codezeilen hinzu. Also schreiben wir zuerst Git Reset, Da Di Soft. Hier schreiben wir unseren Comite hat oder den Pointer, auf den wir uns bewegen wollen Also er, das ist der aktuelle Camttll-Wert , der einen Commit vor diesem Amet ist Wisse, dass dies nur den Commit in der Commit-Historie rückgängig macht und unser Arbeitsverzeichnis und auch den Staging-Bereich nicht berührt Unser Staging-Bereich hat also diese Zeilen, aber unser Amit ist auf die vorherige Version zurückgesetzt Wir können das also anhand des Unterschieds zwischen Staging Area und Commit erkennen des Unterschieds zwischen Staging Area Dafür haben wir den Befehl Git df das cast Siehst du, hier haben wir diese Zeilen. Schreiben wir jetzt Git Reset, DD Mixed, Add Till One. Befehl macht den aktuellen Befehl bis zu einem Befehl rückgängig und macht die Änderungen rückgängig hier aus diesem Befehl Wenn wir hier aus diesem Befehl diesen Test als gemischt entfernen, verwenden wir standardmäßig test as mixed Wir können dies überprüfen, indem wir den Unterschied zwischen Arbeitsbereich und Bereitstellungsbereich Wir können den Git-Status oder auch GTF verwenden Siehst du, hier haben wir diesen Unterschied. Schauen wir uns nun die letzte Option an, nämlich Zurücksetzen, da ist dieser harte Kopf bis eins. Jetzt wird unser All-A-Code auf diesen Kopf zurückgesetzt bis eins. Wenn wir nun den DF sehen, sehen wir hier keinen Unterschied, weil gesamte Bereich bis auf einen Kometen auf Kopf zurückgesetzt wird Also hier sind unsere letzten drei Commits weg, weil wir den Reset-Befehl dreimal ausgeführt haben Auf diese Weise können wir den Commit für einen bestimmten Commit rückgängig machen. 91. Rückgängig machen der Commits: In der vorherigen Lektion haben wir gesehen, wie wir den Mantel lösen können. Sehen wir uns nun die Umkehrung von Amiden an. Stellen Sie sich vor, wir haben zwei Amide in unserer Geschichte, die wir auf Github veröffentlicht haben Jetzt können wir diese Amide nicht mehr rückgängig machen und sie erneut pushen. Es wird dem Code für alle unsere Teammitglieder entsprechen. In dieser Situation verwenden wir also Revert, was bedeutet, dass wir die Änderungen, die durch unser Auslassen B vorgenommen wurden, rückgängig machen und ein neues Kamed erstellen Zurücksetzen bedeutet, zur vorherigen Version zurückzukehren, aber ohne vorherige Amide aber ohne Sehen Sie sich das praktisch an. Hier haben wir also unsere Commit-Historie, und ich möchte die Änderungen rückgängig machen , die dieser dritte Komet vorgenommen hat Imaginär, wir denken, dass das alles auf die Fernbedienung übertragen wird, also können wir Git Reset nicht verwenden Also verwenden wir hier Git Reword und hier schreiben wir eine Commit-Referenz, welche Commit-Änderungen wir rückgängig machen wollen, das ist dieser Camt-Kopf Wenn wir Kopf bis eins schreiben, werden die Änderungen rückgängig gemacht, die der zweite Cate Hier können wir auch mehrere Commits mit einem Kometen rückgängig machen. Wenn du alle Änderungen rückgängig machen willst , die durch diese spezielle Reihe von Kometen vorgenommen wurden, dann können wir so etwas schreiben Zuerst schreiben wir die Commit-Referenz, einen Commit darunter , also er bis vier Doppelpunkt, hier schreiben wir den letzten Commit, also Head. Denken Sie daran, unabhängig davon, welchen Commit wir zuerst schreiben, es dauert die Commits nach diesem Coat bis zum letzten Commit Dieser Befehl macht die durch diese vier Commits vorgenommenen Änderungen rückgängig und erstellt neue vier Jetzt fragt Git für jedes neue Prämien-Amid nach einer Commit-Nachricht Ich möchte die Commit-Nachricht nicht ändern, also schließe ich einfach jede Datei und fertig. Schauen wir uns jetzt unseren Verlauf an. Siehst du, hier bekommen wir vier Belohnungs-Cams. Wie wir sehen können, macht die Rücknahme mehrerer Amide unsere Geschichte Gibt es eine andere Lösung , die dieses Chaos beseitigen kann? Ja, es gibt eine Pause. Anstatt diese vier Belohnungskometen einzeln zu erstellen , können wir diese Änderungen rückgängig machen und sie in Single Met umwandeln Lassen Sie uns also zuerst diese vier Medikamente entfernen . Wir wollen sie nicht Hier können wir Reset verwenden, da diese vier Amide nicht im Remote-Repository gespeichert sind Wir werden Gate-Resets also hart einsetzen und dort, wo wir unseren Kopf bewegen wollen Richtig, wir wollen hierher ziehen. Also er, das ist Kopf bis eins, Kopf bis zwei, bis drei bis vier. Also geh bis vier. Schauen wir uns jetzt unsere Geschichte an. Siehst du, hier machen wir diese vier Ameten rückgängig. Lassen Sie uns diese vier Kometen wieder rückgängig machen, aber wir werden nur einen Gameten erzeugen Wir schreiben Git, revert, dn, das amet und hier schreiben wir unsere Kameit-Referenz Kopf bis vier Doppelpunktkopf. Sehen Sie hier, wir bekommen nichts, aber wir können sehen, dass wir gerade dabei sind, alles rückgängig zu machen Derzeit macht Git alle Änderungen, die in diesen vier Befehlen vorgenommen wurden, rückgängig und platziert diese Änderungen in den Staging-Bereich Das können wir mit Git Status S. S überprüfen, hier erhalten wir drei Dateien mit D, das gelöscht wurde und eine mit modifiziertem und auch tamp, das Wir machen die Änderungen im Staging-Bereich rückgängig. Wenn Sie sich die Änderungen ansehen oder weitere Änderungen vornehmen möchten, können wir dies hier tun Derzeit wollen wir nichts tun, also können wir Get revert schreiben Hier haben wir zwei Möglichkeiten. brechen das Revert ab, oder wir können das Revert fortsetzen, was dazu führt, dass wir das Revert in einem einzigen Wir fahren mit der Nachricht „Frage nach dem Commit“ fort. Hier haben wir nur die letzte Commit-Nachricht zum Zurücksetzen. Wir können hier schreiben und als Letztes für Coit zur Verkostung zurückkehren. Speichern Sie diese Datei und schließen Sie sie. Zurück zum Terminal, siehe Zurücksetzen ist abgeschlossen. Und in der Geschichte gibt es auch nur eine Umformung bei. Wie Sie sehen können, sind unsere drei Dateien jetzt weg. Für den Moment setzen wir das wieder zurück, weil ich Ihnen nur die Demo von Revert zeigen möchte, aber wir könnten diese Camtes in Zukunft benötigen Also setz dich zurück, da ist dieser harte Kopf bis eins und fertig. In der nächsten Lektion werden wir p log sehen. 92. Reflog für verlorene Commits: Stellen Sie sich nun vor, wir setzen unseren Code auf mystische Weise auf bis drei Hier können wir unsere Kometengeschichte überprüfen. Siehst du, wir haben unsere ersten drei Mets verloren. Was ist, wenn wir diese Ameisen zurückholen wollen? Nun, hier könnte man sagen, dass wir das verloren haben. Wie können wir es zurückbekommen? In Git verlieren wir wirklich nichts. Speichere sie im Repository und wenn diese verlorenen Kometen für eine lange Zeit weg bleiben, entfernt nur Git diese Kometen Wenn wir unseren Code zweimal zurücksetzen, wird Git diese Kometen nicht sofort entfernen Hier führen wir Git Rf Log aus, das die vollständige Form des Referenzprotokolls ist Dieser Befehl zeigt die Referenz unseres Standard-Kopfzeigers an. Im Grunde zeigt es uns, wie sich unser Kopfzeiger in unserer Geschichte bewegt. Oh, was sehen wir gerade? Fühlst du dich so verwirrt? War nur ein Scherz. Das ist wirklich einfach Lass mich dir das erklären. Das zeigt nur, wie sich unser Kopfzeiger bewegt. Zuerst erhalten wir Commit a, dann die Einheitenkennung für diesen Punkt und dann die Beschreibung dieser Aktion. Ganz am Anfang habe ich zehn Gameten direkt hintereinander gemalt. Mit jeder Gamete bewegt sich unser Kopf. Danach führen wir in der ersten Lektion diesen Befehl git reset dreimal aus Dann haben wir viermal zurückgesetzt und dann zurückgesetzt, Camt und Reset Das Gute daran ist, dass wir alle Kometen hier haben. Und in dieser Lektion haben wir Lee auch versehentlich zurückgesetzt. Wir müssen also nur unseren Mauszeiger auf diese vorherige Referenz bewegen und schon haben wir den verlorenen Kometen Also wurde zurückgesetzt, D schwer. Hier schreiben wir unsere grobe Log-Referenz oder wir können diese Commit-ID sagen, oder wir können auch diese Commit-ID verwenden. Kopf in Kalibrakets. Wenn wir jetzt unsere Commit-Historie überprüfen, bekommen wir unsere verlorenen Was wir daraus lernen Wenn wir den Befehl git reset ausführen, entfernt Git diese Kometen nicht wirklich Verschiebe einfach Headpointer und füge diese Commits irgendwo in Wenn wir diese Befehle für eine lange Zeit nicht berühren, entfernt nur Git diese Befehle entfernt nur Git diese So stellen wir unsere verlorenen Befehle mithilfe von f log wieder her. Nun, die eine Frage, die mir viele Studenten stellen, ist, können wir nur das Headpointer-Referenzlog sehen oder können wir jedes Zeiger-Referenzlog sehen . Sie haben Recht, mit dem Befehl Git flog haben Sie recht, wir können jedes Zeiger-Referenzprotokoll Recht, mit dem Befehl Git flog haben Sie recht, sehen Derzeit haben wir keine Filiale. Ich zeige dir das F-Log dieses Master-Pointers. Git flog show, und hier schreiben wir unseren Zeigernamen, der Master ist Wir haben einen Zweig namens Feature Cart, dann schreiben wir hier Feature S Cart. Sehen Sie hier, wir bekommen das Referenzprotokoll für Master Pointer. Es ist dasselbe wie bei Kopfzeigern , weil sie sich in dieser Historie zusammen bewegen. Derzeit sehen wir alle Referenzen oder wir können den vollständigen Verlauf sehen. Was ist, wenn wir nur die letzten fünf Momente unseres Masterzeigers sehen wollen? Wir können hier einfach N Leerzeichen schreiben. Hier schreiben wir fünf. Siehst du, hier haben wir nur letzten fünf Momente unseres Masterzeigers. Das ist sehr nützlich, dreht sich alles um Ref Log. In der nächsten Lektion werden wir sehen, wie wir Änderungen an den vorhandenen Comi vornehmen können 93. Den letzten Commit ändern: Sehen wir uns nun den Befehl Amend an. Ändern heißt also Korrektur. Wir können unseren letzten Befehl korrigieren , ohne einen neuen Befehl zu erstellen. Lass es mich dir zeigen. Also hier in der Indexpunkt-ML-Datei ändern wir einfach den Titel Cartwig Modern Ecommerce Store Speichern Sie die Änderungen weniger als diese Änderungen und bestätigen Sie diese Änderung mit einer Commit-Nachricht, Titel der Anwendung aktualisiert wird Jetzt haben wir unseren Commit gemacht, und ich finde, dass wir in unserem Titel dieses W in der Cardi-Schreibweise groß schreiben müssen und dass wir auch einen Bindestrich zwischen E und Commerce hinzufügen möchten Bindestrich zwischen E und Commerce hinzufügen möchten Hier wollen wir für diese winzige Änderung kein neues Camt erstellen für diese winzige Änderung kein neues Camt Hier können wir den Befehl Amend verwenden. Wir nehmen Änderungen an unserem Titel vor, speichern diese Datei und lassen uns diese Änderungen beibringen. Für Gamat schreiben wir Gate KamitF ändern, wir fügen einfach Hier schreiben wir unsere neue Commit-Nachricht. Außerdem, wenn Sie dieselbe Commit-Nachricht wie die vorherige Commit-Nachricht verwenden möchten , dann schreiben wir hier nichts. Siehst du, hier bekommen wir die vorherige Commit-Nachricht. Schließ das und fertig. Wir aktualisieren unser letztes kommt. Wenn wir überprüfen wollen, was wir in unserem letzten Commit geändert haben, dann können wir Git Show schreiben. Siehst du, hier bekommen wir einen aktualisierten Titel. Nun, eine Sache, die ich klarstellen möchte, ist, dass der letzte Commit nicht wirklich aktualisiert wird. Erstellt offiziell einen neuen Befehl weil Git-Commits unveränderlich sind. Das heißt , wenn wir einen Commit erstellen, kann Git ihn nicht ändern Aber hier sieht es so aus, als würde es den letzten Commit ändern. Was ist nun, wenn wir eine Datei zum vorherigen Commit hinzufügen wollen? Dafür müssen wir den gleichen Prozess durchführen , den wir gerade gemacht haben. Hier in unserem Projekt erstellen wir eine neue Datei, scrape dot js und darin einfach Console Dot Log Das ist eine Skriptdatei. Speichern Sie diese Datei und kehren Sie zu Git-Pass zurück. Hier wir unsere Änderungen und können einfach Git commit, dd amend verwenden. Lassen Sie uns die Commit-Nachricht nicht ändern. Lassen Sie uns nun unseren letzten Commit überprüfen. Wie können wir nun, wenn wir in unserem letzten Commit eine neue Datei hinzufügen, die Datei entfernen? Es ist ein bisschen knifflig. Dafür verwenden wir zuerst Reset, und hier verwenden wir die gemischte DDs-Option weil wir nur unseren Commit-Verlauf zurücksetzen wollen. Außerdem setzen wir von der Phase aus zurück, Außerdem setzen wir von der Phase aus zurück unser Arbeitsverzeichnis bleibt unverändert wie zuvor, der Lehrbereich und der Commit werden zurückgesetzt Lassen Sie sich also wie bei Mixed zurücksetzen und fahren Sie bis eins fort. C, wir entfernen die Änderungen und in der Indexpunkt-STML-Datei erhalten wir unseren Titel So können wir diese temporäre Datei löschen und jetzt können wir unsere Änderungen speichern . Und anstatt Git commit, amend zu verwenden, verwenden wir Simple Commit, weil wir unseren letzten Commit zurücksetzen und ihm auch eine Nachricht geben, Titel der Anwendung aktualisieren und eine Skriptdatei erstellen und fertig So funktioniert der Befehl Amend also. Was ist nun, wenn wir eines dieser Commits ändern wollen, und das werden wir in der nächsten Lektion sehen 94. Einen beliebigen Commit in der Geschichte ändern: In der vorherigen Lektion haben wir also gesehen, wie wir unseren letzten Kometen ändern können Aber was ist, wenn wir ein vorheriges AT ändern wollen? Sagen wir diese bei Styles for Index STML Body. In diesem Zusammenhang möchten wir die Hintergrundfarbe unseres Körpers ändern . Wie können wir das also tun? Es ist wirklich einfach. Lassen Sie uns zuerst überprüfen, was wir an diesem Mantel ändern. Also zeig uns d35, CB 01. Siehst du, hier können wir sehen, dass wir Stil für den Körper hinzufügen, aber ich möchte diese Hintergrundfarbe ändern Hier werden wir den Rebase-Befehl verwenden. Lassen Sie mich Ihnen erklären, was Basisbefehle tun. Stellen Sie sich vor, wir haben sechs Commits A bis F und wir wollen Commit ändern, sagen wir C. Wir müssen auf Commit B rebasen, weil Commit C base Commit B ist. Also hier nehmen wir Änderungen an unserem Commit C vor, und wie wir wissen, sind Git-Commits unveränderlich Git kann den Commit nicht ändern. Git erstellt einen neuen Commit, der unsere Änderungen enthält, und erstellt ihn dann mit Commit B. Du fragst dich vielleicht, wie Git C-Commit durch Commit C ersetzen kann ? Und was ist mit Commit D, E und F? Die Antwort lautet: Git ersetzt den Commit C nicht durch C. Anstatt Commit C zu ersetzen, erstellt Git hier Commit, genau wie dieser Commit D, aber dieser Commit hat auch die Änderung, die wir bei CDs machen. Wenn Git diese Änderung beim nächsten Commit entfernt, was hat das dann für einen Sinn? Deshalb ist Git Pi genau derselbe Commit wie Commit D, aber mit Änderungen. Das Gleiche gilt für Commit E und Commit F. Git entfernt diesen vorherigen Branch, und so können wir mithilfe von Git Rebase jeden Commit in unserer Historie ändern Achte aber darauf, dass wir nur die Commits ändern, die nicht gepusht wurden , weil Rebase die Historie eindeutig neu schreibt Sehen wir uns nun Rebasing in Aktion an. Also hier, welches Commit wir ändern wollen. Schreib diesen. Also kopieren wir die Commit-ID ihrer Basis, die der vorherige Commit ist. Denken Sie immer daran, dass wir beim Rebase die vorherige Commit-Referenz verwenden müssen Für Rebase schreiben wir Git Rebase I für Interactive. Im Grunde wollen wir es Git sagen. Wir wollen interagieren oder Änderungen an unseren Commits vornehmen. Und hier schreiben wir unseren Basis-Commit , der 4239 CEC ist Sehen Sie hier in unserem Code-Editor, wir bekommen diese Art von Schnittstelle Im Moment verwenden wir diese Schnittstelle nicht, weil sie Sie verwirren wird Wir werden in den nächsten Lektionen sehen, wie man diese Schnittstelle benutzt in den nächsten Lektionen sehen, wie man diese Schnittstelle Hier haben wir von unten zur Textoption gewechselt. Hier bekommen wir diese Art von Linien. Mach dir keine Sorgen. Das sind nur Skripte , die Git ausführen wird, und das sind alles Medikamente aus unserer alten bis zur letzten Commit-Reihenfolge Hier am Anfang jedes AMets haben wir die PC-Option, was bedeutet, dass Git einfach diese Kometen aus der Historie auswählt und Was ist nun, wenn wir diesen Amet ändern wollen? Am Ende der Datei finden wir also viele Optionen und deren Erklärung Für die Bearbeitung am Ort des Höhepunkts schreiben wir also Bearbeiten. Jetzt wollen wir keine anderen Amide bearbeiten, aber wenn wir das wollen, dann können wir auch hier schreiben, bearbeiten, diese Datei speichern, beide Dateien beifügen Siehst du, hier halten wir bei diesem Camt zur Bearbeitung an, und wir sind gerade dabei, einen von fünf umzubauen, und wir können sehen, dass wir diesen Commit jetzt ändern können Jetzt können wir also ändern, was wir an diesem Mantel ändern wollen. In der Style-Dot-CSS-Datei möchte ich die Hintergrundfarbe auf Weiß ändern. Und Farbe hat 101010. Speichern Sie die Änderungen und lassen Sie uns diese Änderungen probieren. Und auch Gt ka Mate, Dash, Dash, Amend. Entschuldigung, es ist ein Tippfehler. Also Gate Coat, Dash, Dash, Aendern. Wir fahren mit der Auslassen-Meldung fort. Also schließ das Sehen wir uns jetzt die Geschichte an. Siehst du, wie ich dir schon sagte, Git hat einen neuen Zweig gestartet, und das ist unsere Basis. Und hier oben bekommen wir unseren aktualisierten Amend Camt. Wenn wir nun mit dem Rebase fortfahren , dann wählt Git diese Amide aus und legt sie auf diesen Camt und entfernt dann diese Um dieses Rebasing fortzusetzen, schreiben wir Git Rebase, fahren wir Oder wenn wir darüber schreiben wollen, dann können wir darüber dann können wir Lassen Sie uns vorerst mit dieser Rebase fortfahren und wir haben keine weiteren Änderungen. Git schließt diesen Vorgang schnell ab Schauen wir uns jetzt unseren Verlauf an. Hier können wir sehen, dass unsere Geschichte wieder linear ist. Wenn Sie beobachten, stellen Sie fest, alle Kometen-IDs von denen früherer Kometen unterscheiden Es ist also bestätigt, dass Git neue Kometen erzeugt. Aber wie wir wissen, dient dies der Organisation der Geschichte. Wenn wir das nun in unserem Code sehen, erhalten wir diese Änderungen auch in unserer Style-Dot-CSS-Datei. Die Änderungen, die wir dahingehend ändern, dass Camt auch in diesen Amiden verfügbar ist So ändern wir jedes Camd, indem wir Git Rebase I verwenden. 95. Wie man den gesamten Commit verlässt: Löschen einer ganzen Katze ist nützlich, wenn wir unsere Arbeit versehentlich übergeben Aber wenn wir einen Kameten fallen lassen, müssen wir bedenken, dass wir damit alle Änderungen, die wir an diesem Kometen vorgenommen haben, verwerfen alle Änderungen, die wir an diesem Kometen vorgenommen haben In unserer Geschichte haben wir an dieser Arbeit gearbeitet, was ich bisweilen getan habe Mal sehen, was ich dabei begehe. Zeig AC eine 49c Zeig AC Hier können wir in der ML-Datei mit dem Indexpunkt sehen. Anstelle dieses Textes fügen wir dieses He-Tag hinzu, und in der Style-CSS-Datei fügen wir diesen Stil für einen Abschnitt hinzu. Wenn wir diesen Befehl nun löschen, werden diese Änderungen gelöscht. Also werden wir auch zum Löschen Rebase verwenden. In unserem vorherigen Beispiel haben wir sechs Commits, und wenn wir diesen Commit C löschen wollen, dann verwenden wir Gate Rebase I, und hier beginnen wir mit Base, also Commit B. Und dann löschen wir diesen Commit C. hier erstellen wir wieder einen neuen Commit für Commit D, E und F und ersetzen ihn dann durch Commit B, das ist Was ist nun, wenn wir in diesem Commit C eine Datei namens Seiten-DML erstellen In allen drei dieser Commits ändern wir etwas in dieser Datei Dann kommt es zu einem Konflikt , denn wenn wir Commit C löschen, wird auch unsere pg-ML-Datei Und in unseren anderen Commits nehmen wir Änderungen an dieser Page Dot S DML-Datei Dann kommt es hier zu Konflikten. Keine Sorge, wir werden das Problem lösen, da es das Merge-Tool verwendet. Es ist auch sehr einfach. Ich sage Ihnen nur, dass Konflikte auftreten können, wenn wir unser Commit fallen lassen. In unserem Beispiel haben wir hier diese Änderungen. Lassen Sie uns diesen Commit fallen lassen und sehen, ob es zu Konflikten kommt oder nicht. Was denkst du? Lass uns sehen. Also schreiben wir zuerst Git Rebase I und hier schreiben wir unsere vorherige Commit-ID, die unsere Basis ist Auch hier gehen wir zur Umstellung auf Text über und hier bekommen wir diese Skripte Jetzt wollen wir diesen Mantel an der Stelle dieses Gipfels fallen lassen, wir schreiben Drop oder wir können das ganze at aus dem Skript entfernen , die Änderungen speichern, diese Dateien schließen und hier sehen wir, dass wir erfolgreich rebase bekommen , wenn wir unsere Historie überprüfen und dann sehen, dass der Arbeitsfortschritt Kate weg ist, weil wir keinen Konflikt bekommen Lassen Sie mich Ihnen zeigen, was wir tun sollen, wenn es zu Konflikten kommt , denn das könnte Sie verwirren und ich möchte nicht, dass Sie verwirrt werden Hier in unserem Ordner „Projekt im Components“ erstellen wir eine neue Datei namens myders dot HTML Fügen Sie in dieser Datei einfach H ein Tag hinzu, und das ist meine Bestellseite Die Änderungen und lassen Sie uns diese Änderungen vornehmen. Holen Sie sich außerdem die DML-Seite mit dem Punkt „Meine Bestellung erstellen“. Gut. Jetzt ändern wir wieder etwas in dieser Datei. also im ST-Tag an, Nehmen wir also im ST-Tag an, dies ist die Liste der Bestellungen. Speichern Sie die Gene und lassen Sie uns das Ganze auch in Szene setzen und es auf der Seite Nachrichtenaktualisierungen für Bestellungen bestätigen. Sehen wir uns nun unsere Geschichte an. Nehmen wir an, wir wollen diesen zweiten Commit löschen. Also machen wir Git Rebase I und übergeben die ID unserer Basis, die 9981 e53 ist Stellen Sie sicher, dass Sie Ihre Commit-ID schreiben. Hier bekommen wir wieder Skripte in unserem Code-Editor. Wir möchten dieses Commit löschen, damit wir dieses Commit von hier entfernen können. Speichern Sie diese Datei und lassen Sie uns auch diese Datei schließen. In der Git Bash, hier kommt es zu Konflikten, weil wir unseren Commit löschen und in diesem Befehl alle Änderungen verwerfen, was bedeutet, dass wir eine Moder-Punkt-HTML-Datei erstellt haben Wir haben meinen Ordnungspunkt sdmlFle entfernt und beim nächsten Commit nehmen wir Änderungen an derselben Datei vor. Deshalb bekommen wir Konflikte. Die meiste Zeit sind wir nicht mit dieser Situation konfrontiert. Aber wenn es manchmal vorkommt, dann können wir es so machen. Wir können unseren Status überprüfen, indem wir den Git-Status als a, C verwenden. Hier erhalten wir D und U, was Löschen und Aktualisieren bedeutet. Um diese zu lösen, schreiben wir hier einfach das Git Merge Tool. Siehst du, hier bekommen wir den Merge-Konflikt für Komponenten gelöscht Slash Moder Punkt stml Local ist gelöscht und remote, was auf andere Commits hinweist In diesen haben wir Änderungen vorgenommen. Also für modifiziert können wir A schreiben, für Löschen schreiben wir D und für Abort können wir A schreiben. Hier wollen wir unsere Datei nicht löschen Wir entscheiden uns für Modify, weil wir diese Moder-Seite in unserem Cmd behalten wollen diese Moder-Seite in unserem Cmd behalten Wenn wir jetzt noch einmal unseren Status überprüfen, werden wir hier hinzugefügt und wir erhalten diesen Moder Dot StML Punkt ORIG, das ist die temporäre Datei , die Gate während eines Konflikts Wir können das ignorieren oder wir können es auch aus unserem Projekt löschen Lassen Sie uns nun unseren Rebase-Prozess mit rebased Continue fortsetzen mit rebased Lass uns mit derselben Nachricht weitermachen und fertig. Wenn wir jetzt noch einmal unsere Historie überprüfen, stellen wir fest, dass unser Amid erfolgreich abgeschaltet wurde. So lassen wir also unseren Amid fallen. In der nächsten Lektion werden wir sehen, wie wir nur die Commit-Nachricht ändern können. 96. Commit-Nachricht ändern: , ich möchte in unserer aktuellen Historie Nehmen wir an, ich möchte in unserer aktuellen Historie die Commit-Nachricht dieses zweiten Commits ändern , weil die Nachricht nicht klar ist. Was meinen Sie mit Änderungen an der Indexstrategie ML, die sich ändern Und diese Art von Commit-Nachricht kann für viel Verwirrung sorgen. Es ist also immer besser, diese Nachrichten zu ändern, damit unsere Geschichte aussagekräftig aussieht. Lassen Sie mich zunächst sehen, was ich bei diesem Commit tatsächlich gemacht habe. Das habe ich wirklich vergessen. Hol dir Show D sechs, eine 7d59 Okay, hier füge ich diesen Abschnitt mit der Produktliste hinzu. Um die Commit-Nachricht zu ändern, verwenden wir hier also auch Rebase Holen Sie sich Rebase I und hier schreiben wir unsere Base-Commit-ID, die 61a8 71 lautet Sie nur daran, dass der Base-Commit immer ein Commit ist , der dem Commit vorausgeht , den wir rebasen wollen Auch hier bekommen wir das Skript. Jetzt schreiben wir für die Änderung der Commit-Nachricht an der Spitze eine Belohnung. Hier können wir auch mehrere Befehle umformulieren. Nehmen wir an, diesen letzten Befehl möchten wir umformulieren. Wir schreiben hier umformulieren. Wenn wir diese Datei jetzt schließen, werden wir nach der aktualisierten Commit-Nachricht gefragt der aktualisierten Commit-Nachricht , für welche Befehle wir reword hinzufügen Lassen Sie mich Ihnen zeigen, wie Sie diese Dateien speichern und schließen. Siehst du, ich bitte um eine Commit-Nachricht für unseren ersten Befehl. Hier schreiben wir das Hinzufügen eines Abschnitts mit der Produktliste in die DML-Datei mit Indexpunkt Speichern Sie das und schließen Sie diese Datei. Und wieder können wir eine Commit-Nachricht für unseren letzten Commit schreiben , für den wir eine Belohnung erhalten. Ich bin mit dieser Nachricht zufrieden. Also lass uns loslegen und fertig. Wenn wir jetzt unseren Verlauf überprüfen, sehen Sie, hier bekommen wir eine aktualisierte Commit-Nachricht. Hier möchte ich euch noch einmal sagen, dass wir, wenn wir Rückzahlungen machen, erneut diesen Camt erstellen und wenn dieser Commit neu erstellt wird, werden alle Mäntel neu erstellt alle Mäntel Es ist also ganz klar, dass wir die Geschichte neu schreiben. Es ist okay, wenn wir Gameten in unserem lokalen Repository haben, aber wir sollten keine Gameten ändern, die bereits im Remote-Repository gespeichert sind 97. Positionen von Commits ändern: nun in unserer Historie Wenn wir nun in unserer Historie Commits nach oben und unten verschieben wollen, nehmen wir an, dass wir hier den Titel der Anwendung aktualisieren und die Skriptdatei Commit erstellen Wir möchten diesen Commit im Indexpunkt SDMLKit unter diesen Anzeigenklassennamen verschieben im Indexpunkt SDMLKit unter diesen Anzeigenklassennamen Also hier fangen wir wieder mit dem Rebasing an, get rebasi . Hier schreiben wir den Namen des Basiskometen, wo wir unsere Gameten Nehmen wir an, wir haben zehn Kometen, wir wollen die sechs Kometen nach der dritten Begegnung verschieben In dieser Situation beginnen wir mit der Umbenennung von Komet zwei, weil das dann die Basis sein wird Nehmen wir nun an, wir wollen die sechs Kometen nach acht Kometen platzieren , dann beginnen wir mit der Umbasierung bei den sechs Kometen dann beginnen wir mit der Umbasierung Um die Position des Endlagers zu ändern, beginnen wir immer mit dem Rebasing Deshalb beginnen wir hier mit dem Rebasing von dieser Position aus. Neun E vier, CD drei D. Unser Rebase-Skript enthält also all diese Kats Jetzt können wir die Zeilen einfach in der Reihenfolge verschieben, in der wir das Repository neu anordnen wollen Wir gehen also zur aktualisierten Titel- und Skriptdatei Cat und indem wir einfach die Alt- oder Wahltaste und die Pfeiltaste nach oben und unten gedrückt halten , können wir die Position der Mäntel in der Historie ändern, sie an den Anfang der Historie verschieben und diese Datei speichern und diese Dateien durchkreuzen Siehst du, hier bekommen wir ein erfolgreiches Rebase. Schauen wir uns unsere Geschichte an. Sehen Sie sich das an, bewegen Sie sich nach unten, damit wir die Position unserer Ameisen ändern können. In der nächsten Lektion werden wir sehen, wie wir zwei oder mehr Ameten zu einem einzigen Amet zusammenfügen können zwei oder mehr Ameten zu einem einzigen Amet zusammenfügen 98. Zwei oder mehr Commits zerschlagen: Schauen wir uns nun an, wie wir zwei oder drei Kometen kombinieren können. Hier in unserer Geschichte können wir also sehen, wie der Indexpunkt-SML-Datei ein Klassenname hinzugefügt und Stile für den Index-DotLFLE-Hauptteil hinzugefügt Stile für den Index-DotLFLE-Hauptteil Diese beiden Codes können zu einem einzigen Kometen kombiniert werden , weil das derselbe Prozess ist Also werden wir sie miteinander kombinieren. Hier starten wir wieder den Rebase-Prozess von hier aus. Holen Sie sich also Rebase I sechs F EA drei F acht. Auch hier wechseln wir zum Text. Jetzt wollen wir diesen zweiten Commit zu unserem ersten Commit kombinieren . Für den zweiten Commit an der Spitze schreiben wir also Squash Wenn wir auch diesen dritten Commit zu diesen beiden kombinieren wollen , dann können wir hier auch Squash schreiben. Im Moment wollen wir das nicht, also kehren wir noch einmal zu Peek zurück Speichern Sie diese Datei und schließen Sie diese Dateien. Jetzt wird Git uns nach der neuen Commit-Nachricht fragen. Hier bekommen wir alle Commit-Nachrichten, welche Commits wir zerquetschen Also hier wähle ich diese erste Commit-Nachricht und entferne die zweite Außerdem können wir diese Commit-Nachricht ändern, um Stile für Indexpunkt-STML hinzuzufügen Speichern Sie diese Datei und schließen Sie sie. Sehen Sie hier, dass unser Rebase erfolgreich abgeschlossen wurde. Sehen wir uns unsere Geschichte an. Siehst du, wir haben in unserer Comte-Geschichte nur einen Komaten. Nehmen wir nun an, wir kombinieren diese Mäntel mühsam . Was ist, wenn wir die letzte Rebase rückgängig machen wollen? Also hier verwenden wir Gid Raf Log. Hier können wir oben sehen, wir Rebase fertig haben Danach haben wir Peak, Peak, Peak, Squash und Rebase Also müssen wir zu diesem Camt wechseln, wo wir unseren vorherigen Rebase beenden Kopieren Sie diese Cait-ID und gehen wir nach unten Und hier schreiben wir Git, setzt hart auf diese Schauen wir uns unsere Geschichte an. Siehst du, wir haben wieder diese zwei getrennten Kamts. Der Grund, warum wir diesen Kürbis rückgängig machen, ist dass es eine andere Möglichkeit gibt, unsere Amide zu kombinieren Wir schreiben wieder, holen uns Base I, unser Base-Amet, hier bekommen wir ein Rebase-Script Jetzt wo wir Squash schreiben, können wir Fix up schreiben Jetzt fragst du dich vielleicht, was ist der Unterschied zwischen Squash und Fix Up Sie sind also fast gleich. Aber wie wir wissen, haben wir, wenn wir Squash verwenden, danach die Möglichkeit, eine Commit-Nachricht für diesen kombinierten Commit zu schreiben Commit-Nachricht für diesen kombinierten Commit Aber wenn wir Fix up verwenden, haben wir nicht die Möglichkeit, eine Commit-Nachricht zu schreiben Wählen Sie die erste Commit-Nachricht als kombinierte Commit-Nachricht aus. Hier ist unser erster Commit des kombinierten Repositorys dieser. Es wird also diese Commit-Nachricht auswählen. Speichern Sie das und schließen Sie die Datei. Siehst du, schließt den Rebase-Prozess automatisch ohne nach einer Commit-Nachricht zu fragen, und wir bekommen diese Nachricht in unserer Historie In der nächsten Lektion werden wir sehen, wie wir einen einzelnen Commit in zwei oder mehr Commits aufteilen können einzelnen Commit in zwei oder mehr Commits 99. Commits aufteilen: Sehen wir uns nun das letzte Thema der Neuschreibung der Commit-Historie an , bei der große Ametes in kleine Camets aufgeteilt werden Hier in diesem Camt erstellen wir eine CAT-Seite und auch eine Benutzerprofilseite Das kann ein großer Kummet sein. Wir können diesen einzelnen Camt in zwei Kometen aufteilen, einen für die CAT-Seite und einen für die Benutzerprofilseite Hier liegt unsere Basis Camt ebenfalls einen Kometen vor diesem. Lass mich dir einen anderen Weg zeigen, wie du Previous Amid schreiben kannst. Hier wählen wir unseren aktuellen Commit aus und kopieren seine ID. Jetzt schreiben wir, git rebase, ich übergebe die aktuelle Commit-ID, und wenn wir den vorherigen Commit vergessen, verwenden wir hier das Karatzeichen. Das bedeutet diesen Commit. Hier wechseln wir zum Text. Nun, dieses Amit wollen wir teilen. Also hier schreiben wir, bearbeiten am Ort des Höhepunkts Also, wenn wir diese Datei schließen, bleibt sie bei diesem Commit, und dann können wir mit dem Reset-Befehl unsere AMMTS trennen Lass es mich dir praktisch zeigen. Speichern Sie diese Datei und schließen Sie sie. Siehst du, wir befinden uns gerade im Umbasing-Prozess. Schauen wir uns an, wo wir uns in unserer Geschichte genau befinden. Git log, sieh mal, momentan sind wir bei diesem Camt , weil unser Kopf hier ist. Jetzt wollen wir den Reset-Befehl verwenden, um unseren aktuellen Comite-Code aus dem Staging-Bereich und auch aus unserem Amet zu entfernen unseren aktuellen Comite-Code aus dem Staging-Bereich und auch aus dem Staging-Bereich und auch aus Hier schreiben wir git reset, soft, aber das entfernt nur unseren Code Ich möchte den Code auch aus unserem Staging-Bereich entfernen. Dafür schreiben wir hier, ist gemischt. Jetzt setzen wir den aktuellen Commit-Code auf welchen Commit-Code zurück Wir werden zum vorherigen Kometen zurückkehren. Kopf, Dachkammer. Jetzt haben wir in unserem Arbeitsverzeichnis alle Änderungen, die wir in der Big Amid vorgenommen haben, aber sie sind nicht in Stage oder nicht in Cat Lassen Sie mich das mit dem Git-Status klarstellen. Siehst du, hier bekommen wir zwei Dateien, die nicht nachverfolgt wurden. Hier können wir also so viele Commits machen, wie wir wollen. Lassen Sie uns zunächst für die Warenkorbseite entscheiden. Also stellen wir die erste Warenkorb-Seitendatei bereit, Git, fügen Komponenten hinzu, Slash Cart Dot, sGML Wir verpflichten uns zur Veränderung. Git Commit, Implementierung der Warenkorbfunktion. Schauen wir uns jetzt unsere Geschichte an. Siehst du, hier haben wir eine vielfältige Geschichte, weil unsere Basis dieser und hier unsere früheren Kometen sind. Lassen Sie uns nun einen weiteren Commit für das Benutzerprofil erstellen. Wir stellen hier Komponenten, Schrägstrich, Benutzerprofilpunkt, SGML und auch CommitateGT Nun der Grund, warum wir hier nicht Amend Commit verwenden , weil wir unseren aktuellen Commit nicht ändern wollen Hier wollen wir eine neue Katze erstellen. Also git dM, Implementieren Sie die Benutzerprofilfunktion. Schauen wir uns jetzt unseren Verlauf an. Sehen Sie oben, wir haben zwei separate Kometen. Keine Sorge, wir sind immer noch im Rebase-Prozess. Dies ist nicht die endgültige Ausgabe. Wenn wir nun unseren Repase-Prozess fortsetzen, wird Git diese anderen Kometen neu erstellen und sie dadurch über diese beiden Kometen legen, wir erhalten einen linearen wird Git diese anderen Kometen neu erstellen und sie dadurch über diese beiden Kometen legen, wir erhalten einen linearen Verlauf. Das Git-Rebase geht weiter. Gut, wir haben erfolgreich rebase. Lassen Sie uns das anhand der Geschichte überprüfen. Sehen Sie hier, wir erhalten zwei separate Commits und unser großes Commit ist aus unserer Historie verschwunden Um es kurz zusammenzufassen: Zuerst starten wir den Rebase-Prozess verwenden dann den Befehl im Danach, wenn wir bei diesem großen Commit sind, entfernen wir unseren aktuellen Code mit Git Reset, Mixed Head Carat, aus und dem Commit-Bereich dem Staging-Bereich Head Carat bedeutet, dass wir unseren Staging-Bereich zurücksetzen und den Code auf den vorherigen Commit-Code übertragen Hier können wir Änderungen in einem Staging-Modus speichern und sie festschreiben, einen Commit und auch die Änderungen erneut in einem Staging-Modus speichern und dann festschreiben, was Commit zwei sein kann Und dann können wir den Prozess von B fortsetzen und abschließen , sodass S den Commit teilt und unsere Historie neu schreibt 100. Geschichte mit GitKraken neu schreiben: Lassen Sie uns nun sehen, wie wir unseren Verlauf mit Git Kraken neu schreiben können unseren Verlauf Hier dupliziere ich das Projekt , das ich dir zu Beginn dieses Abschnitts zum Üben gebe , und öffne es einfach in Gate Kraken Hier haben wir alle schlechte Medikamente und wir wollen die Geschichte umschreiben Jetzt ist das Umschreiben des Verlaufs in Gate Cracker sehr einfach und der gleiche Vorgang läuft auch im Das Umschreiben der Geschichte bedeutet jetzt, dass wir eine Rebase durchführen müssen. Hier wollen wir den Rebase-Prozess als Grundlage für diesen unter starten Rebase-Prozess als Grundlage für diesen unter Also schreiben wir, klicken Sie auf diesen Commit und wählen hier einfach ein interaktives Rebase aus diesem Commit aus In einfachen Worten, welchen Commit wir wählen, er wird als Basis gesetzt. Jetzt bekommen wir hier einfach diese Art von Rebase-Script. Wir haben diese Schnittstelle bereits im Vas-Code gesehen. Hier, in diesem Drop-down-Menü, können wir den Befehl ändern. Siehe für den ersten Commit Ich wähle Reword. Hier können wir unsere Commit-Nachricht ändern. An der Stelle, an der die Änderungen in der Indexpunkt-SDML vorgenommen wurden, schreiben wir die Datei Add Product List in Index-Punkt-SGML-Datei und aktualisieren die Nachricht Jetzt wollen wir auch diesen dritten Befehl mit diesem zweiten Befehl zusammenführen , wir können hier Squash auswählen und mit dem Pfeil sehen, wir klaren Squash erhalten Jetzt wollen wir hier auch diesen Work in Progress Mantel fallen lassen. Wenn wir Konflikte bekommen, wird Git kraken, wir bitten um Änderung, Löschung und Wie Gitask in unserer Git Bash. Lasst uns mit dem Rebase beginnen, seht ihr, hier kommt es zu Konflikten und wir können auf der rechten Seite Dateien sehen, die miteinander in Konflikt Klicken Sie darauf und hier übernehmen wir Änderungen von B und machen einfach C. C, der Konflikt ist weg, und jetzt können wir diese Rebase fortsetzen oder wir können sie auch abbrechen Lassen Sie uns auf Weiter klicken und sehen, ob alle Änderungen vorgenommen wurden. Das ist eine einfache Basis in Git Kraken und Viscode. Aber hier ist eine Sache. In Git Kraken oder im Vs-Code können wir Kometen modifizieren oder aufteilen Dafür müssen wir das Terminal verwenden. Deshalb zeige ich dir zuerst Git über die Befehlszeile und dann für GI-Tools. Jetzt haben wir offiziell alle Themen im Bereich Gangart behandelt. Was denkst du? Was magst du am meisten an Git? Verwenden Sie es im Terminal oder verwenden Sie es mit UI-Tools. Ich verwende gerne die Befehlszeile für alle Befehle und GI-Tools zum Ansehen des Verlaufs und zum Rebasen. Ihre Wahl mag anders aussehen, aber es ist Ihre persönliche Entscheidung Am Ende des Tages müssen Sie an Ihrem System arbeiten. Was auch immer wir verwenden, unsere Arbeit sollte getan sein. 101. Abschnitt 07 Die meistverwendeten Git-Befehle: Willkommen im Rückblick auf den ultimativen Git-Kurs. In diesem Abschnitt werden wir uns alle Befehle ansehen , die im Leben von Entwicklern am häufigsten vorkommen Es ist wie eine Überarbeitung von Git-Konzepten. Halten Sie also etwas Wasser bereit und genießen Sie diesen Abschnitt. 102. Git-Grundlagen und History-Befehle: Ich fange mit den grundlegenden Git-Befehlen an. Um unser Projekt zu initialisieren, verwenden wir zunächst den Befehl Gain init Oder wenn wir bereits ein Projekt in der Cloud haben, verwenden wir Git Clone und URL Nachdem wir unser Projekt erhalten haben, können wir Änderungen an unserem Code und diese Änderungen dann mit Git Add in Szene setzen. Und hier schreiben wir unseren Dateinamen. Durch die Bereitstellung der Änderungen sind diese Änderungen bereit für die Beschichtung Es ist wie ein Wartebereich. Wenn du nun alle Änderungen speichern willst, dann schreiben wir hier Git add period. Wenn du also unseren aktuellen Status sehen willst, dann schreiben wir Git Status oder Git Status kurz Status. Nachdem wir mit unseren Änderungen zufrieden sind, verpflichten wir uns zu Änderungen, um diesen Code in unserer Gate-Historie zu speichern, diesen Code mithilfe von Git Commit in unserer Gate-Historie zu speichern, und wir fügen hier eine Nachricht hinzu. Stellen Sie hier sicher, dass Sie eine aussagekräftige Nachricht schreiben. Wenn wir keine neue Datei hinzufügen, können wir den Kurzbefehl Git commit AM message verwenden . Mit diesem Befehl können wir unseren Code in einem einzigen Befehl bereitstellen und festschreiben. Wenn Sie nun den Unterschied zwischen der Working Area Code und der Staging Area Code sehen wollen , dann können wir Git DF verwenden, wenn wir den Unterschied zwischen Staging-Vorwahl und festgeschriebenem Code sehen wollen Unterschied zwischen Staging-Vorwahl und festgeschriebenem Code Dann können wir Git dif, Stage oder wir können Git Di Dash Dash Cast verwenden Wenn wir danach unseren Commit-Verlauf sehen möchten, können wir den Befehl Git log verwenden Und wenn wir den Verlauf in einer Zeile sehen wollen, dann können wir Git Log verwenden, eine Zeile gestrichelt. Wir können auch andere Optionen wie ein Diagramm für den Verlauf hinzufügen . Wenn wir danach sehen wollen, was wir in Commit ändern, können wir Git, Show und Commit ID verwenden . Außerdem können wir ihren Kopfzeiger verwenden und wenn wir eine bestimmte Datei sehen wollen, dann können wir Git, Show, Commit Reference verwenden und mit Spalte schreiben wir unseren Dateipfad. Manchmal möchten wir also den Code von einem Commit zum anderen wechseln. Dann können wir Git Checkout, Commit ID oder auch Git, Switch, Commit ID verwenden. Wenn nun in unserem Projekt jemand sehr schlechten Code schreibt, und um den Autor jeder Zeile zu überprüfen, können wir Git, Blame verwenden und hier unseren Dateipfad schreiben, dem wir die Schuld geben wollen. Wenn wir bestimmte Zeilen sehen wollen, können wir hier Option L hinzufügen, und hier schreiben wir Startzeile, Komma, Endzeilennummer. Danach ist git tag, tag name ein weiterer häufig verwendeter Befehl zum Markieren von Git-Commits Dann schreiben wir unsere Commit-ID , für die wir dieses Tag erstellen möchten Wenn wir das Tag entfernen wollen, verwenden wir das Git-Tag D, und hier schreiben wir unseren Tag-Namen und für C, die Liste der Tags, verwenden wir einfach den Befehl Git Tag. Dies sind die wichtigen Befehle im Zusammenhang mit Grundlagen von Git und zum Ansehen des Commit-Verlaufs. 103. Verzweigungs- und Zusammenführungsbefehle: Lassen Sie uns nun einen Überblick über Branches geben. Wenn Sie an einer separaten Funktion arbeiten oder einfach nur in Ihrem Team arbeiten möchten, sollten Sie einen neuen Zweig erstellen und an diesem Zweig arbeiten Wenn wir die Liste aller Branches sehen wollen, dann haben wir den Befehl git branch. Und um einen neuen Zweig zu erstellen, verwenden wir den Git-Branch und den Branch-Namen. Nachdem wir einen neuen Branch erstellt haben, müssen wir zu diesem Branch wechseln, und das können wir mit dem Branchnamen Git Switch tun. Wenn wir nun einen neuen Branch erstellen und auch in einem einzigen Befehl wechseln wollen, dann schreiben wir Git switch, C und Branch name. Um nun zu sehen, was der Unterschied zwischen einem bestimmten Branch und unserem aktuellen Branch ist, können wir den Branchnamen Git Div schreiben. Außerdem können wir den Unterschied zwischen zwei Zweigen, die Git verwenden, erkennen : D, Zweig eins, Punkt Punkt, Zweig zwei. Wenn wir jetzt an Zweig eins arbeiten und plötzlich an Zweig zwei arbeiten müssen, können wir stasen, anstatt den halben Code diesen Code stasen, anstatt den halben Code zu übergeben Stairs ist so, den Code in einer Ecke belassen, dann können wir zu einem anderen Zweig wechseln und unseren fertigstellen oder danach können wir die Treppe in unserem vorherigen Zweig anwenden die Treppe zu erstellen, verwenden wir Git stairs, push, und hier fügen wir Ss message hinzu, um alle Treppen zu sehen, wir verwenden Git Stats List. Wenn wir nun Änderungen von Treppen in unserem Arbeitsverzeichnis übernehmen möchten , können wir Git, Apply und Stats ID verwenden . Nachdem wir die Änderungen von dieser Treppe aus übernommen haben, können wir die Treppe mit Git Stash, Drop und Stats ID Und wenn wir alle Einträge aus dem Projekt entfernen möchten, können wir Git Clear verwenden Wenn wir danach mit unserem Zweig fertig sind, können wir ihn mit unserem Hauptzweig zusammenführen. Und dafür können wir zum Hauptzweig wechseln und ihn dann zusammenführen, indem wir den Branchnamen git merge verwenden. Wenn wir eine unterschiedliche Historie haben, führt Git die Zusammenführung in drei Richtungen durch, und wenn wir eine lineare Historie haben, wird Git für unsere Zusammenführung zugelassen Nachdem wir unseren Branch im Hauptzweig zusammengeführt haben, können wir diesen Branch löschen, indem wir Git branch, D, Branchname Wenn wir diesen Zweig gewaltsam löschen möchten, können wir Git branch, D, Branchname verwenden Außerdem können wir den Kamed mit Git Reset auf die ältere Version Beim Reset haben wir drei Varianten. Git Reset, Dash Dash Soft, Kate, das den Code von Coat zurückgesetzt hat, Git Reset, Dads Mixed, das den Code von A und von Camt zurücksetzt Wenn wir Git Reset DS Hard verwenden, dann wird unsere gesamte Vorwahl mit dieser Comite-Vorwahl zurückgesetzt Jetzt können wir auch das Amid rückgängig machen und der Unterschied zwischen Reset und Amid besteht darin, dass Git mit Revert ein neues Met erstellt, aber beim Reset erstellt Git kein Wird Änderungen im aktuellen Camt vornehmen. Für revert verwenden wir Git revert und wenn wir zum übergeordneten Kometen zurückkehren wollen, das ist der vorherige Komet unseres aktuellen Zweigs, dann schreiben wir hier einen und danach schreiben wir Comte, den wir rückgängig machen wollen, nämlich head Wenn Sie einen Comite-Code ohne Zusammenführung in unseren aktuellen Camt kopieren möchten, können wir schließlich die Git Cherry Peak Commit-Referenz verwenden. Dies ist der Überblick über Verzweigung und Zusammenführung. 104. Arbeiten in Team-Befehlen: Lassen Sie uns nun die Arbeit im Team zusammenfassen. Zuallererst, wenn wir im Team arbeiten, verwenden wir meistens den Befehl git fetch, dem Änderungen aller Branches aus unserem Cloud-Repository abgerufen werden aller Branches aus unserem Wenn wir danach speziell Änderungen von nur einem Zweig abrufen möchten , können wir git fetch schreiben Hier schreiben wir unseren Remote-Namen origin , der der am häufigsten verwendete Remote- und Branchenname ist Wenn wir vom Master abrufen wollen, können wir Git Fetch Origin Master schreiben oder wir können nur Git Fetch schreiben. Das wird genauso funktionieren Wie wir wissen, erhalten wir mit dem Befehl fetch nur Änderungen in unserer Historie Unser Arbeitsverzeichnis bleibt das gleiche wie zuvor. Wenn wir diese Änderungen direkt von der Ferne aus übernehmen wollen, anstelle von Git Fetch verwenden wir anstelle von Git Fetch Git Pull Aber denk daran, dass dadurch ein neuer Commit erstellt wird. Nun, wenn wir mit unseren Änderungen fertig sind und die Änderungen in die Cloud übertragen möchten. Wir müssen Git Push Origin, Master oder Main schreiben , was auch immer unser Projekt hat. Außerdem können wir hier den Shortcut-Befehl Git Push verwenden . Jetzt können wir unser Tag auch auf die Fernbedienung übertragen , indem wir Git Push, Origin und Tag-Name verwenden, um das Tag von Origin zu entfernen Wir verwenden Git Push Origin, Dash Delete und Tag-Name. Wenn wir nun einen neuen Branch erstellen und diesen Branch zum Ursprung übertragen wollen, müssen wir zuerst einen Upstream-Zweig erstellen. Wir schreiben den Namen des Git Push Origin-Zweigs. Wenn wir danach erneut Änderungen an diesem Branch vornehmen wollen , können wir Simple Gate Push verwenden. Git wird die Änderungen in diesen Zweig übertragen , es geht nur darum, im Team zu arbeiten. 105. Vielen Dank: Also herzlichen Glückwunsch. Du hast gerade den ultimativen Git- und Github-Kurs abgeschlossen. Und ich möchte dich nur fragen, hast du Git gelernt? Konnte ich Konzepte erklären, die dir helfen werden, Git zu verstehen? Das hoffe ich wirklich. Und in diesem Video möchte ich nur sagen, vielen Dank, dass Sie sich diesen kompletten It - und Github-Kurs angesehen haben. Dafür bin ich wirklich, wirklich dankbar. Und bitte, wenn du deine Bewertung zu diesem Kurs teilen möchtest , dann siehst du oben den Bating-Button, den du deine Bewertung teilen kannst Was auch immer du sagen willst, positiv oder negativ, es ist wirklich wichtig für mich Dieses Feedback zu geben wird nicht länger als 10 Sekunden dauern, aber das wird mir Inspiration und Motivation geben , bessere Kurse zu erstellen , und es wird mir auch helfen, mehr Schüler zu erreichen , die wie du Git und Github lernen möchten. Vielen Dank, dass du dir diesen Kurs angesehen hast und wünsche dir alles Gute auf deiner Entwickler-Reise. Ich hoffe, dass all deine Träume wahr werden.