Git und GitHub Meisterkurs – Schneller auf dem Weg zu Git!

1. Einführungsvideo: Willkommen zu diesem Kurs über Git und GitHub. Hier sind einige Gründe, warum du Git und GitHub lernen solltest. Mehr als 83 Millionen Prozent auf der ganzen Welt nutzen Get up. 90% der von Fortune finanzierten Unternehmen nutzen GitHub. Mehr als 200 Millionen Repositorys sind Projekte, die sich derzeit auf GitHub befinden. Github ist ein wichtiger Bestandteil Ihrer DevOps-Reise. In der Tat ist GitHub ein Ausgangspunkt, wenn Sie DevOps Catia verfolgen möchten . Du kommst nicht weiter, wenn du nicht GitHub lernst. Github ist auch die beliebteste Code-Hosting-Plattform im Vergleich zu seinen Mitbewerbern wie Bitbucket oder GitLab. Get ist das beliebteste Versionskontrollsystem , Get ist das beliebteste Versionskontrollsystem es je gab. Es ist fast ein Muss für jeden IT-Experten. Und das weißt du wohl schon. Hier sind die Ziele dieses Kurses. Ich bringe dir alles bei, was du über Git und GitHub wissen musst . Ich benutze es seit 2014 und habe sogar Erfahrung in der Verwaltung von Teams und der Einhaltung der Projektfristen. Ich habe den Lehrplan entsprechend verfeinert. Und Sie müssen sich nicht auf andere Bücher oder Kurse beziehen . In diesem Kurs lernen Sie alles, was Sie brauchen , und müssen nicht gehen. Alles was darüber hinausgeht. Sorgen Sie dafür, dass Sie alle Projektaufgaben im Zusammenhang mit Git und GitHub sicher erledigen können. Bringen Sie bei, wie Sie zu Open-Source-Projekten beitragen können, und machen Sie sich mit Interviews sicher. Aber warum sollten Sie aus diesem Kurs lernen? Aldi, wichtige und wichtige Themen werden in den ersten Kapiteln behandelt. Und all die Themen, die nicht unbedingt erforderlich sind oder später im Kurs behandelt werden. Wir achten nur auf sechs bis zehn Kapitel. Sie werden sich sicher fühlen, die Aufgabe später anzunehmen, um aufzustehen. Davon abgesehen empfehle ich Ihnen dringend, sich den gesamten Kurs anzusehen. Um das gesamte Thema zu lernen. Ich kombiniere mehrere verwandte Themen in derselben Vorlesung, um wertvolle Zeit zu sparen. Wenn es für mich Sinn macht, mehrere verwandte Themen zu kombinieren und gemeinsam zu unterrichten, mache ich das immer. Nicht nur, um Zeit zu sparen, sondern auch um effektiver zu unterrichten. Ich bringe Ihnen dieses Objekt mit realen Szenarien, Anwendungsfällen und Workflows bei. Ich habe einige der schwierigsten Projektherausforderungen selbst gemeistert. Und ich kann diese Erfahrung sicherlich nutzen, um über einige der realen Szenarien zu sprechen , in denen Sie all diese Konzepte anwenden können. Ich habe die einzigartige Fähigkeit, sehr komplexe Konzepte auf leicht verständliche Weise zu vermitteln . Sie werden das selbst verstehen wenn Sie in diesem Kurs Fortschritte gemacht haben. Ich habe auch Erwartungen , wer sich diesen Kurs ansieht. Vergessen Sie, was Sie bereits wissen, und fangen Sie neu an. Wenn du bereits etwas über Git und GitHub oder ein verwandtes Thema weißt , möchte ich, dass du einfach alles aus deinem Kopf löschst und mit einem sauberen Verstand anfängst. Andernfalls hören Sie möglicherweise widersprüchliche Terminologien, die Sie dann verwirren könnten. Hingabe und Engagement, das Intersubjekt zu lernen , lebten in der Welt der Ablenkungen. Wenn Sie sich nicht bemühen, engagiert und engagiert zu bleiben , um das gesamte Fach zu lernen, lernen Sie eigentlich nichts. Übe was ich unterrichte. Einmaliges Üben entspricht dem zehnfachen Lesen, das von jemandem irgendwo festgelegt wurde. Aber es ergibt absolut Sinn. Du solltest versuchen zu üben, was ich unterrichte. Andernfalls könnten Sie den Überblick über das Thema verlieren und verwirrt werden. Konzentrieren Sie sich auf einen Kurs, unabhängig davon, ob Sie diesen oder einen anderen Kurs belegen, schließen Sie ihn vollständig ab und wechseln Sie dann auf Wunsch zu einer anderen Informationsquelle. Aber mischen Sie die Dinge nicht zusammen, was wiederum zu großer Verwirrung führen wird. Widme jeden Tag nur eine Stunde ohne Ablenkung. Es ist besser, eine Stunde lang mit vollständigem Fokus zu lernen , als acht Stunden lang mit weniger gutem Fokus zu lernen. Denken Sie daran. Als nächstes werden wir anfangen zu verstehen, was Get Github ist, was ist Versionskontrollsystem usw., mit realen Beispielen? Und das ist eine großartige Möglichkeit , unseren Kurs zu beginnen. Wir sehen uns als Nächstes. 2. 0101 Notwendigkeit für Version und Git Teil 1: Warum brauchen wir ein Versionskontrollsystem? Lernen Sie Mr. Bob kennen, der Anlageberater ist. Und aufgrund all der großartigen Arbeit, die er leistet, hat sich sein Kundenstamm im Laufe der Zeit erheblich vergrößert. Und so sieht er die Notwendigkeit, eine eigene persönliche Website zu haben. Bob hatte sich also eine eigene Website vorgestellt. Und Bob war ein nicht-technischer Typ und dachte daran, Hilfe von einem Freiberufler in Anspruch zu nehmen , um die Arbeit zu erledigen. Also traf er den Absender, der freiberuflich oder ungeklärt ist, ihm alles , was auf seiner Website erwartet , und gab die Frist als 24. Februar an, was zufällig sein Geburtstag ist grade und begann mit der Arbeit an dem Projekt. Einblicke in diese Computer. Dort hatte dieser Ordner namens Investment App erstellt, in dem er all diese Dateien erstellt hat , die diese Website erstellen werden. Nach ein paar arbeitsfreien Tagen hatte Cylinder endlich die Arbeit an der Erstellung der Website abgeschlossen . Er hat es getestet. Er hostete es auch bei einem Hosting-Anbieter oder bei einem Cloud-Dienstanbieter. Gott, die Anwendung läuft und hat sie Bob gezeigt. Bob war ziemlich beeindruckt von der Arbeit von Sunder. Und so beschloss er nun, seiner Website einige weitere Funktionen hinzuzufügen . Und Sie erhalten die Deadline als 20. Februar. Zwei Waren hatten den Deal früher angenommen und begannen, hatten den Deal früher angenommen und diese zusätzlichen Funktionen zu nutzen. Und wieder einmal hatte Cinder all diese Funktionen hinzugefügt, sie beim Hosting-Anbieter gehostet, die Website zum Laufen gebracht und Bob gezeigt. Diesmal war Bob jedoch mit der Arbeit nicht ganz zufrieden. Obwohl die neuesten Funktionen nach dem 24. Februar eingeführt wurden , funktionieren wir einwandfrei. Die Funktionen, die früher funktionierten, scheinen defekt zu sein oder funktionieren nicht wie erwartet. Also hatte Bob die gleichen beiden Schlacken erklärt und ihn gebeten, alle neuen Änderungen rückgängig zu machen und die Anwendung wieder auf den 24. Februar zu bringen . Dazu werden sie bald zögernd akzeptiert. Leider wird es für Cinder keine leichte Aufgabe sein, wird es für Cinder keine leichte Aufgabe sein all diese Änderungen rückgängig zu machen da nach dem 24. Februar eine Menge neuer Code eingeführt wird und der Code verstreut ist über mehrere Dateien hinweg. Es ist wirklich schwierig für den Absender, sich an jede einzelne eingeführte Codezeile zu erinnern und all diese Änderungen rückgängig zu machen. Da jedoch derjenige , der den Deal annahm, um den Kunden bei Laune zu halten, nach vielen schlaflosen Nächten und nach viel Frustration und viel Testzentrum endlich die Arbeit erledigt hat. Diesmal jedoch, mitten in Bobs Frist, fragte sich Bob, warum es weniger als ein paar Wochen dauerte , um die Änderungen rückgängig zu machen. Nun, er hat nur ein paar Tage gebraucht , um die gesamte Website zu erstellen. Dies hat dazu geführt, dass Bob nicht zufrieden war und bald auch bei einigen seiner anderen Kunden ähnliche Probleme sah . Sie beschwerten sich , dass einige der Funktionen nicht wie erwartet funktionierten, was früher funktioniert hatte. Deshalb wollten sie sie reparieren lassen oder zu früheren Versionen ihrer Webanwendungen zurückkehren zu früheren Versionen , die einwandfrei funktionieren. Also dachte Sunder darüber und kam schließlich auf eine geniale Idee, die dieses Problem etwas lösen soll. Wir werden in einer Weile darüber sprechen. 3. 0102 Notwendigkeit für Version und Git Teil 2: Was da drin ist, war zu bemerken, dass er keine Backup-Office-Client-Websites hatte. Wenn Sie eine Sicherungskopie ihrer Websites hatten, hat er die Möglichkeit, entweder zur vorherigen Arbeitsversion ihrer Website zurückzukehren , oder zumindest n liegt das Problem, indem er eine Version mit der anderen vergleicht. Cylinder hatte eine geniale Idee , um dieses Problem irgendwie zu lösen. Was Sie jetzt angefangen haben, ist zum Beispiel, uns die Investment-App anzusehen über die wir gesprochen haben. Cinder erstellt einen Ordner mit dem Namen Investment App V1 und 14. März. Dies ist das Datum, an dem dieses Projekt an den Kunden geliefert wurde. Und dann gehen wir davon aus , dass Bob ihn gebeten hat, ein paar neue Funktionen einzuführen. Dieser Zeitzylinder wird in diesem Teil des Projekts keine Änderungen vornehmen. Stattdessen wird eine Kopie dieses Projekts erstellt, es als V2 bezeichnet und alle neuen Funktionen vorgestellt. Und wenn Bob dort einige bitten würde, noch mehr Funktionen hinzuzufügen, wird er eine Kopie der neuesten Version seines Projekts erstellen , sie zum Beispiel als V3 bezeichnen. Und dann nehmen Sie alle notwendigen Änderungen vor, so weiter und so fort. Jedes Mal, wenn er eine neue Funktion einführte oder einen riesigen Codeabschnitt einführt, wird er einfach den Ordner oder das Projekt kopieren und die notwendigen Änderungen vornehmen. Dieses Mal. Nehmen wir noch einmal den gleichen Fall an, in dem Bob sich beschwert hat, dass Washington zuvor nicht wie erwartet funktioniert und dass er nach Washington V3 zurückkehren wollte, was so bald gut funktionierte, dass das nicht funktioniert müssen ihren Fuß davon nehmen, alle Änderungen rückgängig zu machen. Er könnte einfach den V4-Ordner vom Server entfernen und ihn durch die V3-Arbeitsversion der be-bops-Website ersetzen . Oder wenn Bob darauf bestanden hätte, den Fehler zu beheben, kann das tatsächlich die Dateien zwischen v3 und v4 vergleichen, indem er kann das tatsächlich die Dateien zwischen v3 und v4 beispielsweise eine Vergleichssoftware wie beyond compare verwendet, um genau die Änderungen zu lokalisieren , die neu eingeführt, analysieren Sie das Problem und beheben Sie das Problem. Während dies das Problem etwas gelöst hat, wurde plötzlich klar, dass dies mehr Speicher beansprucht als nötig. Denn der Absender erstellt nicht nur eine Kopie aller Dateien, die er geändert hat, sondern auch der Dateien, die er nie angefasst hat. Das wird also viel Platz beanspruchen und es wird für ähnliche Zwecke sehr schwierig, es zu verwalten. So kam plötzlich eine viel bessere Idee auf, nämlich Versionen der Dateien innerhalb des Projekts zu erstellen . Was meine ich damit? Sie also davon aus, dass Sie wieder ein solches Projekt mit all diesen Dateien haben . In diesem Fall habe ich sie natürlich als HTML bezeichnet, aber das könnte eine beliebige Datei sein, das könnte eine Bilddatei, eine CSS-Datei, eine JavaScript-Datei, eine Java-Datei sein , was auch immer. Sie für dieses Beispiel an, Nehmen Sie für dieses Beispiel an, dass wir alle diese Dateien haben. Nehmen wir nun an, dass das Center eine neue Funktion einführt , die etwas mit den Dateien B und C zu tun hat . Anstatt also eine Kopie des gesamten Ordners zu erstellen , wird eine Kopie der neuesten Version erstellt von diesen beiden Dateien. Dies wird eine Kopie von Datei B und Datei erstellen, siehe, den gesamten Code einführen, der für Feature 1 erforderlich ist. Und wenn Sie eine weitere Funktion einführen möchten und diesmal davon ausgehen, dass die Änderungen die Datei ablegen müssen, sehen Sie sich an, dass einige davon einfach eine Kopie der neuesten Versionen von Datei a erstellen und datei. Siehe zum Beispiel, in diesem Fall wird hier eine Kopie der Datei erstellt sowie eine Kopie von Datei C, Version eins, die die neueste Version von Datei C enthält Und dann wird er die neue Funktion vorstellen. Sobald ich davon ausgehen kann , dass Bob Sunder gebeten hat , die Funktion vollständig zu entfernen , und dass wir zu einer früheren Version seiner Wanderwebsite zurückkehren möchten . Ratet mal, Watson, sie können es einfach aus den V2-Dateien entfernen und nur die V1-Dateien so einfach halten. Und wenn Sie stattdessen den Fehler beheben möchten, kann er einfach die Datei der Version eins mit Washington to File vergleichen und genau bestimmen, was schief läuft, indem er eine Vergleichssoftware wie Beyond Compare verwendet. Watson Sie bemerkten jedoch, dass selbst dies nicht machbar ist , da es unglaublich komplex wird , mehrere Kundenprojekte zu verwalten. Beispielsweise muss der Absender alle diese Dateien wieder in ihren ursprünglichen Namen umbenennen , bevor sie auf dem Remote-Server bereitgestellt werden. Und er hat auch bemerkt , dass seine Dateien ständig zunehmen, was nicht nur bei der Organisation der Dateien zu Problemen führt, sondern auch viel Speicherplatz beansprucht. Zu diesem Zeitpunkt wurde mir klar , dass es an der Zeit ist, die Software die Arbeit für ihn erledigen zu lassen. Eine Software, die Versionen als Software verwaltet , die historische Änderungen verfolgt, Backups erstellt und die Umkehrung von Änderungen ermöglicht usw. Dies ist der Hauptgrund, warum jemand irgendwohin kommen musste mit der Software, die diesen Job erledigen wird. Und das ist die Geburtsstunde von Get. Jetzt macht get viel mehr als nur das. Aber ich spreche gerade nicht über sie weil Sie zu diesem Zeitpunkt nicht wissen, was der GitHub-Teamzusammenarbeitszweig beim Zusammenführen ist und solche Dinge. Ich werde sie für kommende Vorlesungen aufbewahren. Und ich bin mir ziemlich sicher, dass Sie auch Fragen haben müssen wie Was ist GitHub oder GitLab, was verzweigt sich usw. Nun, darauf müssen Sie einfach warten. Ich kann nicht alles unter ein einziges Video passen, wie Patienten und den Rest des Kurses anschauen. Und Sie werden Antworten auf alle Fragen finden , die Sie möglicherweise haben. Aber um ehrlich zu sein. Mir gefällt, wie schnell die Wartung überall ein Smiley-Ausdruck ist . Egal wie sich sein Leben um ihn dreht. Etwas, von dem man lernen kann, nicht wahr? Was hast du gerade gesagt? Nein. Nein. Ich sage nur, dass du einen großartigen Sinn für Mode hast. Okay. 4. 0103 VCS Wie es funktioniert: Lassen Sie uns sehen, wie das Versionskontrollsystem oder einfach die Visio-Software auf einem sehr hohen Niveau funktioniert. Nehmen wir noch einmal an, dass wir Sunder haben, eine freiberufliche Entwicklerin, und cylinder hat eine neue Kundin, Linda, die Restaurantbesitzerin ist, und sie wollte eine Website für ihr Restaurant haben. Also um Online-Bestellungen von unseren Kunden anzunehmen. An ihrem Lächeln können Sie erkennen , dass er bereit ist, das Projekt aufzunehmen. Aber basierend auf seinen schlechten Erfahrungen in der Vergangenheit mit einigen seiner anderen Kunden, die nun entschieden haben, eine VCS-Software zur Verwaltung der Versionierung zu verwenden . Zylinder in seinem lokalen Computer erstellt einen Ordner mit dem Namen Restaurant-App, verbringt ein paar Tage und führt alle Dateien ein, die erforderlich sind, um eine minimal funktionierende Website zu erstellen. Die Videosoftware wird über einen eigenen Datenspeicher verfügen , um alle historischen Daten und Sicherungen zu speichern . Wenn ich sage, dass Datastore nicht unbedingt eine relationale Datenbank oder irgendeine Form von Datenbanksoftware sein muss. Es kann so einfach wie ein Dateisystem sein. Wir verkaufen Software, die normalerweise dazu neigt, Ihr eigenes Dateisystem zu verwenden , um die Backups und historischen Daten zu speichern . Während wir den Kurs durcharbeiten, werden Sie dieses Konzept viel besser verstehen. Aber jetzt nehmen Sie einfach an, dass dies eine Art Backup-Speicher ist , um den Status des Projekts zu speichern. Nehmen wir nun an, dass Cylinder mit den Fortschritten, die er in seinem Projekt gemacht hat, sehr zufrieden ist Er hat eine minimal funktionierende Website und hat alles getestet. Alles funktioniert super. Daher wurde beschlossen, den Status dieses aktuellen Projekts zu speichern . Also um es bei Bedarf zurückzuholen. Also wird er die Visio-Software anweisen den aktuellen Status des Projekts zu speichern, normalerweise indem er einen Befehl ausführt. Sobald der Befehl ausgeführt wurde, wird die Software im Wesentlichen eine Kopie aller Dateien erstellen und sie im Datenspeicher speichern. nun davon aus, dass der Absender eine neue Anforderung zur Einführung der ersten Funktion hat . Und nehmen Sie an, dass all diese Codeänderungen in die Datei, bn-Datei , gehen müssen , siehe einige, die all diese Änderungen vorgenommen haben. Wiederum wird den Befehl ausführen, um den Status seiner aktuellen Arbeit zu speichern. Aber dieses Mal, der Vizier Soft, speichern wir die Informationen etwas anders als früher. So wird es gespeichert. Da in Datei a keine Änderungen vorgenommen wurden, würde die VCU-Software nur die Referenz von defile a speichern. Das bedeutet, dass sie nur Informationen über den Ort enthält, an dem sie eine Kopie ablegen wohnhaft. Und der Grund dafür liegt auf der Hand. Wir möchten nicht unnötig eine Kopie aller Dateien erstellen , die unberührt oder unverändert waren, und diesen Speicherplatz belegen. In Bezug auf die Dateien B und C haben wir jedoch neue Änderungen eingeführt. Die einfachste Software wird jedoch keine Kopie dieser Dateien erstellen. Adr. Was gespeichert wird, ist eigentlich der Unterschied zwischen der modifizierten Datei und der neuesten Version derselben Datei. Und es wird dasselbe im Datastore speichern. Wir nennen, dass jeder von ihnen ein schlechtes Set hat. Im Wesentlichen ist ein schlechter Satz der Unterschied zwischen der Originaldatei und der neuesten Version derselben Datei. Und der Grund dafür liegt wieder einmal auf der Hand. Wir wollen diesen Platz so weit wie möglich sparen. ähnlicher Weise davon aus, dass wir eine neue Funktion namens Feature haben , in die eingeführt wird. Und Datei A und Datei B wurden geändert. Und so würde die VCS-Software die Daten speichern. Wir haben also PAD-Sätze für Datei A und Datei B. Und dann werden wir für Datei C nur die Referenz der vorherigen Version speichern . Und gehen Sie ähnlich davon aus, dass wir ein anderes Feature haben Wir werden Änderungen an Datei B vornehmen. Und so ging die VCO-Software, die die Informationen speichert, nun davon aus, dass Zylinder mit der Version für Rohdatei B nicht zufrieden ist mit der Version für Rohdatei B nicht zufrieden und dass er wollte zu Version drei der Datei B zurückkehren. Also wird es dasselbe in die Vizier-Software einfügen. Das weichere Visum würde dann die Originalkopie von Datei B abholen und dann alle Patches, die danach kamen, bis Version drei anwenden , um die Version drei Datei B zu erstellen die Version drei Datei B , und wird an zurückgeben sonntag Er kann damit machen, was er will. Ein ähnlicher Zuhörer kann auch den Befehl schreiben, der die Software anweist , zum Beispiel die gesamte Projekttorsion drei zu erhalten , und die Software wird genau das tun. Jetzt gibt es offensichtlich eine Menge Wesir-Software auf dem Markt. Wir haben gute Mercurial, SVN usw. Und alle unterscheiden sich geringfügig in Bezug auf Art und Weise, wie die historischen Daten verwaltet werden. Aber im Allgemeinen ist dies die Art und Weise, wie die historischen Daten verwaltet werden. Lassen Sie uns jetzt tief eintauchen und verstehen, was genau passiert, was passiert ist, warum? Mir ist egal, wie es intern funktioniert. Es hilft mir sowieso nicht bei meinem Job. Ich möchte nur wissen, wie man die Software benutzt. Das ergibt Sinn. Das ergibt Sinn. Nur noch ein letztes Video und dann beginnen wir mit der Installation des Tores und machen uns mit viel Übung die Hände schmutzig. Wie wär's damit? Danke. Du bist willkommen. 5. 0104 DistributedVCS: Lassen Sie uns über verteilte Versionskontrollsysteme sprechen. Linda ist sehr zufrieden mit der Arbeit, die bis Sonntag geleistet wurde, und seit sie eine Website gestartet bemerkte sie einen Anstieg unserer Geschäftsumsätze hat, bemerkte sie einen Anstieg unserer Geschäftsumsätze. Und aufgrund der gestiegenen Kundenanforderungen hat sie sich nun entschieden, noch mehr Funktionen auf ihrer Website zu haben . Sie möchte, dass der zweite Ansatz darin besteht, die Arbeit für sie zu erledigen. Aber dieses Mal hat sie aufgrund der steigenden Anforderungen unserer Kunden der steigenden Anforderungen unserer Kunden eine sehr kurze Frist zu beobachten. Absender hat den Deal akzeptiert, aber jemand ist sich der Tatsache bewusst , dass er das nicht alleine schaffen kann und dass er ein paar Leute in seinem Team einstellen musste, um ihm zu helfen, die Projekt pünktlich. Also stellte Sunder ein paar Leute ein, um Asia und Luke zu treffen, die die neuen Mitglieder im Team sind. Der Absender hat ihnen auch ein brandneues MacBook Pro zur Verfügung gestellt ihnen auch ein brandneues MacBook Pro ihnen die Projektdateien oder den Code mitgeteilt. Oder vielleicht hat er einen FTP-Server gehostet, den Link geteilt und sie zum Herunterladen aufgefordert. Und er hat sie auch angewiesen, die Software auf dem lokalen Computer zu installieren , angesichts all ihrer Vorteile. Natürlich hat under seine eigene lokale Einschreibung und seine eigenen Probleme , da sie Fortschritte im Projekt machen. Seitdem habe ich einige Probleme mit der Verwendung eines lokalen Versionskontrollsystems festgestellt. Einige der Probleme , mit denen sie konfrontiert sind , sind keine historischen Veränderungen anderer Mitglieder. Wenn er zum Beispiel einen Blick auf historische Änderungen werfen möchte, die in Datei a vorgenommen wurden, kann sie nur einen Blick auf die historischen Änderungen werfen , die sie vorgenommen hat, aber sie hat keinen Zugriff auf historische Daten von jemand anderem, zum Beispiel Zylinder, weil er nur Zugriff auf seinen eigenen Datenspeicher hat, aber nicht in diesem Datenspeicher. Das ist eindeutig ein Problem. Wenn sie keinen Zugriff auf den gesamten Verlauf der Änderungen erhält, kann sie nicht effektiv an einer Aufgabe arbeiten. Ein weiteres Problem ist, dass es schwierig ist , die neueste Codebasis zu verwalten. Immer wenn jemand eine Änderung vornimmt, muss er andere Entwickler darüber informieren , dass er diese Änderung vorgenommen hat und dass dieser Code auch auf seinen lokalen Computer kopiert werden muss . Um die neueste Version des Codes auf allen Computern zu haben , ist dies natürlich praktisch unmöglich, insbesondere wenn mehrere Teammitglieder an einer einzigen Codebasis arbeiten. Und die Dinge würden noch komplizierter werden wenn zwei Personen an genau derselben Datei arbeiten würden. Ein weiteres Problem ist keine zentrale Verwaltung von Rollen oder Zugriffskontrolle. Nehmen wir zum Beispiel an, dass jemand Luke einschränken möchte, dass er nur auf bestimmte Ordner im Projekt zugreifen kann , nicht jedoch auf die anderen Ordner. Nun, mit dem lokalen Washingtoner Kontrollsystem hat er keine Kontrolle darüber. Der Absender hat über all diese Probleme nachgedacht, mit denen er konfrontiert ist, und eine Recherche bei Google durchgeführt. Und schließlich kam ein sogenanntes zentrales Versionskontrollsystem auf. Würde einfach bedeuten, dass dieses Mal, anstatt den Datenspeicher zu haben, sowie der Code in den lokalen Registrierungen auf den lokalen Computern sind. Es wird auf einem zentralen Server sein. Und jeder würde den Code vom zentralen Server auswählen , daran arbeiten und ihn dann an den Server zurücksenden , damit andere ihren Code verwenden können. Und damit können wir alle Probleme beseitigen, die wir mit dem lokalen Versionskontrollsystem hatten . Noch einmal: Wenn esa sich alle historischen Daten einer bestimmten Datei ansehen möchte , wird sie leicht darauf zugreifen können. Denn dieses Mal werden alle Pfade auf einem zentralen Server verwaltet und alle Entwickler hätten Zugriff darauf. Und mit nur einem einfachen Befehl könnte jeder den brandneuen neuesten Code abrufen und anfangen, daran zu arbeiten. Also um Konflikte zu vermeiden. Und Cinder kann auch besser kontrollieren, wer auf was zugreifen kann. Da alles auf einem zentralen Server gehostet wird, kann er jetzt mit der rollenbasierten Zugriffskontrolle beginnen. Und er wird die Kontrolle darüber haben, wer auf welche Ordner des Projekts zugreifen kann , und so weiter. Zentralisierte Versionskontrollsysteme haben jedoch ihre eigenen Probleme. Was ist zum Beispiel, wenn mehrere für einen Wurf gehen? Oder was ist, wenn jemand den Server hackt? Was ist, wenn er Verbindungsprobleme hat? Vielleicht funktioniert ihr WLAN nicht. In all diesen Fällen können Entwickler nicht an dem Projekt arbeiten. Sie könnten genauso gut riskieren, den gesamten Code zu verlieren , wenn sie den Server nicht aufzeichnen können. In Anbetracht all dieser Nachteile bietet zentralisiertes Versionskontrollsystem, musste eine Alternative finden. Und so stieß er ein verteiltes Versionskontrollsystem. Es ist im Grunde das Beste sowohl aus der Welt des lokalen als auch des zentralisierten VCS, wodurch alle ihre Nachteile beseitigt werden. Diesmal mit zentralem Versionskontrollsystem. Anstatt ein einziges Depot als zentralisierten Server zu haben. Hier hat jedes einzelne langlebige seinen eigenen Server und jeder Entwickler hat eine Kopie des gesamten Verlaufs oder der Versionen des Codes auf seinem eigenen lokalen Computer. Das bedeutet, dass selbst wenn der Server für eine Aufgabe zuständig ist , jeder seine eigene lokale Kopie des gesamten Codes sowie der historischen Daten hat. Und wenn jemand wie Asia Konnektivität verliert, vielleicht aufgrund einer Wi-Fi-Verbindung, kann sie immer noch Fortschritte machen, weil sie alles auf ihrem lokalen Computer hat. Sie kann Änderungen vornehmen. Und wann immer sich die Verbindung wieder normalisiert, kann sie den Code an den zentralen Server liefern , damit andere Entwickler sie abrufen und etwas damit anfangen können. Oder im Falle eines Datenverlusts jeden Dollar plus eine Sicherung der gesamten Codebasis. Sie können sich also an einige Beispiele von zentralisierten Versionskontrollsystemen oder CVS-Subversion oder einfach SVN Perforce oder an einige Beispiele für zentralisierte Versionskontrollsysteme erinnern zentralisierten Versionskontrollsystemen oder CVS-Subversion oder einfach SVN Perforce oder an einige Beispiele für zentralisierte Versionskontrollsysteme . Einige Beispiele für verteilte Versionskontrollsysteme sind Mercurial, Bazaar und Git. Git ist ein verteiltes Versionsverwaltungssystem. Alle Entwickler müssten Git auf dem lokalen Computer installieren. Darüber hinaus haben wir GitHub, das sich wie ein zentraler Server verhält. Ich denke, wir haben genug Wissen gesammelt , um mit Git zu arbeiten. 6. 0105 InstallingGit: Okay, lassen Sie uns sehen, wie wir herunterladen, installieren und konfigurieren können , um an unserer lokalen Registrierung teilzunehmen. Nehmen wir nun an, ich bin ein Freelancer und habe ein sehr kleines Projekt, von dem ich glaube, dass ich alleine laufen kann. Vergessen Sie die Zusammenarbeit im Team, vergessen Sie mehrere am Projekt beteiligte Personen. Vergessen Sie vorerst GitHub . Konzentrieren wir uns einfach auf Get. Gehen Sie also zu Google und suchen Sie nach dem Download, rufen Sie den ersten Link auf, stellen Sie jedoch sicher, dass er zur Website gehört. Holen Sie sich den Bindestrich SCM. Das ist die offizielle Website von get. Sobald Sie dort sind, klicken Sie je nach verwendetem Betriebssystem auf den entsprechenden Link. Wenn Sie diese Seite jetzt aufrufen, sehen Sie möglicherweise ein anderes Layout. Aber du hast den Punkt verstanden. Sie müssen nur auf den Link klicken, der für Ihr Betriebssystem spezifisch ist . Ich verwende Windows. In meinem Fall gibt es, wenn Sie macOS verwenden , separate Anweisungen dafür . Folgt ihnen einfach. Und während der Installation können Sie alle Standardeinstellungen beibehalten und mit der Installation fortfahren. Und es ist nicht notwendig , dass Sie bei der Installation jeden einzelnen Schritt verstehen . Das ist völlig normal. Falls Sie Probleme bei der Installation in macOS-Sets haben, setzen Sie sich mit uns in Verbindung und wir können Ihnen helfen. Aber da ich Windows verwende, klicke ich hier darauf. Ich habe im Grunde ein paar Optionen. Die erste davon ist die Installer-Version von Git und die andere ist die portable Version von Git. Wenn ich eine portable Version herunterlade, kann ich Git verwenden, ohne sie installieren zu müssen. Und das könnte nützlich sein, besonders wenn ich an mehreren Computern arbeiten möchte und Git nicht auf jedem einzelnen Computer installieren möchte. Ich kann einfach all diese Dateien auf einen USB-Stick oder einen USB-Stick speichern und dann auf all diesen Computern gut verwenden. Aber ich gehe mit dem Installer. Ich verwende ein 64-Bit-Betriebssystem, also klicke ich darauf. Nun, für Linux- und Mac-Benutzer haben Sie Git möglicherweise bereits installiert. Sie können es einfach überprüfen, indem Sie einen Befehl ausführen. Ich werde dir den Befehl in einer Weile zeigen. Oder Sie haben diese Bibliotheken bereits, also müssen Sie sie nur installieren. Sie können sich dafür auf die Installationsanweisungen beziehen . Also habe ich das heruntergeladen. Lassen Sie uns jetzt den Installationsvorgang starten. Wenn Sie Patienten haben, die die gesamte Lizenz durchgehen, habe ich nicht so viele Patienten, ich habe einfach auf Weiter geklickt. Während der Installation von Git stoßen Sie möglicherweise auf bestimmte Schritte, bestimmte Eingabeaufforderungen, bestimmte Terminologien, die Ihnen nicht vertraut vorkommen. Es ist vollkommen in Ordnung. Denken Sie als Faustregel daran, alle Standardeinstellungen beizubehalten und mit der Installation fortzufahren. Es ist nicht erforderlich, dass Sie jeden einzelnen Schritt dieses Installationsvorgangs verstehen . Seitdem habe ich lange daran gearbeitet. Ich verstehe, was hier gefragt wird. Aber für dich musst du nicht alles verstehen. Ich würde Sie nur durch die Schritte führen , die Sie meiner Meinung nach anhand des Wissensstands, den Sie bisher in diesem Kurs erworben haben, verstehen können anhand des Wissensstands, den Sie bisher in diesem Kurs erworben haben, verstehen . Also könnte ich einfach alles den Standardeinstellungen überlassen. Diese Aufforderung fordert uns jedoch im Grunde, dass aufgefordert werden, die Komponenten auszuwählen , die wir installieren möchten. Wir werden über Git Bash sprechen und loslegen. In der nächsten Vorlesung. Sie können einfach ignorieren und den Rest dieser Dinge auf die Standardeinstellungen beschränken. Wir wollen nicht zu sehr ins Detail gehen. Es ist nicht das, was hier im Grunde genommen darum geht , eine Software zum Bearbeiten von Punkt-Get-Dateien auszuwählen. Ich habe Notepad Plus Plus in meinem Computer installiert, und das kann ich wählen. Und ich würde dir auch empfehlen, dieselbe Software zu verwenden . Es ist Open Source. Dafür müssen Sie nichts bezahlen. Laden Sie Notepad Plus, Plus herunter, es ist ein erstaunliches Tool. Wählen Sie das und klicken Sie auf Weiter. Belassen Sie dies auf Standard, da Sie diesem Zeitpunkt nicht wissen, was eine Verzweigung ist. Daher ist es für mich nicht sinnvoll, Ihnen diesen Schritt zu erklären. Also lassen wir das auf Standard. Okay, auf dieser Registerkarte werden wir im Grunde gefragt , ob wir nur Git Bash verwenden oder ob wir auch die Befehlszeile von Windows verwenden werden ? Dieser Schritt ist spezifisch für Windows. Möglicherweise sehen Sie keine ähnlichen Installationsschritte. Wenn Sie sich bemühen, Git auf einem anderen Betriebssystem wie Linux oder MacOS zu installieren, sehen Sie möglicherweise insgesamt andere Anweisungen. Aber wie gesagt, überlasse alles auf den Standardeinstellungen und beende die Installation. Aber wenn ich diese Option auswähle, wird get tatsächlich eine Pfadvariable in Systemregistrierungsvariablen hinzufügen , damit wir Git-Befehle auf dem Windows-Befehlsprozessor verwenden können . Wenn Sie diese Option wählen. wird jedoch nicht mit einer Annahme geschehen , dass nur Git Bash verwendet wird. Wir werden wieder über Git Bash sprechen in der nächsten Vorlesung grau werden. Als Nächstes überlasse ich dies auf Standard. Im Grunde. Es wird gefragt, ob sie das vorhandene OpenSSH verwenden möchten oder ob Sie es bereits installiert haben. Du kannst einfach darauf zeigen. Aber wir werden das OpenSSH verwenden , das zusammen mit gut geliefert wird. Übrigens Offenheit, die es Ihnen im Wesentlichen ermöglichen würde , sich auf sichere Weise mit dem Remote-Computer zu verbinden. Mehr dazu in den kommenden Vorlesungen bestimmt. Überlassen Sie dies ebenfalls auf Standard. Offensichtlich verstehst du nicht, was Kampf oder dieser Checkout ist, daher kann ich dir momentan nichts dazu erklären. Belassen Sie die Standardeinstellung. Belassen Sie den Standard. Okay, das spricht über Git Pull. Auch dies ist zu weit fortgeschritten , als dass Sie es verstehen könnten. Überlassen Sie einfach alles den Standardeinstellungen. Ich bin Britin oder du verstehst vielleicht nicht alle Schritte hier drin. Versuche nicht einmal zu verstehen, dass es nicht nötig ist. Wir werden in den kommenden Vorlesungen alles untersuchen. Es ist völlig normal. Wenn du es nicht verstehst, ist das vollkommen in Ordnung. Vertrau mir. Klicken Sie auf Weiter. Aktivieren Sie das Dateisystem-Caching. Ja, das wollen wir, das würde die Leistung verbessern. Wir können auch diese Auswahl aufheben und auf Installieren klicken. Warte ein bisschen. In Ordnung, ich möchte die Versionshinweise nicht lesen. Kopf fertig. Okay, wir haben jetzt auf unserem lokalen Computer installiert. Lass uns gehen und das überprüfen. Wenn es tatsächlich installiert wurde. Ich bin Fenster geöffnet, Windows-Befehlsprozessor. Und geben Sie dann get ein. Wenn Sie eine Ausgabe wie diese sehen können. Das bedeutet, dass get erfolgreich installiert wurde. Und der Grund, warum wir den Befehl git vom Windows-Befehlsprozessor ausführen können , ist irgendwo in der Mitte des Installationsprozesses darum gebeten hatten, dass wir irgendwo in der Mitte des Installationsprozesses darum gebeten hatten, die Pfadvariable von holen Sie sich Windows-Registrierungsvariablen. Lass mich dir zeigen, was ich meine. Suchen Sie nach Enrollment-Variablen. Klicken Sie auf Systemregistrierungsvariablen bearbeiten. Wenn du auf den Pfad gehst. Hier sehen Sie den Pfad zur Bibliothek. Wann immer Sie also command ausführen, wird so etwas einfach ausgeführt. Windows OS wird sich tatsächlich all diese Teile ansehen , die hier aufgeführt sind. Und dann kommt es mit diesem Teil auf, wo es den Code hat , etwas mit dem GET-Befehl zu tun. Und daher können wir diese Ausgabe sehen. Wenn Sie dies entfernen, können wir keine Git-Befehle vom Windows-Befehlsprozessor ausführen , es sei denn, wir gehen explizit in dieses Verzeichnis und tun dies. Wie auch immer, wenn das alles verwirrend klingt, ignoriere einfach, vertrau mir, du wirst in den kommenden Vorlesungen alles verstehen. 7. 0106 Git CLI vs Git Bash vs Git GUI: Es gibt grundsätzlich drei Möglichkeiten , mit Git zu interagieren. Wir können entweder gets CMD oder Git Bash oder get GUI oder grafische Benutzeroberfläche verwenden. Gets CMV ist nichts anderes als der Windows-Befehlsprozessor, den wir zum Ausführen von Git-Befehlen verwenden. Tatsächlich hatten wir uns bereits in unserer vorherigen Vorlesung ein Beispiel dafür angesehen, in der wir die Installation von get testeten. Die andere Möglichkeit, die wir haben, ist die Verwendung von Git Bash , einem Tool, das wir zusammen mit Git installiert haben. Git Bash ähnelt dem Windows-Befehlsprozessor, außer dass wir Standard-Linux-Befehle verwenden können , um mit guten zu interagieren. Dies ist besonders nützlich, wenn Sie aus einem Linux-Hintergrund kommen , wo Sie es gewohnt sind , Linux-Befehle auszuführen. Und jetzt nehmen wir an, Sie arbeiten mit dem Windows-Betriebssystem. Sie müssen diese zusätzliche Lernkurve nicht in Anspruch nehmen, um den Windows-Befehl zu verstehen und mit Git zu interagieren. Um beispielsweise alle Dateien in einem bestimmten Ordner innerhalb der Windows-Befehlszeile aufzulisten , verwenden Sie dort den Befehl. In Linux verwenden Sie den Befehl ls, um alle Dateien aufzulisten. Wenn Sie einen Mac oder Linux verwenden, werden beide mit einer Unix-Shell geliefert. Du musst Git Bash nicht installieren. Git Bash ist nur für Windows-Betriebssysteme gedacht. Wenn Sie an keines dieser Tools gewöhnt sind, ist es natürlich immer besser, Git Bash gegenüber gutem cmd zu wählen. Und der Grund dafür ist, dass Sie, wenn Sie an Git Bash gewöhnt sind, auch zu einem späteren Zeitpunkt auf dem Linux-Betriebssystem arbeiten können , wenn Sie das tun würden. Die dritte Option, die wir haben, ist Get GUI oder grafische Benutzeroberfläche. Und wie der Name schon sagt, bietet dieses Tool eine grafische Benutzeroberfläche für die Interaktion mit Git. Nun muss ich erwähnen, dass get gooey nicht alle Funktionen unterstützt, die get zu bieten hat. Wir können mehr mit Git Bash erreichen oder CMD-Kämpfe bekommen , um Ruhm zu erlangen. Davon abgesehen hat eine gute GUI auch ihre eigene Rolle. Zum Beispiel, wenn Sie sich das Gesamtbild ansehen möchten , oder wenn Sie die gesamten historischen Veränderungen aus der Vogelperspektive betrachten möchten, und so weiter. Dann könnte es für Sie nützlich sein, die Abfrage zum Abrufen zu verwenden , um das Geld zu erhalten. Im Rest des Kurses werden wir jedoch Git Bash verwenden, da dies die beste Option ist. Wir könnten genauso gut irgendwann im Kurs den Get-Go-Weg erkunden . Aber wir werden uns hauptsächlich auf Git Bash konzentrieren, was auch die beliebte Wahl ist. 8. 0107 Grundlegende Bash Befehle: Schauen wir uns einige der grundlegenden Befehle an, die wir auf Git Bash ausführen können , um mit dem Windows-Dateisystem zu interagieren. Wenn Sie nun aus einem Unix- oder Linux-Hintergrund kommen, kennen Sie wahrscheinlich all diese Befehle. das Video gerne überspringen. Sie müssen sich den Rest der Vorlesung nicht ansehen. Und für andere fragst du dich vielleicht , warum wir diese Befehle haben? Nun, unter Windows erstellen wir Ordner. Schauen Sie sich an, was sich darin befindet, oder löschen Sie Ordner. Wir machen das grafisch , was Windows uns bietet. Wenn Sie jedoch dasselbe von Git Bash aus tun möchten, müssen wir diese Befehle verwenden, da Git Bash keine grafische Benutzeroberfläche enthält. Jetzt haben Sie vielleicht eine andere Frage. Warum müssen wir mit diesen Befehlen mit dem Dateisystem interagieren , wenn wir dasselbe unter Windows tun können? Die Antwort ist, du kannst es so oder so machen. Aber wenn Sie diese Befehle lernen, könnte es für Sie in Zukunft hilfreich sein. Wenn Sie beispielsweise unter einem Linux-Betriebssystem arbeiten , haben Sie dort kein Windows-Betriebssystem. Sie müssen mit diesen Befehlen mit dem Dateisystem interagieren . Und diese Befehle sind auch nicht schwer zu erlernen. Sie sind eigentlich ziemlich selbsterklärend. Zum Beispiel haben wir MKDIR steht für make directory. Und wie der Name schon sagt, hilft es Ihnen, ein Verzeichnis oder einen Ordner zu erstellen. Und dann haben wir CD-Ständer für Change Directory. Es wird Ihnen helfen, von einem Verzeichnis in ein anderes Verzeichnis zu wechseln . Und das ist der Befehl, mit dem wir innerhalb des Dateisystems navigieren. Und dann haben wir PWD-Stände für das gegenwärtige Arbeitsverzeichnis, das nur die Diät druckt, auf der wir uns gerade befinden , während wir an Git Bash arbeiten. Wenn Sie sich jemals fragen, in welchem Verzeichnis Sie arbeiten, dann ist dies der Befehl, den Sie ausführen müssen. Und dann haben wir Ls steht für Liste. Und das würde einfach alle Dateien in einem bestimmten Verzeichnis auflisten . Dieser Befehl, kombiniert mit der Option Bindestrich a, listet alle Dateien auf, einschließlich der versteckten Dateien. Und dann haben wir endlich unsere M steht für remove. Und wie Sie vielleicht vermuten, hilft uns dies dabei, einen Ordner oder eine Datei zu löschen. Nun würden einige dieser Befehle mit bestimmten Optionen kombiniert werden. Wir werden sie in einer Weile erkunden. Ich habe für diese Vorlesung einen Testordner erstellt. Und hier werden wir mit all diesen Befehlen experimentieren. Lassen Sie uns zunächst Git Bash starten. Du kannst Git Bash entweder über das Startmenü starten oder einfach mit der rechten Maustaste klicken und hier auf Git Bash klicken, um Git Bash im aktuellen Verzeichnis zu starten. Sie werden einen Bildschirm sehen , der ungefähr so aussieht. Beginnen wir damit, einen neuen Ordner zu erstellen. Also bekommt es den Befehl , den ich benutzen muss. MKDIR steht für make directory. Und ich gebe den Namen des Ordners oder Verzeichnisses an, das ich erstellen wollte. Nennen wir es meine App oder was auch immer. Das hat also ein neues Verzeichnis erstellt, um sicherzustellen , dass es tatsächlich ein Verzeichnis erstellt hat. Lassen Sie uns den Befehl ls ausführen, um alle Dateien im aktuellen Verzeichnis aufzulisten. Und tatsächlich sehen wir das Verzeichnis , das wir gerade erstellt haben. Wir können auch eine Option Bindestrich a anhängen , um alle Dateien aufzulisten, einschließlich der versteckten Dateien. Aber im Moment haben wir in diesem Gebiet keine versteckten Dateien, die wir zeigen könnten. Dieser Befehl wird sich jedoch in Zukunft als nützlich erweisen, insbesondere wenn wir das Geschenkverzeichnis erkunden möchten , das sich versteckt hat. Lassen Sie uns jetzt in das App-Verzeichnis einsteigen. Wie mache ich das? Weil der Befehl cd , um das Verzeichnis zu ändern. Und ich wollte dieses Verzeichnis erwähnen, drücken Sie die Eingabetaste und wir befinden uns derzeit im MyApp-Verzeichnis. Um sicherzugehen, dass wir uns in diesem Verzeichnis befinden. Lassen Sie uns den Befehl PWD ausführen , um das aktuelle Arbeitsverzeichnis zu überprüfen, und dies würde mein App-Verzeichnis drucken. Gehen wir nun zum übergeordneten Verzeichnis meiner App. Also wie mache ich das? Wir machen CD-Raum, Punkt Punkt Schrägstrich. Wenn Sie zum Verzeichnis der Großeltern gehen möchten, haben Sie nur noch einen Punktstrich. Und das wird den Trick machen. Ich möchte jedoch nur in das übergeordnete Verzeichnis gehen. Jetzt machen wir den Befehl ls, um alle Dateien aufzulisten. Nehmen wir an, ich möchte diesen Ordner löschen, erhalte den Befehl, es ist RM und den Namen des Ordners. Dadurch wird der Ordner jedoch nicht gelöscht. Nun, der Ordner wird nicht gelöscht da dieser Benutzer nicht die Berechtigung dazu hat. Oder dieser Ordner enthält möglicherweise Dateien. Und es fordert uns auf, diese Dateien zuerst zu löschen. Nur dann können wir diesen Ordner löschen? Wir wissen jedoch, dass dieser Ordner keine Dateien enthält. Also muss es der andere Grund sein. Um dies zu umgehen, müssen wir zusammen mit dem RM-Befehl eine Option hinzufügen, und das ist der Bindestrich r, f. R steht für rekursiv und F steht für force. Rekursiv würde bedeuten, dass wir sagen, wir nicht nur diesen Ordner löschen wollen, sondern auch alle darin enthaltenen Dateien? Und Anstrengung bedeutet Kraft. Mit anderen Worten, wir möchten das Löschen des Ordners unabhängig von den Berechtigungen erzwingen . Ich gebe den Namen des Ordners an. Und dieses Mal wird der Ordner gelöscht. Wenn wir das jetzt tun, wird dieser Ordner nicht mehr angezeigt. Nehmen Sie sich also fünf bis zehn Minuten Zeit und versuchen Sie mit diesen Befehlen zu experimentieren und zu spielen. Versuchen Sie einfach, Ordner zu erstellen, Ordner zu löschen, sich anzusehen, was sich in den Ordnern befindet usw. 9. 0108 Was genau ist Git Commit: Du hast wahrscheinlich von Git Commit gehört, aber was genau ist das? Lass uns einen Blick darauf werfen. Stellen Sie sich vor, Sie spielen ein Videospiel. Und gehen Sie davon aus, dass Sie im Spiel so weit fortgeschritten sind, dass Sie nicht riskieren möchten, zu verlieren. Sie speichern das Spiel zu diesem Zeitpunkt, indem Sie eine aussagekräftige Nachricht geben, spielen das Spiel weiter und machen einige Fortschritte. Und wieder einmal möchten Sie das Spiel retten. Und Sie beginnen einfach damit, eine aussagekräftige Botschaft zu vermitteln. Und wenn mit Ihrem Spiel etwas schief gehen sollte, schauen Sie sich einfach die gesamte Liste der Spielstände an, die Sie erstellt haben schauen Sie sich einfach die gesamte Liste der Spielstände an, die Sie , und laden das Spiel an einem bestimmten Punkt. Nun müssen Sie beachten, dass das Speichern hier eigentlich kein Backup ist. Es ist wie eine Momentaufnahme. Beispielsweise können Sie die Speicherdatei nicht einfach kopieren und auf ein anderes System übertragen dem dasselbe Spiel installiert ist, und das Spiel von diesem gespeicherten Punkt aus laden können . Das ist nicht möglich. Wenn es sich jedoch um ein Backup handelt, erstellen Sie eine Sicherungskopie des gesamten Spiels. Wenn sich das Spiel beispielsweise in einem Ordner befindet, kopieren Sie einfach den gesamten Ordner, übertragen ihn auf ein anderes System und starten das Spiel dort, wo Sie beginnen möchten. Hier gespeichert ist im Wesentlichen wie ein Snapshot, aber nicht gerade ein Backup. Eine ähnliche Analogie kann mit Windows-Wiederherstellungspunkten erklärt werden . Möglicherweise erstellen Sie mehrere Wiederherstellungspunkte indem Sie eine aussagekräftige Nachricht geben. Und wenn etwas mit Ihrem System schief geht, vielleicht ein Virus oder so, wünsche ich mir wirklich, dass das nicht passiert. Aber wenn so etwas passiert, schauen Sie sich einfach alle wiederhergestellten Listen an , nachdem Sie sie erstellt haben, wählen Sie eine davon aus und setzen das System wieder in seinen früheren Zustand zurück. So wie Sie Punkte für Microsoft wiederhergestellt oder die Option zum Speichern für ein Spiel gespeichert haben , haben Sie git commit. Für dein Projekt. Sie werden in Ihrem Projekt einige Fortschritte machen. Nehmen wir zum Beispiel an, Sie haben über Feature 1 gebloggt. Und dann haben Sie das Gefühl , genug getan zu haben, um das Projekt zu speichern oder das Projekt zu übertragen. Sie tun genau das, indem Sie den Befehl git commit verwenden. Und dann machst du mit dem Projekt weiter. Sie arbeiten an einer anderen Funktion und übertragen das Projekt dann mit einer aussagekräftigen Botschaft. Und wenn bei Ihrem Projekt etwas schief geht, können Sie mit get zum früheren Status des Projekts zurückkehren oder eine bestimmte Datei auf ihre früheren Versionen zurücksetzen usw. So wie saved kein Backup in einem Spiel. Git commit erstellt eigentlich keine Sicherungskopie Ihres gesamten Projekts, sondern erstellt einen Schnappschuss Ihres Projekts zu diesem bestimmten Zeitpunkt. So haben Sie ein Projekt mit all diesen Dateien erstellt . Und jetzt haben Sie das Gefühl , genug getan zu haben, um das Projekt zu speichern oder alle Änderungen im Projektarchiv zu übernehmen. Jetzt können Sie nicht einfach den Befehl git commit ausführen und alle Dateien erwähnen , auf die Sie zugreifen möchten. So funktioniert das nicht. Leider ist noch ein zusätzlicher Schritt erforderlich, bevor Sie reinkommen. Und dafür gibt es einen Grund. Sie könnten beispielsweise andere Dateien im Projekt haben , die nicht zum Commit bestimmt sind. Sie möchten nicht, dass andere Teammitglieder auf diese Dateien zugreifen können. Es könnte zum Beispiel einige automatisch generierte Dateien sein oder Sie könnten bestimmte Dateien haben die nur für die lokale Verwendung bestimmt sind, aber für die Außenwelt nicht verfügbar sein sollten. Und hier haben wir einen zusätzlichen Schritt, bei dem Sie alle Dateien, die Sie verfolgen wollten, keinen Motor bekommen müssen . Derzeit werden all diese Dateien in deinem Arbeitsverzeichnis nicht wirklich von Git verfolgt. Sie müssen explizit angeben, welche Dateien Sie verfolgen wollten. Das kannst du mit dem Befehl git add machen. Sie möchten diesen Befehl verwenden git add. Und Sie haben in diesem Fall alle Dateien erwähnt, wir werden sie nach Layer-Datei, Datei C und D erwähnen und den Befehl ausführen, der im Wesentlichen alle diese Dateien in den Staging-Bereich kopiert. Und zu diesem Zeitpunkt beginnt get, diese Dateien zu verfolgen. Sobald Sie das getan haben, werden Sie den Befehl git commit verwenden , um alle Änderungen an ein lokales Repository zu übertragen, oder manchmal auch als Objektdatenbank bezeichnet. Und das ist nicht der einzige Fall, in dem Sie möglicherweise git add git commit benötigen. Schauen wir uns einen weiteren Anwendungsfall an. Stellen Sie sich vor, Sie haben einige Funktionen zum Begehen. Und Sie haben gleichzeitig an beiden Funktionen gearbeitet und gehen davon aus, dass Änderungen an Feature 1 in Datei A und Datei B vorgenommen wurden. Und Feature zwei Änderungen wurden in Datei C und D vorgenommen. weiter zu verschiedenen Commits, nicht in einem einzigen Kommentar. Wie machen wir das? Wenn es kein Konzept der Inszenierung gibt? Und wenn wir den Befehl git commit verwenden würden, würde das all diese Änderungen übertragen, das wollen wir nicht. Mit dem Befehl git add fügen wir zunächst alle Dateien hinzu, die sich auf Feature eins beziehen. Und dann werden wir die Änderungen mit einer aussagekräftigen Botschaft übertragen, genauso wie wir beim Speichern eines Spiels eine aussagekräftige Botschaft erhalten . Wir werden dasselbe auch tun, um den Kometen zu verlassen. Sobald Sie damit fertig sind, werden wir die Dateien C und D hinzufügen und als Feature zu übernehmen. Über einen bestimmten Zeitraum. Wir werden all diese Kommentare in unserem lokalen Repository verwalten . Auf diese Weise können wir uns alle historischen Daten ansehen und alle historischen Daten ansehen unser Projekt auf seinen früheren Stand zurückbelohnen . Oder wir können was die bestimmte Datei einer bestimmten Version aus ihrer Vorgeschichte machen. Oder wir möchten uns den Unterschied zwischen der aktuellen Version der Datei und ihren früheren Versionen usw. ansehen der aktuellen Version der Datei und ihren früheren Versionen usw. . All das werden wir auf jeden Fall in den kommenden Vorlesungen untersuchen . Und irgendwann werden wir all diese Änderungen in ein zentrales Repository wie GitHub übertragen . Und das ist, dass alle anderen Teammitglieder auf Ihre Änderungen sowie auf alle Ihre Kommentare und historischen Daten zugreifen können Ihre Änderungen sowie auf alle Ihre . jedoch das Thema eines anderen Kapitels. Ich sollte auch erwähnen, dass ich, als ich anfing, Git zu verwenden einer lokalen GitHub-Community beigetreten bin. Jetzt habe ich ihnen diese Frage gestellt. Warum müssen wir ein paar Schritte ausführen, um die Änderungen zu übernehmen? Warum können wir nicht einfach einen Befehl haben , der ungefähr so aussieht. Wir werden git commit hyphen m erwähnen und dann wirst du eine Nachricht geben. Und dann listen Sie alle Dateien auf , die Sie übertragen möchten und die beispielsweise Feature 2 entsprechen könnten . Nun, ich habe von ihnen keine zufriedenstellende Antwort erhalten. In der Tat, wenn Sie über andere Versionskontrollsysteme wie Mercurial oder Subversive sprechen andere Versionskontrollsysteme , haben sie nicht diesen zusätzlichen Schritt die Dateien vor dem Commit hinzuzufügen. 10. 0109 Initialisierung des Projekts und Erforschen des dot git Ordners: Lassen Sie uns sehen, was es bedeutet, ein Projekt zu initialisieren. Um dies besser zu verstehen, nehmen wir an, dass ich einen Freelancing-Vertrag habe, während ich gebeten werde, eine Webanwendung für meinen Kunden zu erstellen. In meinem System habe ich diesen Ordner mit dem Namen meine App erstellt , in dem ich alle Dateien vorstellen werde, die erforderlich sind, um eine minimal funktionierende Anwendung zu erstellen . Jetzt könnte ich all diese Dateien mit der neuen Option hier erstellen . Aber ich werde es tatsächlich mit Git Bash machen , nur damit Sie mit all diesen Linux-Befehlen vertraut sind. Und die Befehle, die ich verwenden muss, heißen Touch. Und dann gebe ich den Namen der Datei an. Der Einfachheit halber nenne ich es einfach als Ein-Punkt-TXT. Nun ist es offensichtlich nicht sinnvoll, eine TXT-Datei zum Schreiben des Quellcodes zu haben . Aber wir sind nicht wirklich daran interessiert, hier Anwendungen zu erstellen , die wir lernen, auf die wir eingehen und bestimmte Annahmen treffen möchten . In ähnlicher Weise werde ich zwei Rod DXDY erstellen. Ich hab den Namen falsch verstanden. Und drei Punkte dx, dy. Benennen wir das in TXT mit zwei Punkten um. Also habe ich all diese Dateien erstellt. Derzeit wird jedoch keine dieser Dateien tatsächlich von Git verwaltet. Wenn ich zum Beispiel den Befehl git commit jetzt ausführen würde, wird eine Nachricht ausgegeben, die besagt, dass kein Git-Repository oder eines der übergeordneten Verzeichnisse ist. Wir müssen es also wissen lassen , dass es Ihr Projekt verwalten muss. Und die Art, wie Sie es sagen, ist die Verwendung eines Befehls git darin steht für Initialisierung. Sobald wir das Projekt initialisiert haben, bitten wir im Wesentlichen darum, ein schriftliches Projekt einzurichten. Es muss in unserem Projekt eingerichtet werden, Es muss in unserem Projekt eingerichtet um jetzt mit der Verwaltung eines Projekts zu beginnen. Ich werde Versionen erstellen, um die wir bitten. Und wenn Sie feststellen, hat es tatsächlich einen versteckten Ordner mit dem Namen dot get erstellt . Hier haben wir diesen Staging-Bereich, über den wir bereits gesprochen haben. Und hier haben wir die Objektdatenbank, über die zuvor gesprochen wurde. Falls Sie diesen Ordner nicht sehen können, müssen Sie die Option zum Anzeigen der versteckten Dateien und Ordner aktivieren . In Windows müssen Sie zur Registerkarte Ansicht gehen, auf Optionen klicken und auf Ordner und Suchoptionen ändern klicken. Und wieder sollten Sie auf der Registerkarte Ansicht in der Lage sein, diese Option zu finden, um die versteckten Dateien zu aktivieren oder anzuzeigen. Und hier ist es. Klicken Sie auf diese Option mit der Aufschrift Versteckte Dateien, Ordner und Laufwerke anzeigen . Klicken Sie auf Übernehmen und Okay, und Sie sollten diesen Ordner jetzt finden können . Schauen wir uns an, was sich darin befindet. Nun lohnt es sich offensichtlich nicht wirklich, in die Tiefe zu gehen und zu versuchen, alles zu verstehen, was hier drin ist. Wir werden einige davon im Rest des Kurses untersuchen , sobald wir es für angemessen halten. Aber im Moment gebe ich Ihnen nur einen Überblick darüber, was sich in diesem Ordner befindet. Wir haben diesen Hook-Ordner, in dem wir eine Reihe von Skripten haben. Diese Skripte würden definieren, was vor und nach einem bestimmten Ereignis getan werden muss . Zum Beispiel sind wir uns des Commit-Ereignisses bereits bewusst. Und dann haben wir das Skript mit dem Namen pre-commit. Wie der Name schon sagt, tut es etwas, bevor die eigentliche Commit-Logik ausgeführt wird. Also führe ich dieses Skript bevor ich die Commit-Logik ausführe. Wir könnten also Dinge wie die Validierung der Syntax haben und so weiter. Wenn Sie wirklich neugierig sind, was in den Skripten enthalten ist, können Sie mit der rechten Maustaste klicken und es mit Notepad Plus, Plus öffnen . Und gehen Sie einfach all diese Kommentare durch und versuchen Sie, ein Gefühl dafür zu bekommen, was es tut. Aber ich empfehle dir nicht, das zu tun. Verwechsle dich nicht selbst. Dann haben wir den Eingabeordner , in dem wir diese Ausschlussdatei haben. Öffnen wir es mit Notepad Plus, Plus. Wenn es in Ihrem Projekt Dateien gibt , die Sie nicht berücksichtigen möchten, würden Sie sie hier auflisten. Sie können auch Muster verwenden. Sie können zum Beispiel Sternpunktprotokoll sagen. Und jetzt würde get alle Dateien mit beliebigem Namen ignorieren, hat aber die Punktprotokoll-Erweiterung. Nur ein Beispiel. Übrigens ist die Ausschlussdatei etwas, das sich lokal auf einem Computer befindet. Und was auch immer Sie hier hinzufügen, gilt nur für Ihren eigenen Einleger, innerhalb Ihres lokalen Systems. Wenn Sie Ausschlüsse für alle Teammitglieder haben möchten , gibt es dafür eine separate Sache namens Gitignore. Wir werden in den kommenden Kapiteln darüber sprechen. Als Nächstes haben wir den Ordner objects. Hier speichern gute Lebensmittel alle historischen Daten oder den Versionsverlauf. Dies ist das, was wir als Objektdatenbank bezeichnen . Derzeit enthält dieser Ordner nicht viele Daten. Aber sobald wir ein paar Kommentare abgegeben haben, werden Sie sehen, dass dieser Ordner gefüllt wird. Sie werden sehen, wie eine Reihe von Ordnern erstellt werden. Innerhalb des Objektordners. Wir haben den Ribs-Ordner, aber das spricht nicht darüber, denn um das zu verstehen, müssen Sie wissen, was ein Commit-Objekt, Hashing usw. ist . Also werden wir es vorerst überspringen. Die Konfliktdatei werden wir in der nächsten Vorlesung untersuchen. Die Beschreibungsdatei hat etwas mit Git Web zu tun. Und da du get web nicht kennst, macht es für mich keinen Sinn, darüber zu sprechen. Jetzt sofort. Der Kopf hat etwas mit Verzweigung zu tun. Also reden wir darüber. Als wir über Filialen sprachen. Lass uns weitermachen. Eine Sache, die ich auch erwähnen sollte , ist , dass das Einsteigen ein sicherer Betrieb ist. Nehmen wir an, dass ich eine Weile an meinem Projekt gearbeitet habe und ein paar Kommentare abgegeben habe und dann versehentlich davon ausgehen, dass ich den Befehl innerhalb unseres Projekts erneut ausführe. Das wird keinen Schaden anrichten. Alles würde so bleiben wie es ist, als ob wir diesen Befehl überhaupt nicht ausführen würden. Wenn Sie diesen Ordner jedoch löschen, wird das Probleme verursachen. Sie werden alle historischen Daten, den gesamten Versionsverlauf usw. verlieren . Und dann müssten Sie entweder das Projekt neu initialisieren, aber den Befehl git init ausführen und von vorne anfangen. Oder Sie müssen das Projekt aus dem zentralen Repository auschecken , das wir in den kommenden Kapiteln untersuchen werden. Als Faustregel gilt jedoch, Sie immer daran denken sollten, sich nicht mit diesem Ordner anzulegen , es sei denn, Sie wissen, was Sie tun. Die Tatsache, dass es standardmäßig ausgeblendet ist, sollte Ihnen sagen , dass es nicht für Entwickler wie Sie und mich gedacht ist , sondern für sich selbst verwendet werden soll. Es kann jedoch Fälle geben, in denen Sie einige Änderungen vornehmen oder etwas in diesem Ordner tun müssen . Zum Beispiel haben wir bereits über die Info-Ausschlussdatei gesprochen , in der Sie möglicherweise einige Ausschlüsse hinzufügen möchten. Ansonsten möchten Sie sich in den meisten Fällen nicht mit diesem Ordner anlegen. Lass es einfach zu bekommen. 11. 0110 Konfigurieren von Git Credentials und Erkunden von lokalen globalen Systemkonfigurationen: Okay, lassen Sie uns sehen, wie wir Git-Anmeldeinformationen konfigurieren können , und versuchen, den tatsächlichen Zweck zu verstehen. Wir haben jetzt ein Projekt von get mit einer Reihe von Dateien initialisiert. Lassen Sie uns nun versuchen, den Befehl git commit auszuführen und zu sehen, was passiert. Du bekommst 12. Bitte fragen Sie, bitte sagen Sie mir wer Sie sind. Jetzt. Das Wasser fragt nach lokalen Commit-Änderungen für Sie, aber wer zum **** sind Sie? Und es hat auch Anweisungen gegeben, wie wir uns vorstellen können, indem wir diesen Befehl ausführen. Aber es geht nicht nur darum, dass Sie sich vorstellen, um diesen eigentlichen Zweck Sie diese Anmeldeinformationen konfigurieren. Nehmen wir zum Beispiel an, dass eines Ihrer Teammitglieder oder einen Fehler erhalten hat, der seinem Namen zugewiesen wurde, und dass dies nicht der Fall ist. Die Funktion funktioniert nicht wie erwartet. Bei der Analyse des Problems möchten sie sich alle historischen Änderungen in dieser Datei ansehen . Und dann stoßen sie eine zuvor eingeführte Änderung, die das Problem verursacht zu haben scheint oder ein Feature beschädigt zu haben scheint. Ratet mal was? Sie werden den Namen der Person und die E-Mail-Adresse der Person , die diese Änderungen vorgenommen hat. Sie werden sich mit ihnen in Verbindung setzen und sie bitten, den Fehler zu beheben. Aber wie bekommt man nein. All dies ist der Fall, wenn Sie diese Anmeldeinformationen im Inneren konfigurieren, wenn Sie einen Commit vornehmen und all diese Änderungen an das zentrale Repository übertragen, das GitHub sein wird. Es speichert auch diese Informationen darüber , wer welche Änderungen vorgenommen hat, und enthält Ihren Namen sowie Ihre E-Mail-Adresse. Wenn du also guten Code einführst, wird jemand zurückkommen und dich loben. Sind. Wenn du schlechten Code einführst, wird jemand zurückkommen und dir die Schuld geben. In den meisten Fällen ist es sowieso immer die Schuld, aber keine Kommentare dazu. Lassen Sie uns also sehen, wie wir die Anmeldeinformationen konfigurieren können , und get hat uns bereits mitgeteilt, wie das geht. Verwenden wir also diesen Befehl, git, config hyphen, hyphen global. Wenn wir diese globale Option festlegen, bedeutet dies, dass diese Anmeldeinformationen alle Projekte verfügbar sind, alle guten Projekte, die Sie in Ihrem System erstellen , die sich auf diesen bestimmten Benutzer beziehen. Wenn Sie zum Beispiel diese beiden Systeme angeben würden, wären diese Anmeldeinformationen systemweit wertvoll. bedeutet, dass für jeden Benutzer im System alle diese Anmeldeinformationen gelten. Wir haben auch eine weitere Option, die „lokal“ lautet. Das bedeutet, dass diese Sträflinge nur für das aktuelle Projektarchiv verfügbar sind, an dem Sie gerade arbeiten. Versuchen wir es zuerst mit local. Vielleicht lege ich zuerst den Namen fest. Sie können einen beliebigen Namen festlegen, aber es muss Ihr Name sein. Und ich drücke die Eingabetaste. Und ich werde auch eine E-Mail einrichten. Okay, schauen wir uns jetzt an wo diese tatsächlich bevölkert sind. Das ist also in der Mappe. Erinnern Sie sich nicht an frühere Vorlesung, ich erwähnte, dass wir über diese Konfigurationsdatei sprechen werden. Nun, hier würden all diese Anmeldeinformationen festgelegt. Versuchen wir nun, diese Anmeldeinformationen auf globaler Ebene festzulegen . Dieses Mal würde dies nicht unter Benutzerverzeichnis in Ihrem C-Laufwerk aufgefüllt werden . Lass mich das hochziehen. Daher sollten Sie innerhalb des Benutzerverzeichnisses in der Lage sein, die Git-Konfiguration zu finden. Und das würde sich dort widerspiegeln. Und wenn Sie die systemweiten Anmeldeinformationen festlegen , können Sie dies auch tun. Ich erwarte nicht, dass Ihr Computer von mehreren Personen verwendet wird , und alle tragen zu Ihrer Arbeit bei. Aber wie auch immer, lassen Sie uns das für das System einrichten, obwohl Sie eine Berechtigung benötigen. Das startet also nicht als Administrator aus dem Startmenü. Und dann können wir die Anmeldeinformationen festlegen und die Konfiguration abrufen. Es tut mir leid, der angeblich systemweit geänderte Benutzername. Ich werde sagen, das ist gelaufen und diese würden sich in den Programmdateien widerspiegeln. Lass mich dich dorthin bringen. Sie in den Programmdateien das ETC-Verzeichnis ab. Du wirst die Git-Konfigurationsdatei sehen. Und hier würden die Anmeldeinformationen eingetragen. Übrigens sollte ich auch erwähnen, dass lokale Anmeldeinformationen globale Anmeldeinformationen außer Kraft setzen. Und globale Anmeldeinformationen überschreiben die Anmeldeinformationen auf Systemebene. Also holen Sie sich, wir werden versuchen, die lokalen Anmeldeinformationen schnell zu erhalten. Wenn sie nicht verfügbar sind. Es wird versucht, die globalen Anmeldeinformationen zu durchsuchen. Andernfalls wären die letzten Optionen diese Systemanmeldeinformationen. Wenn keine davon gesetzt ist, wird offensichtlich ein Fehler angezeigt. Sie können sich auch die Anmeldeinformationen ansehen, indem Sie einen Befehl ausführen git config list. Irgendwo hier werden Sie den Namen und die E-Mail-Adresse wie in der Zelle sehen. Sie können auch eine Option angeben, um eine bestimmte Ebene von Anmeldeinformationen anzuzeigen, beispielsweise lokal. Und Sie können auch genauer angeben, welche Informationen in Config enthalten sind. Sie möchten einen Blick darauf werfen und sich zum Beispiel den Benutzernamen ansehen. Und es wird den Wert davon drucken. 12. 0111 Staging und Unstaging und Überprüfungsstatus: Lassen Sie uns sehen, wie wir instationäre Dateien innerhalb des Git-Repositorys bereitstellen können . Und wie ich bereits erwähnt habe, müssen wir Dateien bereitstellen, bevor wir planen, sie zu übertragen. Derzeit haben wir also drei Dateien in unserem Arbeitsverzeichnis. Lassen Sie uns planen, sie zu verpflichten. Lassen Sie mich das Fenster erweitern , damit Sie eine bessere Sicht haben. Lassen Sie mich auch den Befehl clear eingeben, um den Bildschirm zu löschen , sodass wir eine neue Ansicht erhalten. Ich werde eine ls machen , um alle Dateien aufzulisten. Und wir haben derzeit drei Dateien. Wenn ich versucht habe, git commit zu machen, wird es uns jetzt beschweren, dass wir nicht verfolgte Dateien in unserem Projekt haben. Wir brauchen mindestens eine Datei. Tract wird mindestens eine Datei im Staging-Bereich haben , um Commit durchführen zu können. Und das ist es, worüber es sich beschwert. Wie speichern wir diese Dateien? Ruft den Befehl ab, gut hat uns schon einen Hinweis gegeben. Es ist gut in. Also lass uns git hinzufügen. Und ich könnte einfach alle Dateien auflisten , die ich übertragen wollte. Zum Beispiel ein Punkt TXT-Leerzeichen zu Punkt TXT usw. Dies ist nützlich, wenn Sie zwei auswählen möchten, welche Dateien als Teil einer bestimmten Funktion enthalten sein sollen . In diesem Fall möchte ich jedoch alles festlegen. Also könnte ich einfach einen Platzhalterzeichenstil verwenden. Ich kann auch ein Muster verwenden. Zum Beispiel kann ich Star Dot TXT sagen, und dies würde alle Dateien mit einem beliebigen Namen mit der Erweiterung dot TXT inszenieren . Führen wir also diesen Befehl aus. Das ist was wir brauchen. Das hat jetzt alle unsere Dateien im Staging-Bereich bereitgestellt. Wie stellen wir sicher, dass alle unsere Dateien bereitgestellt wurden? Nun, es gibt einen Befehl , um den Status dieses Git-Status zu überprüfen . Der Befehl Git status zeigt uns eine Liste der nicht verfolgten Dateien, Liste von Dateien, die verfolgt werden, Dateien, die geändert werden, usw. Dieser Befehl ist nützlich, um den Status unseres Projekts im Verlauf dieses Kurses zu überprüfen unseres Projekts im Verlauf dieses Kurses Sie werden mehr über diesen Befehl erfahren. Nachdem Sie diesen Befehl ausgeführt haben, werden unsere Dateien unter Zu übernehmende Änderungen aufgelistet. Außerdem wurde die Farbe dieser Dateien grün, was bedeutet, dass diese Dateien jetzt verfolgt werden oder sich diese Dateien gerade im Staging-Bereich befinden. Was es in einem früheren Fall besagt , dass all diese Dateien unter nicht verfolgten Dateien aufgeführt und rot markiert sind. Nehmen wir nun an, ich wollte eine dieser Dateien aus dem Staging-Bereich entfernen , vielleicht weil ich sie versehentlich hier hinzugefügt habe . Wie machen wir das? Nun, Gott hat uns bereits einen Hinweis auf den Befehl gegeben , den wir ausführen müssen, um auf der Bühne eine Datei zu erhalten, die RM mit Bindestrich, Bindestrich zwischengespeicherter Option erhält. Immer wenn ich sage, dass Cached indiziert oder inszeniert sind, meinen wir alle dasselbe. Behalte das im Hinterkopf. Also hol dir RM Bindestrich, Bindestrich zwischengespeichert. Und ich werde die Dateien auflisten, die ich auf der Bühne haben wollte. Wenn ich alle Dateien auf der Bühne haben möchte, könnte ich ein Wildcard-Zeichen wie dieses verwenden. Und das würde alle Akten auf die Bühne stellen. Lass mich das machen. Dies hat also alle unsere Dateien nicht angegeben, um sicherzustellen , dass alle unsere Dateien auf der Bühne sind. Verwenden wir den Befehl git status. Und wie Sie sehen können, gibt es wieder den Abschnitt für nicht verfolgte Dateien und dort wieder rot markiert. Fügen wir sie wieder hinzu. Lassen Sie mich diesmal auf der Bühne eine einzelne Datei erstellen, vielleicht TXT mit zwei Punkten. Sie müssen sicherstellen, dass Sie diese Option im Cache verwenden. Wenn Sie diese Option nicht verwenden, hat dieser Befehl eine andere Bedeutung, die wir in den kommenden Vorlesungen sprechen werden. Dies hat einen zwei-Punkt-TXT inszeniert. Lassen Sie es uns wissen und überprüfen Sie den Status unseres Projekts. Und wie Sie sehen können, ist TXT mit zwei Punkten jetzt unter nicht verfolgten Dateien aufgeführt. Aber wie die anderen beiden Dateien unter Änderungen aufgeführt sind , um dabei zu werden. Nehmen Sie sich also einen Moment Zeit und experimentieren Sie mit diesen Befehlen, um instationäre Dateien zu inszenieren und diese Daten gleichzeitig zu überprüfen. Übernehmen Sie die Änderungen noch nicht. Wir werden in der nächsten Vorlesung darüber sprechen. Aber zögern Sie nicht und haben Sie keine Angst, mit all diesen Befehlen zu experimentieren . Möglicherweise haben Sie das Gefühl, dass diese Kommentare zu diesem Zeitpunkt ziemlich einfach und unkompliziert sind . Aber während wir in diesem Kurs voranschreiten und wenn ich immer mehr Git-Befehle vorstelle, werden Sie das Gefühl haben, dass sie sehr verwirrend sind. Also die einzige Waffe, die du brauchst, um diesen verwirrten Geisteszustand zu vermeiden. In seiner Praxis kann ich nicht betonen, wie wichtig es ist, all diese Befehle zu üben, sonst werden Sie sich bald verwirren. Wir sehen uns in der nächsten. 13. 0112 Verstehen mit mehreren usecases: Lassen Sie uns sehen, wie wir unsere Änderungen an das Git-Repository übertragen können . Übrigens, wenn ich Git-Repository sage, könnte ich unseren Projektordner mit Punkt-Git-Ordner meinen. Oder ich könnte auch den Objektdatenspeicher meinen , über den wir zuvor gesprochen haben. Das hängt vom Kontext ab. Um die Verwirrung zu vermeiden, nenne ich unser Arbeitsverzeichnis ist unser Projektordner als Git-Repository. Ich werde die Objektdatenbank als Objektdatenbank bezeichnen nur um Verwirrung zu vermeiden. Derzeit haben wir also all diese Dateien an Ort und Stelle. wir sicher, dass all diese Dateien bereitgestellt werden. Ich werde den Git-Status machen. Wir haben eine Datei , die nicht inszeniert ist. Also lass uns git machen, füge zwei Punkte TXT hinzu, um es zu inszenieren. Lass uns noch einmal den Git-Status machen. Und wir haben alle unsere Akten inszeniert. Ich werde sagen, git commit hyphen m. Und dann werden wir eine aussagekräftige Botschaft liefern. Warum müssen wir diese Botschaft übermitteln? Nun, beschreibt im Grunde die Änderungen, die Sie zu einem späteren Zeitpunkt vornehmen, wenn Sie oder jemand anderes in Ihrem Team, einen Blick auf alle historischen Änderungen oder historischen Commits werfen sollten . Sie erfahren auch , welcher Ausschuss sich dessen Botschaft ansieht. Sie könnten beispielsweise Änderungen vornehmen, um einen Fehler zu beheben, oder eine Funktion hinzufügen. Als gute Praxis. In Echtzeitanwendungen folgen wir einem bestimmten Format für diese Nachricht. Die erste besteht aus einer Kombination von alphanumerischen Zeichen, bei denen es sich im Wesentlichen um Kombination von alphanumerischen Zeichen, eine Defekt- oder Feature-ID handelt, die Sie aus Ihrem Fehlerverfolgungs-Tool auswählen. Wenn Sie für eine Organisation arbeiten, haben Sie möglicherweise ein Fehler - oder Feature-Tracking-Tool. Sie wählen die ID aus und geben sie hier ein. Zum Beispiel könnte es so etwas wie WI sein , einige numerische Codes. W steht für Workitem. Es könnte etwas anderes für dich sein. Und dann werden Sie eine beschreibende Botschaft produzieren. Und selbst diese Nachricht, würden wir aus dem Titel des Defekts aus dem Fehlerverfolgungstool auswählen ? Ich sage meine funktionierende App oder was auch immer. wir die Eingabetaste. Und alle Änderungen, die inszeniert wurden, würden jetzt übernommen. Und um sicherzustellen, dass wir alle Dateien festgeschrieben haben, machen wir den Git-Status. Und es zeigt nichts, was bedeutet, dass wir keine Dateien haben, um süchtig zu werden. Lassen Sie uns nun eine Änderung an einer der vorhandenen Dateien in unserem Arbeitsverzeichnis vornehmen eine Änderung an einer der . Dafür verwende ich den Befehl echo, nur um eine der Dateien mit einem Text auszufüllen. Mein Text in Datei eins zum Beispiel. Und ich werde diese Nachricht in einer Punkt-TXT-Datei speichern. Dieser Befehl entspricht dem Öffnen der Ein-Punkt-TXT-Datei und der Eingabe des Textes, meines Textes in der ersten Datei. Lass mich die Eingabetaste drücken. Jetzt werde ich den cat-Befehl verwenden, um zu sehen, was sich in der Ein-Punkt-TXT-Geste befindet. Ich habe Ihnen gezeigt, dass wir diese Nachricht dort haben , und sie druckt den Text in OneNote dxdy aus. Alles gut. Dies ist eine Änderung , die wir eingeführt haben, was bedeutet, dass wir sie in Szene setzen müssen , um dies zu begehen. Also lass uns noch einmal den Git-Status machen. Diesmal heißt es , dass wir eine Datei haben , die geändert wurde. Also müssen wir git add machen, um diese Datei hinzuzufügen und in den Staging-Bereich zu bringen . Git-Status. Es wird grün, was bedeutet, dass es bereit ist, gebunden zu werden. Ich werde erneut den Commit-Befehl verwenden. Bestätigen Sie die Änderungen. Lassen Sie uns vorerst die Defekt-ID entfernen. Lassen Sie mich nur eine aussagekräftige Botschaft geben. Geänderte Datei, zum Beispiel die Eingabetaste drücken, Status abrufen. Und tatsächlich haben wir unsere Änderungen vorgenommen. Betrachten wir nun einen Fall des Löschens einer Datei. Dafür verwende ich den Befehl RPM steht für remove. Und dann gebe ich den Dateinamen an. Lassen Sie uns es auf Punkt TXT bringen, eine andere Haltung. Nun ist dieser Befehl nicht spezifisch zu bekommen, dies ist ein typischer Unix-Befehl. Drücken Sie Enter. Ich werde nachsehen, ob es gelöscht wurde und ob es tatsächlich gelöscht wurde. Dies ist eine neue Änderung , die in das Projekt eingeführt wird. Ratet mal was? Wir müssen es inszenieren und sie dann wissen lassen, dass wir die Datei gelöscht haben. Und so spiegelt es sich auch in der Objektdatenbank wider. Der Git-Status zeigt also an , dass die Datei gelöscht wurde, aber diese Änderung wird nicht bereitgestellt. Also füge Punkt dxdy hinzu. Guter Status. Und wir haben Änderungen, die bereit sind, bearbeitet zu werden. Noch einmal, git commit mit einer aussagekräftigen Botschaft. Lassen Sie mich diesmal keine Nachricht eingeben und drücken Sie die Eingabetaste , um zu sehen, was passiert. Nun, es würde den Texteditor öffnen , den wir bei der Installation von Git ausgewählt hatten. In meinem Fall hat es Notepad Plus Plus für dich, es könnte etwas anderes sein. Hier müssen wir die Nachricht eingeben, die wir sonst mit der Option Bindestrich m eingeben würden , wenn wir sagen, dass die Datei gelöscht wurde. Um die Datei zu speichern und einfach zu schließen. Und es hat unsere Veränderungen begangen. Wir verwenden den RM-Befehl mit der Stimmung, der Datei. Und dann hatten wir den Befehl git add ausgeführt , um diese Änderungen zu inszenieren. Wir können diese beiden Schritte jedoch in einem Ziel ausführen, indem wir den Befehl verwenden get out from this time anstatt nur RM, ich sage get RM. Dadurch wird nicht nur die Datei entfernt, sondern wir werden diese Änderungen auch im Staging-Bereich vornehmen. Löschen wir zum Beispiel three dot dx, dy. Ich mache ls. Und wie Sie sehen können, wurde die Datei gelöscht. Aber wenn ich den Git-Status mache, , anders als bei RM-Befehlen, sind die Änderungen, anders als bei RM-Befehlen, diesmal bereits bereitgestellt und Sie können die Änderungen direkt übernehmen. Git commit, Bindestrich sie. Drei Dateien wurden gelöscht. Schauen wir uns nun die gesamte Liste der Commits an , die wir mit dem Befehl git log master gemacht haben . Master ist der Name des Zweigs und auch der Standardbranch. Wir werden zu einem späteren Zeitpunkt über Filialen sprechen . Aber jetzt führe diesen Befehl einfach blind aus, um die gesamte Liste der Commits zu sehen, die du gemacht hast. Der jüngste würde oben angezeigt. Wie du siehst. Wir haben unser erstes Commit, aber meine funktionierende App-Nachricht. Und dann haben wir die erste Datei geändert, wir haben die zu löschenden Dateien gelöscht. Drei Dateien. Ich kann auch den Autor sehen , der das getan hat. In diesem Fall ist es gemein für dich. Es ist alles, was Sie bei der Konfiguration der Anmeldeinformationen eingegeben haben . Wenn wir ein zentralisiertes Repository haben und wenn wir ein Team haben, das an einem Projekt arbeitet, können Sie die gesamte Liste der Commits sehen von mehreren Teammitgliedern ausgeführt wurden. Und wenn Sie einen Commit entdecken würden, der Probleme verursacht oder ein Feature möglicherweise kaputt macht. Sie können den Autor erreichen indem Sie ihm eine E-Mail schreiben. 14. 0201 Sha1 Hashing Algorithmus: Vergessen wir es für eine Sekunde und versuchen wir zu verstehen, was der Chavan-Hashing-Algorithmus ist. Der Siobhan-Hashing-Algorithmus, oder manchmal auch Hash-Funktion genannt, würde jede beliebige Datenmenge als Eingabe verwenden. Und es wird uns einen 40-stelligen HashCode geben , der eine Ausgabe hat. Die Größe der Eingabe spielt keine Rolle. Es kann so klein wie ein Byte sein, oder es kann so groß wie ein GB oder sogar ein TB sein. Die resultierende Ausgabe wird jedoch immer ein 40-stelliger Hashcode sein. Selbst wenn die Eingabe nur ein einzelnes Alphabet ist, wird immer noch ein 40-stelliger HashCode als Ausgabe angezeigt . Hier sind einige der Eigenschaften der Hash-Funktion. Dieselbe Eingabe würde zu demselben HashCode führen , egal wie oft Sie sie ausführen, sie kann dieselbe Eingabe liefern, die zu genau demselben HashCode führen wird . Sie können keine Daten aus einem bestimmten Hashcode generieren. Obwohl es möglich ist, Daten in einen Hash-Code zu konvertieren, ist es nicht anders möglich. Ich meine, wenn ich dir einen HashCode gebe, kann er keine Daten daraus generieren. Es ist wirklich schwierig, eine andere Eingabe zu finden , die zum gleichen HashCode führt, aber das ist nicht unmöglich. Sie könnten eine andere Eingabe haben, die genau demselben HashCode führen könnte. Aber die Wahrscheinlichkeit, es zu finden , damit Sie sich nicht einmal darum kümmern müssen. Hier ist ein weiterer Anwendungsfall, in dem hashCode verwendet werden kann , wenn wir die Register für Ihre Website verwenden , indem wir den Benutzernamen, das Passwort und andere Details eingeben . Anstatt das Passwort zu speichern und Textformat in der Datenbank zu zeichnen, speichern wir den Hashcode dieses Passworts, sodass der nächste Term-Benutzer versucht, sich anzumelden. Wir werden den Hashing-Algorithmus erneut für das eingegebene Passwort ausführen . Und dann werden wir sehen, ob die resultierende Ausgabe mit der in der Datenbank übereinstimmen würde. Wenn beide übereinstimmen, wird der Benutzer authentifiziert und erhält Zugriff. Der Vorteil des Speicherns von Hash-Code, anstatt das rohe Passwort im Textformat zu speichern , besteht darin, dass ein Hacker, der Ihr System hackt, Zugriff auf Hashcodes erhält, aber nicht auf die tatsächlichen Passwörter. Sie können mit dem HashCode nichts tun. Sie können sich beispielsweise nicht im Namen eines Benutzers mit dem HashCode anmelden . Der gesamte Hashing-Algorithmus wird als Sicherheitsmaßnahme verwendet. Sie können ein Set für einen anderen Zweck verwenden. Und es geht darum, verschiedene Objekte eindeutig zu identifizieren und zu erhalten. Und wir werden in der nächsten Vorlesung darüber sprechen. Versuchen wir nun, mithilfe der Git-Befehle Hash-Code aus Git Bash zu generieren . Der auszuführende Befehl ist ein gutes Hash-Objekt, aber vorher sollten wir den Befehl echo mit etwas Text verwenden . Ich werde Pipe-Zeichen verwenden und dann die Standardeingabe für das Hash-Objekt abrufen . Durch die Verwendung des Pipe-Zeichens sagen wir , dass die Ausgabe dieses Befehls die Eingabe dieses Befehls sein würde. Im Wesentlichen versuchen wir, den HashCode dieses speziellen Textes zu erhalten . wir die Eingabetaste. Wir haben einen HashCode für diesen Text. Und egal wie oft ich denselben Befehl ausführe, wir werden genau denselben HashCode sehen. Aber wenn ich auch nur eine kleine Änderung vornehme, würde sich der resultierende Hashcode völlig von dem unterscheiden, was wir gerade gesehen haben. Nehmen wir zum Beispiel an, ich habe gerade einen Charakter hinzugefügt und die Eingabetaste gedrückt. Sie werden feststellen, dass sich diese beiden Hash-Codes erheblich unterscheiden. Sie werden mehr über HashCode, eingehende Vorträge, erfahren . 15. 0202 Git Internals (Alles über Objektdatenbank) Teil 1: Um besser zu erklären, wie gut die Daten in der Objektdatenbank verwaltet und gespeichert werden. Ich habe alles in unserem Projekt gelöscht. Alle unsere Commit-Vorgeschichte, alle Änderungen, die wir eingeführt haben sind jetzt endgültig vorbei. Was wir hier haben, ist im Grunde ein brandneues Verzeichnis. Und ich werde jetzt Git Bash hier starten und eine Reihe von Dateien und Verzeichnissen erstellen. Ich möchte ein paar Dateien in diesem Ordner erstellen. Also verwende ich den Befehl touch one dot dx dy und dx dy. Dies hat ein paar Dateien erstellt. Darüber hinaus werde ich ein Unterverzeichnis in unserem Projekt vorstellen . Es gibt den Befehl, ein brandneues Verzeichnis zu erstellen. MKDIR steht für make directory. Ich nenne es als Vermögen. Wir haben also Vermögenswerte , die neu erstellt werden. Gehen wir hinein und erstellen dort auch eine Reihe von Dateien. Ich werde erstellen, ich möchte den Befehl touch one subdata dxdy, substance oder subdirectory verwenden den Befehl touch one subdata dxdy, substance , nur für unser Verständnis. Und zwei Sub-Punkt-TXT-Dateien. Lassen Sie uns auch etwas Inhalt in diese Datei aufnehmen. Kehren wir zum übergeordneten Verzeichnis zurück, das unser Projekt-Stammverzeichnis ist. Ich verwende den Befehl echo. Datei eins der nächsten Generation. Wir werden es in einer Punkt-TXT-Datei füllen. Und in ähnlicher Weise werden wir Text in der anderen Datei, stool, dxdy, füllen . Ein Sub, das wird in einen Subpunkt dx dy gehen, sich innerhalb des Assets-Unterverzeichnisses befindet. Also hier ist unsere Verzeichnisstruktur. Wir haben das Assets-Verzeichnis und einige Dateien im Root-Projektverzeichnis. Und innerhalb von Vermögenswerten, die wahr sind. Wir haben diese beiden Akten. Derzeit wird dieser Ordner nicht initialisiert. Also lass uns genau das tun. Steigen Sie ein, um dieses Projekt zu initialisieren. Und git füge alle Dateien hinzu. Git status, um den Status zu sehen. Und wie Sie sehen können, ist alles inszeniert. Lassen Sie uns nun die Änderungen übernehmen. Git verpflichten. Mein erster Kommentar. Das sollte funktionieren. In der nächsten Vorlesung werden wir die verschiedenen Objekttypen in Git verstehen und wie all diese Dateien in der Objektdatenbank gespeichert werden . Wir sehen uns in der nächsten. 16. 0202 Git Internals (Alles über Objektdatenbank) Teil 2: Lassen Sie uns darüber sprechen, wie gut es die Daten tatsächlich in der Objektdatenbank speichert . In unserer vorherigen Vorlesung hatten wir ein Projekt mit einer Reihe von Dateien erstellt und diese Änderungen übernommen. Und hier ist die Projektstruktur, die wir hatten. Wir haben den Ordner my app, der das Root-Projektverzeichnis ist. Innerhalb dessen haben wir einen Punkt, der Sie zu Punkt TXT und auch zu einem Unterverzeichnis namens Assets führt . Innerhalb des Assets-Verzeichnisses haben wir einen Subpunkt dx dy und dx dy. Schauen wir uns nun an, wie diese Dateien tatsächlich in der Datenbank gespeichert sind , für die wir die verschiedenen Arten von Objekten verstehen müssen , die get hat. Zuerst haben wir das Blob-Objekt für jede einzelne Datei, zu der Sie kommen. In der Datenbank wurde ein Blob-Objekt erstellt. Jedes der Blob-Objekte würde den Inhalt der entsprechenden Datei speichern . Zum Beispiel könnten wir ein Blob-Objekt für einen Punkt dxdy mit all seinem Inhalt erstellt haben. Jedes der Blob-Objekte hat auch einen eindeutigen Hash. Und wie Sie vielleicht vermutet haben, würde dieser Hash mit dem Siobhan-Hashing-Algorithmus generiert werden . Und die Eingabe dieses Algorithmus wäre der Inhalt der Datei. Es wird nicht wirklich der Siobhan-Algorithmus verwendet , um die Anwendung zu sichern oder so. Es verwendet es, um einen eindeutigen Bezeichner für seine Objekte zu erstellen . Und der Inhalt, der im Blob gespeichert wird , ist nicht in einem für Menschen lesbaren Format. Es wird in komprimiertem Format gespeichert. So kann ich es effizient speichern, verwalten und abrufen. Get bietet jedoch auch bestimmte Befehle , mit denen der Inhalt innerhalb des Blobs gelesen werden kann . Das werden wir in den kommenden Vorlesungen untersuchen. Nun, da es vier Dateien gibt die wir zuvor festgeschrieben hatten, werden in der Datenbank vier Blobs zusammen mit dem entsprechenden Inhalt dieser Dateien erstellt der Datenbank vier Blobs zusammen mit dem . Als nächstes haben wir drei Objekte. Das Tree-Objekt würde jedem einzelnen Direktor im Projekt entsprechen , einschließlich des Projekt-Stammverzeichnisses . Und genau wie beim Blob-Objekt wird das Baumobjekt auch einen eindeutigen Cache haben , um ein bestimmtes Baumobjekt eindeutig zu identifizieren. Darüber hinaus wird es Referenzen haben, die im Wesentlichen die Hash-Codes anderer Blob-Objekte oder drei Objekte oder eine Kombination aus beiden beibehalten anderer Blob-Objekte oder drei Objekte oder . Zum Beispiel haben wir ein paar Ordner in unserem Projekt. Und so werden sie alle ein paar von drei Objekten sein für jedes dieser Verzeichnisse erstellt wurden. Wir werden also ein Baumobjekt für das Assets-Verzeichnis erstellen lassen. Und in diesem Objekt werden die Referenzen hashCode seiner Dateien gespeichert . In diesem Fall würde dieses Baumobjekt den HashCode OPT Sub One Dot TXT und subdued oder TXT enthalten . Im Wesentlichen sind dies die Hashes der Blobs, die unter einem Punkt T bis zu Punkt TXT entsprechen . Und dann wird ein weiteres Baumobjekt für das übergeordnete Projektverzeichnis erstellt. Und es wird HashCode aus seinen eigenen Dateien haben. Darüber hinaus enthält es auch den hashCode des Unterbaums, der dem Verzeichnis assets entspricht. Und natürlich hätte jedes dieser drei Objekte seinen eindeutigen Hashcode, um sie eindeutig zu identifizieren sodass sie von einigen anderen Objekten aus referenziert werden können. Als nächstes haben wir das Commit-Objekt. Dies wird wieder einen eigenen eindeutigen Hash haben. Und dieser Hash wird basierend auf den Commit-Informationen generiert , wie dem Namen des Autors, E-Mail-Adresse, der eingegebenen Nachricht, dem Zeitpunkt, zu dem der Commit stattgefunden hat, usw. Und Commit object würde die Referenz oder hashCode des übergeordneten Baums enthalten. Darüber hinaus enthält es auch Informationen über den Namen des Autors, E-Mail-Adresse, die beim Commit eingegeben wurde usw. Und mit Ausnahme des allerersten Kampfes der commit object enthält auch eine Referenz oder einen HashCode des vorherigen Kommentars. Sie werden in den kommenden Vorlesungen wissen, wie wichtig es ist. Für die Änderungen, die wir gerade vorgenommen hatten. Auf diese Weise würden die Informationen in der Datenbank gespeichert. Wir haben also drei Objekte, die jedem einzelnen Direktor im Projekt entsprechen. Und dann haben wir auch Blob-Objekte, die jeder einzelnen Datei innerhalb des Projekts entsprechen . Nun ist es nicht unbedingt so, dass, wenn Sie zehn Dateien in Ihrem Projekt erstellt haben, zehn Blobs in der Objektdatenbank erstellt würden . Das muss nicht unbedingt so sein. Wenn Sie beispielsweise zwei Dateien mit genau demselben Inhalt haben zwei Dateien mit genau demselben Inhalt und beide beispielsweise genau denselben HashCode generieren würden . Dann wird get dafür nicht zwei verschiedene Blob-Objekte erstellen, sondern nur ein Blob-Objekt erstellen und stattdessen darauf verweisen. Wie auch immer, mehr dazu in den kommenden Vorlesungen. 17. 0204 Git Internals Anzeigen und Lesen von Git Objekte: Wir haben theoretisch verstanden, wie gut es die Daten tatsächlich verwaltet und in der Objektdatenbank speichert. Schauen wir uns das jetzt praktisch an, um die Dinge besser zu erklären. Ich zeige Ihnen auch eine grafische Darstellung dessen, was wir gerade tun , auf der rechten Seite des Bildschirms, damit Sie ein besseres Bild davon haben , was wir tun. Derzeit haben wir also nur einen Commit. Schauen wir es uns an. Also logge ich mich ein , um mir die ganze Liste der Commits anzusehen. Derzeit haben wir nur einen. Und wie Sie sehen können, haben wir Autoreninformationen, Datum und sogar die Commit-Nachricht. Darüber hinaus haben wir einen 140-Zeichen-Hashcode. Kannst du erraten, worum es bei diesem Hash-Code geht? Nun, hier ist der hashCode des Commit-Objekts, das diesem Commit entspricht. Wie sehen wir uns nun den Inhalt in diesem Kometenobjekt an ? Nun, dieser HashCode selbst gibt einen Hinweis darauf, wie wir zu diesem Commit-Objekt navigieren können. Lass mich dir zeigen, was ich meine. Ich bin im Projektverzeichnis. Lass es mich für dich vergrößern. Ich gehe in den Punkt-Git-Ordner. Und rate mal, in welchen Ordner wir gehen müssen. Das ist objects-Ordner. Jetzt haben wir hier eine Reihe von Ordnern, die nicht existierten, bevor wir die Änderungen übernommen haben. Wenn du dir jetzt den HashCode ansiehst und die ersten beiden Zeichen herausnimmst , heißt es 95. Wir müssen in den Ordner gehen. Und dann sehen Sie eine Datei mit dem Namen, im Wesentlichen aus den verbleibenden Zeichen des HashCodes besteht. Wir haben also 95 ECE, also weiter. 95 ist der Verzeichnisname und der Rest der Zeichen ist der Name der Datei. Und das ist es, was wir als Commit-Objekt bezeichnen . Wenn Sie versuchen, den Inhalt mit einem Notepad Plus Plus, Plus anzusehen , können Sie ihn nicht lesen, da er in einem anderen Format gespeichert wird , das für uns nicht lesbar ist. Die einzige Möglichkeit, den Inhalt darin zu lesen, besteht darin, den Befehl get kept file auszuführen . Und dann geben Sie die Option Bindestrich P steht für hübschen Druck. Und geben Sie den HashCode des Objekts , das Sie hübsch drucken möchten. Ich könnte den gesamten Hash-Code kopieren, oder ich könnte einfach die ersten Zeichen und hier einfügen. Und das würde Watson in das Kometenobjekt drucken. Wenn Sie sich den Typ des Objekts ansehen möchten, die Option Bindestrich d, um den Typ zu drucken. Und das ist zum Gegenstand gekommen. Lassen Sie uns das Objekt noch einmal hübsch drucken. Also hier, wie ich bereits erwähnt habe, haben Sie Informationen über den Autorencomputer und sogar die Commit-Nachricht. Darüber hinaus haben wir auch einen hashCode, der eigentlich der hashCode des übergeordneten Baumobjekts ist. Schauen wir uns also an, was sich innerhalb des Baum-Objekts befindet. Und ich werde den gleichen Befehl verwenden, um hübsch zu drucken, was sich innerhalb des Baumobjekts befindet. Ich kann einfach die ersten paar Zeichen kopieren. Füge es hier rein. Und wenn Sie die Eingabetaste drücken, werden Sie sehen, was sich darin befindet. Da wir zurück zum Root-Verzeichnis müssen, haben wir ein Unterverzeichnis und ein paar Dateien. Und wenn Sie sich ansehen, was sich in diesem Baumobjekt befindet, haben Sie ein paar Blobs. Jedes Blob würde einer einzelnen Datei entsprechen . In diesem Fall ist es ein Punkt dx dy und dx dy. Und dann zeigt es auch auf einen anderen Baum, oder es ist hashCode ausgeschaltet und ein anderer Baum oder der Teilbaum. Also können wir auch in den Unterbaum gehen. Lass uns das machen. Ruft die Ausgabe ab. Es werden die Blobs der beiden Dateien im Unterordner sein. Ein Subpunkt nimmt in Subpunkt-TXT auf. Übrigens können Sie diese Objekte im Ordner objects finden . So wie Sie das Commit-Objekt gefunden hatten. Es ist nicht anders. Da bin ich der Objects-Ordner. Sie werden einen Ordner finden. Das ist also das Unterbaumobjekt, über das wir gesprochen haben. Und in ähnlicher Weise können Sie auch die Blob-Objekte finden. Lassen Sie uns zum Beispiel über diesen Blob sprechen. Es beginnt mit 99, also gehen wir in dieses Verzeichnis. Und das ist ein Blob-Objekt. Lassen Sie uns versuchen, dieses Blob-Objekt hübsch zu drucken und wir sollten in der Lage sein, den Inhalt darin zu sehen. Und noch einmal, wenn Sie es mit Notepad Plus, Plus oder etwas anderem öffnen würden, könnten Sie nicht lesen. Und Sie sehen den Text , der sich in dieser Datei befindet. Auf diese Weise erhalten wir im Wesentlichen die Daten in der Objektdatenbank. Und das zu verstehen ist sehr wichtig für Sie, um zu verstehen, wie die Themen, die wir diskutieren werden, und die kommenden Kapitel. 18. 0205 Wie sich Blob Objekte verhalten: Lass uns über Blob-Objekte sprechen und wie sie innerhalb des Git-Repositorys verwaltet werden. Stellen Sie sich vor, ich habe ein brandneues Projekt mit der folgenden Datei erstellt , einem Punkt TXT, und sie enthält den folgenden Text. Hallo vom bekommen. dem Moment, in dem ich diese Datei zu diesem Staging-Bereich hinzufüge, wird get tatsächlich versuchen, einen Hash-Code aus dem Inhalt einer Punkt-TXT-Datei zu generieren . Und get wird dann prüfen, ob wir bereits Objekte in der Objektdatenbank haben , die diesem Hashcode entsprechen. Wenn es keine gibt, würde es ein Blob-Objekt mit dem gesamten Inhalt einer Punkt-TXT-Datei erstellen , natürlich in komprimiertem Format. Nehmen wir nun an, ich habe eine weitere Datei erstellt, sagen wir zwei Punkte TXT, mit genau dem gleichen Text wie zum groben Ein-Punkt-TXT-Hallo, nehme noch einmal an, dass ich diese Datei auf die Staging-Bereich. GetWidth. Versuchen Sie erneut, HashCode aus dem Inhalt einer Zwei-Punkt-TXT-Datei zu generieren. Und dieses Mal werden wir feststellen, dass wir bereits ein Objekt haben , das diesem HashCode entspricht. Also wird get kein weiteres Blob-Objekt erstellen. Der Grund dafür liegt auf der Hand. Warum sollten wir genau dasselbe Blob-Objekt erstellen wollen , wenn wir bereits eines haben. Warum verwenden wir nicht einfach den vorhandenen? Es ergibt Sinn, oder? Schauen wir uns das alles in der Praxis an. Für dieses Beispiel und vermeiden Sie jegliche Art von Schlussfolgerung. Ich habe einen neuen Ordner mit dem Namen Tests Tab erstellt. Und hier werden wir experimentieren und sehen, was Get-Blobs für uns tun können. Also lass mich starten und in diesem Ordner verprügelt werden. Wichtigste zuerst: Lassen Sie uns das Projekt initialisieren. Und lassen Sie mich weitermachen und eine Datei mit etwas Inhalt erstellen. Ich verwende den Befehl echo. Ich werde diese Nachricht in einer Punkt-TXT-Datei speichern. Dieser Befehl erstellt nicht nur ein Punkt-TXT-Dateimodul, sondern füllt es auch mit diesem Inhalt. Hallo vom Abrufen. Gehen wir nun in das Objektverzeichnis und sehen, wie es sich verhält. Lassen Sie mich diese Datei angeben, ein Punkt txt, git füge einen Punkt dx dy hinzu. Und in dem Moment, in dem ich das mache, sehen wir, dass ein neuer Ordner direkt in Objekten erstellt wird . Ratet mal, was diese Datei ist? Nun, das ist das Blob-Objekt für eine Ein-Punkt-TXT-Datei , das wir gerade erstellt haben. Also ja, Blobs werden erstellt, wenn die Datei im neuen Stadium nicht unbedingt vorhanden ist , wenn Sie die Änderungen übernehmen. Wenn Sie die Änderungen übernehmen werden das Kometenobjekt sowie die drei Objekte erstellt sowie die drei Objekte , die einer Reihe von Blobs entsprechen . In der Tat ist das der Zweck der Commit-Operation. Es ist ein Snapshot zu erstellen, der das Projekt zu diesem bestimmten Zeitpunkt gespeichert hat. Wir werden in der nächsten Vorlesung über Momentaufnahmen sprechen. Gehen wir zurück. Lassen Sie uns nun sehen, was passieren würde, wenn ich eine weitere Datei mit genau demselben Inhalt erstellen würde. Was das oft Punkt-TXT betrifft, werde ich den gleichen Befehl verwenden. Aber dieses Mal werde ich dieselbe Nachricht in eine Punkt-TXT-Datei einfügen. Lassen Sie uns die Akte inszenieren. Ich mache den Git-Status. Und wir haben diese beiden Dateien inszeniert. Wenn Sie jedoch feststellen, dass für TXT mit zwei Punkten kein neues Objekt erstellt wurde. Und den Grund dafür habe ich dir bereits erklärt. Da wir bereits ein Blob-Objekt mit genau demselben Inhalt haben, geht get nicht in create ein weiteres Objekt. Mit anderen Worten, in dem Moment, in dem wir das Extra unter dem Staging-Bereich hinzugefügt haben, versuchen Sie, den HashCode für diesen Inhalt zu generieren. Und es wird überprüft , ob wir irgendwelche vorhandenen Objekte in der Datenbank haben irgendwelche vorhandenen Objekte in , die diesem HashCode entsprechen. Für TXT mit zwei Punkten haben wir einen vorhandenen Blob und daher wurde kein weiterer Block erstellt. Das gleiche Prinzip gilt auch dann, wenn Sie eine Datei ändern würden. Nehmen wir zum Beispiel an, dass ich den Text darin ändern wollte, um dxdy von der Datei zu rocken, zum Beispiel werden wir den Text in die Punkt-TXT-Datei ersetzen. Lassen Sie uns diese Datei inszenieren. Können Sie jetzt raten, ob ein neuer Ordner im Ordner objects erstellt wird , die Antwort lautet natürlich ja. Wir haben ein neues Blob-Objekt erstellt, da dieser Inhalt hier einzigartig ist und es dafür kein vorhandenes Blob-Objekt gibt. Lassen Sie uns auch eine weitere Datei erstellen, Drei-Punkt-TXT-Datei mit dem gleichen Inhalt wie die oft Punkt-TXT-Datei. Und lassen Sie uns die Datei Git Status treppen. Und wir müssen diese drei Akten festschreiben. Ein Punkt dx dy und dx dy, oder genau den gleichen Inhalt haben, während do route dxdy eine andere Textur hat. Lassen Sie uns nun die Änderungen übernehmen. Nun, das sind keine Angebote, aber was auch immer. wir die Eingabetaste. Und wie Sie sehen können, haben wir sowohl Commit als auch das Tree-Objekt erstellt, gleich nachdem wir die Änderungen vorgenommen haben. Schauen wir uns nun an, was sich innerhalb des Baum-Objekts befindet. Ich werde ein Log bekommen, um den hashCode des Commit-Objekts zu erhalten. Git cat file item B. Lassen Sie uns überprüfen, was sich in diesem Baumobjekt befindet. Also sollten sowohl ein Punkt dx, dy als auch Drei-Punkt-TXT als auch Drei-Punkt-TXT auf genau dasselbe Blob-Objekt zeigen. Wenn Sie feststellen, dass sowohl ein Punkt TXT-Eintrag dxdy auf genau dasselbe Blob-Objekt zeigen. Während es sich bei TXT mit zwei Punkten um ein anderes Blob-Objekt handelt. 19. 0206 Müllsammlung und Packungsdateien: Jetzt haben Sie vielleicht eine Frage. Jedes Mal, wenn wir eine Datei hinzufügen oder eine Datei ändern und sie in den Staging-Bereich bringen, sehen wir, dass das Blob-Objekt in der Objektdatenbank erstellt wird . Und get wird sie nicht einmal löschen. Auch wenn Sie die Dateien aus dem Staging-Bereich instabil würden . Ist das effizient oder nimmt es zu viel Platz ein? Die Antwort ist natürlich, dass es nicht ganz effizient ist. Aber gut hat dieses Konzept der Garbagecollection, das regelmäßig passiert oder wenn Sie bestimmte Befehle ausführen, wie zum Beispiel get pulled, werden wir über git pull, git push sprechen Befehle, sicher eingehende Kapitel. Aber es gibt bestimmte Befehle, die auch die Garbage-Collection auslösen. Das Konzept der Garbagecollection ähnelt in gewisser Weise Garbagecollection in anderen Programmiersprachen. Zum Beispiel haben wir eine Garbagecollection in Programmiersprache Java, der alle nicht referenzierten Objekte zerstört würden. Und das gleiche wie bei Git. Es ist sicher kein 100% iger Wirkungsgrad, aber es hat auch einen Mechanismus, um die Objekte effizient zu verwalten. Tatsächlich können wir die Garbage Collection manuell ausführen. Holen wir uns GC. Und wenn Sie feststellen , dass die zuvor existierenden Objekte nicht mehr existieren. Bedeutet das, dass alles für immer gelaufen ist? Die Antwort lautet nein. All das haben wir immer noch. Wenn Sie beispielsweise diesen Befehl ausführen, werden wir immer noch sehen, wie diese Objektinformationen vorliegen, und Sie können sogar den Inhalt in diesen Blob-Objekten lesen. Wie ist das jetzt möglich? Wir haben diese Objektordner nicht, konnten diese Objekte aber trotzdem lesen. Nun, es ist in diesem hinteren Verzeichnis. Im Wesentlichen hat dieser Garbage-Collection-Vorgang all diese Objekte weiter in eine einzelne Paketdatei komprimiert. Wir haben auch idx, unsere Indexdatei. Dadurch wird angezeigt, welches Objekt sich in welcher Back-Datei befindet. Derzeit haben wir nur eine einzige Pack-Datei, da alle Projekte sehr klein sind. Aber da wir immer mehr Dateien in ein Projekt eingeführt haben, werden neue Packdateien eingeführt. Zu diesem Zeitpunkt würde ein Index ins Bild kommen. Aber darüber müssen wir uns sowieso keine Sorgen machen. Sie können Watson auch in der PAC-Datei überprüfen. Lass mich Git Bash in diesem Ordner starten. Und der zu verwendende Befehl ist get, verify back, hyphen v. Und dann gebe ich den Namen der gepackten Datei an, und das würde alle Objekte darin drucken. Eine Sache, die ich auch erwähnen sollte , ist , dass Technologie süchtig macht. Wenn wir alles lernen wollen. Der Himmel ist die Grenze, wie tief wir gehen und jedes einzelne Konzept verstehen können. Aber ist es das wert? Das ist die Frage. Du willst da draußen nicht wirklich alles lernen. Das ist es einfach nicht wert. Weil wir bereits eine Menge Dinge zu besprechen haben und zu besorgen ist nur der Ausgangspunkt und Ihre DevOps-Reise. Für mich als Ausbilder muss ich alles wissen und recherchieren. Was hat gut zu bieten, damit ich herausfiltern kann , was für dich benötigt wird und was nicht. Tatsächlich zögere ich, überhaupt über diese Konzepte zu sprechen, aber ich fand, dass es sehr wichtig ist, dies zu verstehen , um alle zukünftigen Konzepte zu verstehen, über die wir in kommenden Kapiteln sprechen werden. Aber ansonsten zögere ich, über all diese Konzepte zu sprechen , die in Ihrem Gettier keine Rolle spielen. kann ich machen, wenn ich will. Ich kann dir einfach Dinge beibringen , nur um zu beweisen, dass ich darüber weiß. Aber das ergibt weder für dich noch für mich Sinn. Meine Aufgabe ist es, Ihnen die Arbeit zu erleichtern und nicht Ihre Arbeit zu komplizieren. Und ich würde es vorziehen und mein Bestes geben, dir nur das beizubringen , was für deinen Job absolut notwendig ist. Das musst du im Hinterkopf behalten und nicht versuchen, alles zu lernen. Das ist eine der größten Erkenntnisse, die ich in meiner Karriere gemacht habe. Ich habe einfach versucht alles zu lernen. Tatsächlich macht Technologie sehr süchtig. Je mehr Sie erkunden, desto mehr möchten Sie mehr wissen und es lohnt sich nicht. Es ist eine Art Unterhaltung für sich, vielleicht auf seltsame Weise, aber es ist für mich. Ich muss dir diesen Schmerz nicht antun. 20. 0207 Git Snapshot Was bedeutet es, einen Snapshot zu machen: Versuchen wir zu verstehen, was ein guter Schnappschuss ist. Zuvor hatten wir ein Projekt erstellt, in dem wir einige Dateien im Stammverzeichnis des Projekts hatten . Und dann haben wir auch ein Unterverzeichnis , in dem wir ein paar weitere Dateien haben. Wenn Sie sich an unsere früheren Vorlesungen erinnern könnten. Dies war die Objektstruktur, die wir hatten, als wir unser erstes Commit machten. Lassen Sie mich dieses Diagramm vereinfachen , damit es kompakter aussieht. Nehmen wir nun an, dass ich eine andere Datei eingeführt habe, c3 dot dxdy mit dem folgenden Text hallo von get. Und ich habe das im Root-Projektverzeichnis behalten , bleibt diese Datei. Und dann habe ich die Änderungen vorgenommen. Können Sie sich nun vorstellen, wie die Objektstruktur aussehen würde? Für das zweite Commit, das wir machen? Stell dir so etwas vor? Wir haben also ein neues Blob für die neu eingeführte Datei erstellt. Sie außerdem, dass Erwarten Sie außerdem, dass Sie Blobs für jede einzelne Datei im Projekt erstellen können? Die Antwort lautet natürlich nein. Stattdessen erstellt Git einen Blog für die neue Datei. Und das Root-Tree-Objekt des neuen Commits wird den Hash dieses neuen Blobs enthalten. Und für alle anderen Dateien ihre vorhandenen Blobs und drei Objekte, da sie unverändert geblieben sind und nicht geändert bezieht sich Git einfach auf wurden. Im Wesentlichen würde der Inhalt des Tree-Objekts und der zweiten Spalte genau dem Kondensator des Tree-Objekts in unserem ersten Commit entsprechen, außer dass es einen zusätzlichen Eintrag geben wird für die neu eingeführte Datei. Darüber hinaus wird das Commit-Objekt auch den Unterschied enthalten oder der HashCode des vorherigen Commits oder seines übergeordneten Objekts kommen. Die Bedeutung davon werden Sie in späteren Kapiteln kennen. Also was ist dieser Schnappschuss hier? Nun, im Wesentlichen machen Sie jedes Mal, wenn Sie ein Commit durchführen, eine Momentaufnahme des Status des Index oder des Staging-Bereichs zum Zeitpunkt des Commits. Es erfasst im Wesentlichen, wie jede Datei zum Zeitpunkt des Commits aussah. Wenn Sie zu einem der vorherigen Commits zurückkehren würden , Git alle Dateien in Ihrem Arbeitsverzeichnis so wiederherstellen, wie sie waren, als Sie den Kommentar abgegeben haben Ihrem Arbeitsverzeichnis . Wie ist das möglich? Es ist wegen des Schnappschusses. Sehen wir uns das alles jetzt in der Praxis an. Ich bin in unserem guten alten Ordner für meine App. Lassen Sie mich weitermachen und eine neue Datei erstellen. Wir haben also drei Punkte dx, dy mit etwas Text drin. Git füge git commit hinzu. Zweiter Commit. Zum Schluss geben wir noch eine zweite Bemerkung ab. Lassen Sie uns nun das Commit und drei Objekten untersuchen . Ich werde Git Log machen , um die ganze Liste der Commits anzusehen. Übrigens, wenn wir über den Elternkampf sprechen, wenn wir diesen Befehl ausführen git log, hat er die Details zu unserem letzten Commit angezeigt. Und dann hat dieses Kommentar-Objekt die Details seines übergeordneten Commits, das ist das. Und so wird git fortfahren und auch seine Details anzeigen. Für dieses Commit gibt es jedoch Commits, da dies das allererste Commit ist, das wir gemacht keine übergeordneten Commits, da dies das allererste Commit ist, das wir gemacht haben. Und so wird dieser Befehl nicht mehr ausgeführt. Wie auch immer, du wirst mehr über übergeordnete Commits und kommende Kapitel erfahren . Lassen Sie uns also loslegen und untersuchen, was von innen nach außen geht. Aktuelle Commit. Holen Sie sich die Datei, Bindestrich P. Und wie Sie sehen können, haben wir den hashCode des Root-Tree-Objekts. Darüber hinaus haben wir auch den hashCode des übergeordneten Commits, der dieser ist. Und dann Autoreninformationen und so weiter. Mal sehen, was in dieser Akte steckt. Also hier ist der Inhalt des Baum-Objekts. Vergleichen wir es mit dem Tree-Objekt unseres ersten Connects. Wenn Sie feststellen, ist der hashCode des Unterbaumobjekts genau der gleiche. Der Hashcode von einem Punkt dx dy und dx dy ist genau gleiche, mit Ausnahme der neu eingeführten Datei three dot dx dy. Das erklärt also. 21. 0208 Zeitreise mit Git: Mal sehen, wie wir Zeitreisen bekommen können. Ich meine, ich werde es dir in einer Weile beweisen. Nehmen wir an, Sie gehen Feature eins herunter und übertragen all diese Änderungen im Rahmen Ihres allerersten Commits. Und nehmen wir an, dass all diese Änderungen in einem Punkt TXT vorgenommen wurden. Und dann sagt Ihr Kunde, dass er eine weitere Funktion in seiner Anwendung benötigt. Sie möchten es also übernehmen und daran arbeiten, ein weiteres Commit durchführen und davon ausgehen, dass all diese Änderungen in die Punkt-TXT-Datei eingegangen sind. Ihr Kunde hat erneut eine kreative Idee. Er benötigte eine weitere Funktion in seiner Anwendung. Und noch einmal arbeiten Sie an dieser Funktion und machen ein weiteres Commit. Und dann nehmen wir an , Sie haben Drei-Punkt-TXT eingeführt , bei dem Sie all diese drei Funktionsänderungen haben . Nehmen wir nun an, der Kunde hat sich aus irgendeinem Grund entschieden, Feature 3 aus irgendeinem Grund nicht zu haben. Und dass er zur vorherigen Version dieser Anwendung zurückkehren wollte . Wie können Sie also alle Änderungen an Feature Drei rückgängig machen? In diesem Beispiel ist es ziemlich einfach. Sie löschen einfach die Drei-Punkte-TXT-Datei und machen dann einen weiteren Commit. Wie wir in einem unserer vorherigen Kapitel besprochen haben, ist das Umleiten von Änderungen jedoch keine leichte Aufgabe, da Änderungen in realen Anwendungen möglicherweise über mehrere Dateien verteilt sind. Und es ist wirklich schwierig, all diese Änderungen rückgängig zu machen , ohne die Dinge durcheinander zu bringen. Möglicherweise brechen Funktionen, die früher funktionieren. Glücklicherweise könnte get zur vorherigen Arbeitskopie unseres Projekts zurückkehren . Jetzt sollte ich auch erwähnen, dass der Ansatz, über den ich sprechen werde um zur vorherigen Version des Projekts zu gelangen, nicht der empfohlene Ansatz ist. Der empfohlene Ansatz ist die Verwendung von Branches, über die wir im nächsten Kapitel sprechen werden. Und im nächsten Kapitel werden Sie auch verstehen, warum dies nicht der empfohlene Ansatz ist , um Ihre Änderungen umzuleiten. Aber jetzt schauen wir uns das in Aktion an. 22. 0209 Zeitreise in der Praxis: Okay, schauen wir uns an, wie wir Zeitreisen können und sehen uns ein kurzes Beispiel an. Und noch einmal, um Verwirrung zu vermeiden, habe ich einfach alles im Desktop-Ordner bereinigt und wir werden alles von Grund auf neu machen. Lass mich starten und Git Bash. Mein Plan ist es, drei Commits zu machen. Und wir gehen davon aus, dass jeder Kommentar einzelnen Merkmalen entsprechen würde . Initialisieren Sie das Projekt. Berühren Sie einen Punkt TXT, git add. Wir bleiben bei dieser Datei, git commit. Und nennen wir es wie auch immer. Wir werden den Vorgang für das Hinzufügen von Features wiederholen. Nennen wir es TXT mit zwei Punkten. Git fügt zwei Punkte TXT und Git Commit hinzu. Feature zwei. Lassen Sie uns ein letztes Commit machen , das Feature drei darstellt. Und Git Commit gab es drei. Jetzt machen wir git log , um einen Blick auf die gesamte Liste der Objekte zu werfen. Lassen Sie mich diesen Ordner vergrößern , damit wir uns gleichzeitig ansehen können , was hier passiert, während wir die Befehle ausführen. Derzeit haben wir also diese drei Dateien. Nehmen wir nun an, ich wollte belohnen und zu einer der vorherigen Versionen des Projekts zurückkehren. Nehmen wir an, ich wollte zurückgehen wie mein Projekt aussah. Ich habe ein Feature gemacht, um zu kommen. Der Befehl, den ich verwenden muss, ist eigentlich switch. Beachten Sie nun, dass dieser Befehl möglicherweise nicht für Sie funktioniert, wenn Sie ältere Versionen von Git installiert haben . Laden Sie also nur die neueste Version von Git herunter und installieren Sie sie, dann wird dieser Befehl ausgeführt. Wenn du immer noch darauf bestehst, frühere Versionen von gaped zu verwenden, dann gibt es einen weiteren Befehl namens git checkout. Du musst das tippen. Und wenn Sie wie in meinem Fall die neueste Version installiert haben , funktionieren diese beiden Befehle problemlos. Ich bevorzuge jedoch die Verwendung von switch. Und dann werden wir den HashCode des Kampfes bereitstellen , dem wir uns widmen wollen. Lass mich den Code einfügen. Sie müssen nicht den gesamten Code einfügen. Die ersten Zeichen würden tatsächlich ausreichen. Wenn ich nun die Eingabetaste drücke, wir einen Hinweis von get, dass Sie, wenn Sie sich trennen möchten, gehen Sie zum Commit und versuchen Sie es erneut mit der Option detach. Was auch immer wir gerade tun, heißt eigentlich distanzierter Kopfzustand. Sie werden es im nächsten Kapitel verstehen und das auch sagen, dass eine Verzweigung erwartet wird. Aber es wurde engagiert. Wie ich bereits sagte, was auch immer wir gerade tun, ist eigentlich nicht der empfohlene Ansatz. Der empfohlene Ansatz besteht tatsächlich darin, Zweige zu verwenden. Wir werden im nächsten Kapitel noch einmal darüber sprechen. Das empfiehlt Git sogar. Es wird erwartet, dass wir einen Zweig und keinen Kometen verwenden. Lassen Sie uns fortfahren, indem die Option zum Trennen des Bindestrichs mit einbeziehen. Und wenn Sie den Moment bemerken, in dem wir diesen Befehl ausführen, sehen Sie keine Drei-Punkte-TXT-Datei mehr. Und selbst wenn Sie sich die ganze Liste der Commits ansehen würden , indem Sie git log machen. Es werden nur zwei Commits gedruckt. Im Wesentlichen. Wir sind gerade in der Zeit zurückgegangen , um das Projekt zu dem zurückzubringen was es war, als sie Feature zum Commit machten. Es ist gleichbedeutend damit, dass ich keine Änderungen vorgenommen habe, nachdem ich ein Feature erstellt habe. Wie cool ist das? Du kannst tatsächlich auch in die Zukunft gehen. Und ich liege nicht falsch , wenn ich das sage. Lassen Sie mich den HashCode von Feature drei zusammenstellen . Dieses Mal. Lassen Sie mich git checkout und Strauss ausführen, wobei ich dann den Hash des dritten Commits, unseres Feature-Tree-Commits, spezifiziere . Und schauen Sie sich an, was in unserem Arbeitsverzeichnis passieren würde . Nun, du siehst drei dx, dy wieder, wir sind zurück in der Zukunft. Wie cool ist das? Ich wünschte, es gäbe so etwas in unserem Leben. Ich meine, ich könnte einfach in die Vergangenheit reisen, Dinge in Ordnung bringen, vielleicht in Bitcoin investieren und in die Zukunft zurückkehren. Wie cool wäre es? Es ist nur möglich und wird im Moment. Es ist verrückt, aber gleichzeitig irgendwie gruselig, um ehrlich zu sein, aber das ist die Macht des Guten. Aber versuchen Sie trotzdem, mit dieser Funktion zu experimentieren. Spiel einfach damit herum. Und kümmern Sie sich nicht um Terminologien wie head, branch usw. werden wir im nächsten Kapitel sprechen . Eine weitere Sache, die ich erwähnen sollte, ist, dass immer dann, wenn wir einen anderen Commit wechseln oder auschecken, Get immer dann, wenn wir einen anderen Commit wechseln oder auschecken, das Arbeitsverzeichnis wieder auf das zurückbringen konnte das Arbeitsverzeichnis wieder auf das zurückbringen , was es war, als wir diesen Kommentar abgegeben haben. Und es ist sehr schnell passiert. Der Grund, warum es so schnell passiert, ist das Konzept des Schnappschusses, das wir in einer unserer vorherigen Vorlesungen besprochen hatten . In anderen Versionskontrollsystemen. Was die Geschichte ist eigentlich der Unterschied von Dateien im Vergleich zu ihren vorherigen Commits. Und wenn wir das Tool hinzufügen, um das Projekt auf einen bestimmten Zustand zurückzubringen , wird es tatsächlich alle Unterschiede zusammenfassen, um die Dateien wieder so zu erstellen, wie sie waren, als wir das Commit gemacht haben. Im Falle von get dreht sich jedoch alles um Snapshot. Grundsätzlich zeigt jedes Commit-Objekt auf einen Snapshot oder das Root-Tree-Objekt, das alle Informationen aller Dateien enthält , die sich in unserem Arbeitsverzeichnis befinden, und all seinen entsprechende Blob-Objekte. Es ist also relativ schneller. Vergessen Sie, den Inhalt von Blob-Objekten abzurufen, und fast sofort oder schnell laden Sie fast sofort oder schnell alle Dateien in das Arbeitsverzeichnis. Das ist die Stärke des Speicherns eines Schnappschusses im Vergleich zum Speichern der Unterschiede bei Pad-Sets wie wir es in einer unserer vorherigen Vorlesungen besprochen haben. Es ist, als würden Sie beim Spielen eines Spiels zwischen mehreren Verkaufsstellen hin und her wechseln. Etwas ähnlich dem. Hoffe es macht Sinn. 23. 0301 Leben ohne Zweige: Lassen Sie uns sehen, wie sein Leben vor Git Branches existierte. Und an diesem Bild erkennt man, dass es eine sehr frustrierende Erfahrung sein muss. Stellen Sie sich vor, wir haben Bob, der Anlageberater und Absender ist und Freelancer ist. Bob auseinander, um eine Bewerbung für ihn zu erstellen. Und der Absender hat eine Anwendung erstellt und Bob ist sehr zufrieden mit der Funktionsweise der Anwendung. Und jetzt hat Bob beschlossen, seiner Anwendung ein paar weitere Funktionen hinzuzufügen . Und der Absender hat zugestimmt, an diesen Funktionen zu arbeiten. Nehmen wir nun an, der Absender hat angefangen, auf Feature eins zu gehen , all diese Änderungen übernommen und Bob gezeigt. Bob ist ziemlich zufrieden mit der Funktionsweise der ersten Funktion. Und er hat grünes Signal gegeben , weiter an anderen Funktionen zu arbeiten. Der Absender hat also auch weiter an der Funktion gearbeitet. Und schickte Bob eine E-Mail, in er gebeten wurde, die Funktion zu überprüfen. Aber dieses Mal ist Bob ziemlich beschäftigt mit diesen Kunden. Und so hatte er keine Zeit, diese Funktion zu überprüfen. Einige dort haben jedoch beschlossen, weiter an anderen Funktionen zu arbeiten , denn wenn er weiter auf Bobs Antwort wartet, kann er die Projektfrist möglicherweise nicht einhalten. Also lieferte er auch Feature Drei und Feature für und schickte Bob eine E-Mail, in der er gebeten wurde , all diese Funktionen zu überprüfen. Bob hat alle Funktionen überprüft. Und aus irgendeinem Grund ist Bob mit Feature to End nicht zufrieden , dass er beschlossen hat, diese Funktion vollständig aus seiner Anwendung zu streichen . Also dachte Cinder ein bisschen darüber nach und erkannte , dass es wirklich schwierig ist , all diese Änderungen rückgängig zu machen. Denn wenn er versucht, all diese Änderungen rückgängig zu machen, könnte er am Ende einige der Funktionen , die gerade laufen, kaputt machen. Eine andere Sache, an die man denken muss, ist , zu einer der vorherigen Versionen des Projekts zurückzukehren , indem man den Befehl gets ausführt , die git checkout sind. Aber das Problem dabei ist , dass Cinder nicht nur die Funktion von Änderungen entfernt, sondern auch Feature drei und Funktionen für Änderungen, die gut funktionieren, loswerden wird . Und Bob ist mit diesen Funktionen sehr zufrieden. Dies ist nur die Spitze des Eisbergs in Bezug auf die Art von Problemen, mit denen wir konfrontiert sein könnten, wenn wir keine Zweige verwenden. In realen Anwendungen sind Sie beispielsweise möglicherweise nicht die einzige Person, die an der Anwendung arbeitet. Möglicherweise haben Sie die Codebasis und die Liste der Commit-Verläufe, sich für ein zentrales Repository und mehrere Teammitglieder entscheiden und möglicherweise aus mehreren Teams stammen, würden zu diesem Projekt beitragen. Jeder würde seine eigenen Commits machen und seine eigenen Funktionen einführen. Jetzt können wir nicht riskieren , zu einer der vorherigen Versionen zurückzukehren , und riskieren, die gesamte Anstrengung des Teams zu verlieren. Ein weiteres Problem, mit dem Sie möglicherweise ohne Zweige konfrontiert werden, besteht darin, dass Sie an mehreren Features gleichzeitig arbeiten möchten . Lass mich dir erklären, was ich meine. Angenommen, Sie haben all diese Funktionen zugewiesen und müssen sie vor Ablauf einer Frist beenden. Nennen wir sie Funktion F1, F2, F3 und F4. Es wird zwar nicht empfohlen , Multitasking durchzuführen, manchmal müssen Sie in der Anwendungssituation an mehreren Dingen gleichzeitig arbeiten. Nehmen wir zum Beispiel an, dass Sie mit der Arbeit an Feature F begonnen haben und einige Änderungen in Bezug auf F1 in Ihrem Arbeitsverzeichnis vorgenommen haben. Und dann musst du jemandem eine E-Mail schreiben. Und basierend auf der Antwort möchten Sie mit Feature eins fortfahren. Während du auf die Antwort wartest. Es wird nicht erwartet, dass du YouTube oder so etwas schaust. Ihr Chef würde erwarten, dass Sie eine weitere Aufgabe übernehmen. Vielleicht fangen Sie an, an Feature zu arbeiten , um zum Beispiel Feature zwei aufzunehmen und daran zu arbeiten. Führen Sie Code in Bezug auf Feature zwei ein. Und dann nehmen wir an , dass Sie auch für die Funktion von jemand anderem abhängig sind . Und du musst auf die Antwort warten. Sie greifen also auch Feature drei auf. Während Sie all diese Funktionen verwalten, warten Sie auf Antworten und aktualisieren Sie den Code entsprechend. Ihr Chef würde Sie bitten, ein Update zur Funktion für Sie zu senden . Wir werden Ihnen sagen, dass es in Bearbeitung ist , obwohl Sie noch nicht mit der Funktion begonnen haben, nur um sie bei Laune zu halten, Sie könnten ihm sagen, dass es in Bearbeitung ist. Sie sind also gezwungen, vorerst mit der Arbeit an einem Feature zu beginnen . Und dann kannst du plötzlich für Feature eins antworten. Oder jemand in Ihrem Team bittet Sie, Feature 3 zu liefern , weil er von ihnen abhängig ist. Ich hoffe du kommst dahin, wohin das führt. Wenn Sie all diese teilweisen Änderungen an allen Funktionen in Ihrem Projekt vorgenommen haben . Dies würde zu viel Chaos und viel Frustration führen . Lassen Sie uns über ein weiteres realistisches Problem sprechen , mit dem Sie möglicherweise konfrontiert werden, wenn Sie keine Zweige verwenden. Stellen Sie sich vor, Sie haben ein zentralisiertes Repository, in dem alle Teammitglieder zur Codebasis beitragen würden . Und da kommt diese neue Dame , die gerade dem Team beigetreten ist. Sie hatte keine Erfahrung im Programmieren. Sie hat gerade das College abgeschlossen und ist der Organisation beigetreten. Und ihr wurde ein Feature zugewiesen, an dem sie arbeiten konnte. Während sie an dem Feature arbeitet, hatte sie das Gefühl, dass es zu viele Änderungen gibt, um wiederzukommen. Also dachte sie darüber nach, sich teilweise auf die Codebasis zu verpflichten. Also begeht sie diese Änderungen. Und natürlich ist dies, wie Sie erwarten können , keine ideale Sache. Aber sie ist neu im Team. Sie weiß nicht viele Dinge. Sie lernt immer noch und hat sich teilweise verpflichtet. Und der Rest der Teammitglieder würde anfangen , diese neuen Änderungen vorzunehmen, weil sie den neuesten Code benötigen , um zusätzlich zum vorhandenen Code an ihren eigenen Funktionen zu arbeiten . Und sie tragen zum Projekt bei, führen ihre eigenen Änderungen ein und führen neue Funktionen oder Fehlerbehebungen ein. Aufgrund dieses teilweisen Commits, das diese junge Dame gemacht hat, könnten auch alle zukünftigen Commits tatsächlich brechen. Oder noch schlimmer, es könnte die Dinge tatsächlich reifen lassen und früher gut funktionieren. Jetzt ist es verständlich , dass sie neu im Team ist und zwangsläufig Fehler machen wird, aber alle hochrangigen Mitglieder im Team beherbergt hat, die faire Arbeit geleistet haben. Dennoch müssen sie die Schuld auf sich nehmen , da ihr Code aufgrund der von dieser jungen Dame eingeführten Änderungen nicht wie erwartet funktioniert . Dies ist nur eine Folge eines Fehlers, den ein Teammitglied begangen hat. Wie wäre es, wenn mehrere Teammitglieder all diese halb gekochten Ideen in die Haupt-Codebasis einbringen würden. Es wird bald ein Albtraum werden. Es wird bald schwierig werden, die Projektfristen nicht einhalten zu können, zu viele Probleme zu beheben usw. Also ich denke, ich muss jetzt etwas über Git Branches lernen. Absolut. Worauf wartest du dann? Jeder trifft diese Sachen beschädigt. Okay. Einfacher Zylinder. Das ist der Plan. Deshalb bin ich hier. Ich bin hier, um es dir beizubringen. Danke. Danke. Du bist willkommen. 24. 0302 Was sind Git Branches: Okay, lassen Sie uns versuchen, eine Vorstellung davon zu bekommen , was unsere Git-Zweige sind. Jetzt muss ich erwähnen , dass Sie mit diesem Video allein möglicherweise nicht in der Lage sind, ein vollständiges Bild davon zu verstehen oder sich ein vollständiges Bild davon zu machen, was Git-Branches sind. Sie müssen sich den Rest der Vorlesungen in diesem Kapitel ansehen , um ein vollständiges Bild davon zu erhalten, was unsere Git-Branchen sind, was der Zweck ist, warum sie existierten und wie sie alle Probleme lösen wir hatten vorhin geredet. Also lasst uns weitermachen und versuchen als Mitarbeiter zu bekommen, was ich Filialen bekomme. Git-Zweige sind ein so wichtiges Merkmal in Git, dass sogar das Logo selbst ein Symbol hat , das get-Zweige darstellt. So können Sie die Bedeutung dieser Funktion in Git verstehen . Jetzt möchte ich dir eine Frage stellen. Was fällt Ihnen als Erstes ein, wenn Sie das Wort Zweig hören? Würdest du dir so etwas vorstellen? Nun, du liegst nicht falsch. Hier. Wenn Sie beobachten, haben wir einen Hauptzweig und dann auch Unterzweige, die vom Hauptzweig kommen. Und jeder dieser Zweige hat seine eigenen Blätter. Nun, das ist auch gleichbedeutend Zweigen, die man bekommt. Also n get, Sie haben möglicherweise einen Master-Branch, der von get erstellt wurde , wenn Sie das Projekt initialisieren und Ihr erstes Commit durchführen. Wir müssen dieses Tor nicht manuell erstellen, hat das für uns getan. Und alle Kommentare , die wir bisher gemacht haben , gingen in diesen Standard-Zweig, Master-Zweig, obwohl wir uns dessen nicht bewusst sind. Und dann könnten wir auch Feature-Branches haben , die aus dem Master-Branch stammen. So wie wir Haupt- und Unterzweige in einer realen Branche haben , haben wir auch Master Branch und Feature Branches in gutem Zustand. Und so wie jeder der Zweige seine eigenen Blätter haben würde, haben wir auch in Git Konvekte , die sich in jedem dieser Zweige befinden. Und all diese Zweige würden sich unabhängig voneinander entwickeln. Wenn Sie beispielsweise ein Commit durchführen und einen Branch verwenden, sind diese Änderungen in keinem der anderen Zweige verfügbar. Genauso wie bei anderen Branchen. Wenn Sie einen Kommentar erstellen und einen Master-Branch erstellen, diese Änderungen in anderen Branches nicht verfügbar. Wenn du in einem bestimmten Branch ein Commit machen willst, musst du zu diesem Branch wechseln und in diesem Branch ein Commit machen. Und diese festgeschriebenen Änderungen werden in anderen Zweigen nicht verfügbar sein. Und wenn du zu einem Branch wechselst, lässt Git das Arbeitsverzeichnis so aussehen, wie es aussah , als du das letzte Commit in diesem bestimmten Branch gemacht hast . Schließlich wäre das Ziel all dieser Feature-Zweige in den meisten Fällen, im Master-Branch zusammengeführt zu werden. Das bedeutet, dass wir jetzt alle Änderungen, die in diesen Feature-Zweigen eingeführt wurden, innerhalb des Master-Zweigs haben werden. Offensichtlich ergibt dies für Sie zu diesem Zeitpunkt möglicherweise keinen vollständigen Sinn . Lassen Sie uns das zusammenfassen und sehen, wie dieses Projekt von Anfang an entwickelt haben könnte. Wenn Sie also zunächst das Projekt und Ihr erstes Commit machen, haben Sie einen Master-Branch, der von good erstellt wurde. Nehmen wir an, Sie haben ein paar Kommentare abgegeben. Diese Kommentare würden in den Master-Zweig gehen. Wir haben also den ersten Commit , der kein Elternteil hat. Und dann haben Sie den zweiten Commit , der den ersten Commit als übergeordnetem Commit hat. Und jetzt nehmen wir an, Sie sind beauftragt, an Feature eins zu arbeiten. Anstatt all diese Funktionen zu Änderungen innerhalb des Master-Branches vorgenommen. Sie werden lediglich einen Befehl ausführen, um einen Feature-Branch zu erstellen. Und das würde nur den Feature-Branch erstellen. Und sobald Sie das getan haben, müssen Sie zu diesem Branch wechseln , um in diesem Feature-Branch Commits vornehmen zu können . Sie würden also einen Befehl ausführen , um zu diesem Zweig zu wechseln. Und sobald Sie das getan haben, werden Sie anfangen, alle Funktionen einzuführen , die man ändert. Wenn Sie den ersten Kommentar abgeben. Wir haben ein Kommentar-Objekt , dessen Eltern das letzte Commit des Branches sein würden das letzte Commit des Branches von dem aus Sie diesen Branch erstellt haben. In diesem Fall ist es der Master-Branch. Der erste Kommentar , den Sie innerhalb des Feature-Eins-Zweigs abgegeben haben, würde jetzt auf das letzte Commit des Master-Branches verweisen. Nehmen wir an, Sie haben im Feature-Branch einige Kommentare abgegeben. Keine der Änderungen, die wir in Feature One Branch eingeführt haben , wäre im Master-Branch verfügbar. Denn wie ich bereits erwähnt habe, würden sich all diese Zweige unabhängig voneinander entwickeln . Nehmen wir nun an, Sie haben sich entschieden, an etwas anderem zu arbeiten, und Sie wollten all diese Änderungen innerhalb des Master-Branches beitragen . Sie würden also wieder zum Master-Branch wechseln und einen Kommentar abgeben. Beachten Sie, dass diese beiden Commits oder das exakt gleiche Elternteil haben und was auch immer die Änderungen, die Sie mit diesem neuen Commit innerhalb des Master-Zweigs eingeführt haben mit diesem neuen Commit innerhalb , nicht sein werden verfügbar innerhalb des Feature-Zweigs. Feature One Branch würde nur alle Änderungen enthalten, die im Master-Branch eingeführt wurden, bis Sie das Feature auf dem Branch erstellt und das erste Commit durchgeführt haben alle Änderungen enthalten, die im Master-Branch eingeführt wurden, bis Sie das . Plus all die Änderungen, die Sie in Feature eins eingeführt haben. Okay, nehmen wir an , Sie haben noch einen Kommentar innerhalb des Master-Branches abgegeben. diesem Zeitpunkt aufgefordert, Angenommen, Sie werden zu diesem Zeitpunkt aufgefordert, an einer Funktion zu arbeiten, um zu erraten, was Sie noch einen weiteren Zweig erstellen werden, nennen wir es Feature zu Verzweigung. Und dann musst du zu diesem Branch wechseln, um Commits innerhalb der Funktion zum Branch machen zu können, du wirst einen Commit machen. Und dieses Mal wäre es in Feature zu Branch gefangen . Und dieses Commit-Objekt würde auf den letzten Commit im Master-Branch zeigen, da es der Master-Branch ist von dem aus wir diese Funktion für die Verzweigung erstellt haben. Und alle nachfolgenden Commits, die Sie vornehmen werden, werden von Feature zu Branch verfolgt. Nun, vielleicht möchten Sie wieder zum Master-Branch zurückkehren Reihe von Kommentaren machen, und nicht die Dimensionsfunktion, um zu verzweigen werden Änderungen vorgenommen, die Sie in Master Branch bis eingeführt haben die Zeit, zu der Sie Feature zum Verzweigen erstellt und das erste Commit durchgeführt haben Und alle Kommentare, die Sie in Branch eingeführt haben , enthalten jedoch keine der Änderungen, die Sie in einem der anderen Zweige vorgenommen haben . Zeigen Sie zum Beispiel einen Zweig an. Schließlich möchten Sie alle Änderungen , die Sie in diesen Feature-Zweigen vorgenommen haben, in den Master-Branch zusammenführen diesen Feature-Zweigen vorgenommen haben, in , sodass Sie alle Änderungen innerhalb des Master-Branches haben . Nun haben Sie offensichtlich viele Fragen, wie dies all die Probleme lösen würde , über die wir zuvor gesprochen hatten. Und was genau ist eine Filiale? Wie funktioniert das intern? Und wie wird es geschafft, was es bedeutet wenn Sie in einen anderen Zweig wechseln, Sie, und in den nächsten Vorlesungen Antworten auf all diese Fragen zu finden . Und übrigens habe ich erwähnt, dass wir innerhalb des Master-Branches Commits machen . Normalerweise neigen wir nicht dazu, Commits direkt im master-Branch zu machen . Wir erstellen immer einen neuen Branch, Beta-Funktion oder einen Bugfix. Und wenn wir uns über alle Änderungen sicher sind, sobald wir sie getestet haben, lassen wir sie überprüfen, erst dann werden wir all diese Änderungen innerhalb des Master-Zweigs zusammenführen. Was der Master-Branch im Wesentlichen hätte , ist ein sogenanntes Merge-Commit. Werde in den kommenden Vorlesungen über Merge-Commits sprechen. Ich möchte jetzt nicht darüber sprechen und dich weiter verwirren. Wir sehen uns im nächsten. 25. 0303 Wie Branches unsere Probleme gelöst haben: Okay, bisher haben wir eine Vorstellung von Filialen. Schauen wir uns nun an, wie Branchen die Probleme lösen, über die wir zuvor gesprochen hatten. Lassen Sie uns eins nach dem anderen über sie sprechen. Stellen Sie sich vor, Sie werden aufgefordert, an mehreren Funktionen gleichzeitig zu arbeiten . Dieses Mal werden Sie mehrere Zweige haben, von denen jeder einer einzelnen Funktion entspricht. Multitasking ist für Sie sehr einfach , weil Sie beispielsweise an Feature One arbeiten wollten. Du wechselst einfach zu diesem Zweig und arbeitest weiter an Feature eins. Irgendwo in der Mitte Ihrer Arbeit haben Sie sich vielleicht entschieden, an einer anderen Funktion zu arbeiten, beispielsweise an einer Funktion, vielleicht weil Sie auf eine E-Mail-Antwort warten oder was auch immer. Also ratet mal was? Er wechselte zu einem Feature Branch und arbeitete weiter an Feature zwei. Und da in einem Zweig eingeführte Fellwechsel keine Auswirkungen auf die anderen Zweige haben . Es besteht keine Chance, dass Sie sich mit Codeänderungen verwechseln , die für mehrere Funktionen eingeführt wurden. Wir haben separate Kontexte für jedes einzelne Feature. Und sie entwickeln sich unabhängig voneinander. Branches hat also das Problem gelöst, dass sie nicht in der Lage sind, mehrere Funktionen zu multitasken. Nehmen wir nun an, dass ein unerfahrener Programmierer dem Team beigetreten ist. Ratet mal was? Sie können einfach einen Zweig erstellen, experimentieren. Alles, was sie experimentieren wollten, Fehler machen, aus diesen Fehlern lernen und Updates bringen wollten. Endlich, wenn sie mit den Änderungen fertig sind. Und sobald nach dem Test all diese Änderungen vorgenommen wurden, können die leitenden Mitglieder des Teams tatsächlich alle Codeänderungen überprüfen. Und nur dann werden sie akzeptieren all diese Änderungen mit dem Mainstream der Entwicklung verschmolzen werden . Es gibt also keinen Spielraum, in dem ein Mitglied im Team mit dem Code herumspielt und auch die Arbeit anderer kostet. Nehmen wir an, Sie wollten eine der Funktionen loswerden , dann müssen Sie nicht alle Änderungen rückgängig machen und riskieren, Probleme zu verursachen. Oder du musst nicht zu einem der vorherigen Commits zurückkehren und riskierst, die gesamte Anstrengung des Teams zu verlieren, die danach entstanden sind. Stattdessen können Sie den Zweig einfach löschen und schon können Sie ihn aufrufen. Die Funktion, die Sie nicht möchten. Es wird keinerlei Auswirkungen oder Einfluss auf die Arbeit anderer haben. Ein weiterer Vorteil bei Branches ist, dass du teilweise Commits machen kannst. Ohne Zweige, die wir teilweise Commits vorgenommen haben, könnten Sie das Risiko eingehen, dass neue Fehler in Ihrer Anwendung einige der Arbeitsfunktionen beeinträchtigen. Mit Branches können Sie jedoch mehrere partielle Commits vornehmen, insbesondere wenn Ihr Feature sehr groß ist. Und wenn Sie fertig sind, werden Sie einfach all diese Änderungen auf dem Master-Branch zusammenführen . Hoffe es macht Sinn. 26. 0304 Wie Git Branches funktionieren und was genau ist ein Branch: Okay, versuchen wir zu verstehen, wie Zweige funktionieren würden. Aber lassen Sie uns vorher verstehen, was genau eine Branche ist. Wenn ich einen Branch definieren würde, wäre ein Branch einfach eine Referenz auf einen Commit, oder mit anderen Worten, er ist nur ein Zeiger auf ein bestimmtes Commit. Jetzt fragen Sie sich vielleicht, warum etwas so Einfaches wie dieses so viel für uns tun kann? Das tut es. Lass mich dir erklären, was ich meine. Lass uns das einrichten. Initialisieren Sie das Projekt einfach mit dem Befehl git init. Und da branch eine Referenz auf ein bestimmtes Commit ist, benötigen wir mindestens einen Commit, um einen Branch zu haben. Und deshalb siehst du gerade nichts. Ein Branch würde erstellt werden wenn wir das erste Mal einen Commit machen. Und dieser Zweig ist der Master-Zweig , der von Git selbst erstellt würde. Das müssen wir nicht manuell machen. Sie können sich das einfach als eine Datei mit dem Namen Master vorstellen , deren Inhalt der HashCode eines bestimmten Commits sein wird . Und ein Branch zeigt immer auf den letzten Commit in diesem Branch. Derzeit haben wir nur einen einzigen Commit. Dieser Master-Branch würde auf dieses Commit verweisen. Nehmen wir an, ich habe ein neues Commit gemacht, dann würde der Zweig jetzt auf dieses neue Commit zeigen, so weiter und so fort. Und mach ein neues Commit und Branch würde auf dieses neue Commit zeigen. Nehmen wir an, ich muss auf Feature eins gehen. Wir führen einen Befehl aus, um einen weiteren Branch zu erstellen. Nennen wir es Feature One Branch. In dem Moment, in dem Sie diesen Befehl ausführen, erstellt Git einen neuen Zweig, im Wesentlichen eine neue Datei mit dem Namen feature one, deren Inhalt der hashCode eines bestimmten Commits sein würde. Was wäre es? Kannst du raten? Nun, es wäre das letzte Commit aus dem Branch von dem aus wir Feature One Branch erstellt haben. Es würde also auf dieses Commit hinweisen. Nehmen wir an, ich habe noch ein paar Commits gemacht. Was denkst du, würden diese Kommentare in Mel fließen? Es würde in den Master gehen , weil dies der derzeit aktive Zweig ist. Diese beiden Kommentare würden also in den Master-Zweig gehen. Und wie Sie sich vorstellen können, würde der Master jetzt auf das jüngste Commit in diesem bestimmten Zweig hinweisen . Nehmen wir nun an, Sie wollten innerhalb des Feature-Branches einige Kommentare abgeben . Nun, du musst einen Befehl ausführen , um zu diesem Zweig zu wechseln. Und sobald Sie das getan haben, werden alle Commits, die Sie machen werden, innerhalb des Feature-Eins-Zweigs verfolgt. Wenn ich jetzt einen Commit mache, wie würde das Diagramm Ihrer Meinung nach aussehen? Nun, ein Zweig würde immer auf den letzten Kommentar zu diesem Zweig verweisen . Merkmal. Ein Branch würde jetzt auf dieses neue Commit verweisen. Und dieses neue Commit wird das Master Branch Commit als übergeordnetes Element haben . Zu diesem Zeitpunkt werden wir also zwei Commits haben , die genau dasselbe Elternteil haben. Nehmen wir an, ich habe noch ein paar Kommentare abgegeben. Wo würden diese Kommentare Ihrer Meinung nach verfolgt werden? Nun, da Feature One Branch der aktuelle Actor Branch ist, würden diese Kommentare innerhalb des Feature-Eins-Zweigs erscheinen. Und natürlich würde Feature One Branch jetzt den letzten Commit auf diesem Branch verweisen. Nun, meine Frage an Sie: Stellen Sie sich vor, ich habe in jedem dieser Kommentare eine Datei hinzugefügt . Wenn ich mir das Arbeitsverzeichnis ansehen würde, welche Dateien werden Sie sehen? Kannst du raten? Nun, jedes Mal, wenn du zu einem Branch wechselst, schreibt Git das Arbeitsverzeichnis um, wie es aussah , als du das letzte Commit auf dem Branch gemacht hast, zu dem du gerade gewechselt hast. In diesem Fall verfügen die aktuellen Akteurzweige über eine Charge. Sie werden also all diese Dateien A, B, C und F, G, H sehen B, C und F, G, . Sie werden die Dateien D und E nicht sehen. Und wenn Sie jetzt zum Master Branch wechseln, werden Sie A-, B-, C-, D-, E-Dateien sehen , aber nicht F, G, H Files. Hoffe es macht Sinn. Wir sehen uns in der nächsten. 27. 0305 Filialen in Aktion (Verzweige erstellen und das Git Repo): Okay, lassen Sie uns Zweige mit einem kurzen Beispiel in Aktion sehen. Ich werde noch einmal einen neuen Ordner erstellen, meine App, und hier werden wir alles über Zweige experimentieren. Ich werde Git Bash hier starten. Lassen Sie mich eine Datei erstellen, die im Master-Branch festgeschrieben wurde. Und wir werden von dort aus beginnen. Ich werde das Projekt initialisieren lassen. Berühren Sie dann einen Punkt TXT, um diese Datei zu erstellen. Git füge einen Punkt TXT hinzu , um als diese Datei zu bleiben. Und bevor ich die Änderungen festlege, lass mich dich zu refs, heads-Verzeichnis bringen. Dies ist, wo es oft Verzweigungen erstellen würde. Lass mich zurück zu Git Bash gehen und lass mich diese Änderung kommentieren. Git commit Bindestrich m. Erstes Commit im Master-Branch. In dem Moment, in dem ich diese Änderungen festnehme, werden Sie sehen, dass eine neue Datei von gaped erstellt wird. Schauen wir uns an, was in dieser Datei enthalten ist. Namen der Datei zur Kenntnis zu nehmen ist der Name des Zweigs, der Standardzweig, den Gott für uns geschaffen hat. Es ist der Meister. Und der hashCode ist der hashCode des Commits, den wir gerade gemacht haben. Wenn ich zu Git Bash zurückkehre und git log, ist der HashCode, den Sie hier sehen genau der HashCode, den Sie in der Masterdatei sehen. Im Wesentlichen zeigt der Zweigmeister im Moment auf diesen speziellen Kometen. Lassen Sie uns noch einen Kommentar abgeben und sehen, was passieren wird. Berühren Sie die Zwei-Punkt-TXT-Datei, git, fügen Sie zwei Punkte TXT hinzu. Und dann noch einmal, lassen Sie uns die Änderung begehen. Nennen wir es Second Commit und Master Branch. Und schauen wir uns den Inhalt in der Masterdatei an . Also cat dot bekommt refs heads und dann den Dateimaster. Und wie Sie sehen können, zeigt der Master jetzt auf den letzten Commit in diesem aktuellen Zweig. Wenn ich also git log, wirst du sehen, dass der Master-Zweig tatsächlich auf den letzten Commit verweist , den wir gemacht haben. Versuchen wir nun, einen neuen Branch zu erstellen. Und der Befehl dafür ist git branch. Und dann geben Sie den Namen des Zweigs an, den Sie erstellen möchten. Nennen wir es Feature Eins. Das hat also Feature-Eins-Zweig erstellt, aber wir befinden uns immer noch im Master-Branch. Und du kannst es erkennen, indem du hier nachschaust, es heißt Meister, also sind wir derzeit im Master Branch. Wenn ich jetzt ein Commit mache , wird es nicht verfügbar sein. Kennzeichnen Sie einen Zweig. Aber wenn Sie bemerken, hat es auch eine weitere Datei im heads-Verzeichnis mit dem Namen feature one erstellt heads-Verzeichnis mit dem Namen feature und den Inhalt darin abgerufen. Nun, es wird der HashCode des letzten Commit-Off-Zweigs sein, von dem aus wir Feature One Branch erstellt haben. Wenn Sie sich also den Inhalt der Feature-Eins-Datei ansehen, wird dies im Wesentlichen der Feature-Eins-Datei ansehen, auf den letzten Commit des Master-Branches verweisen . Wie erwartet. Wenn ich jetzt ein neues Commit mache, in das Sie denken, dass die Änderungen vorgenommen werden, wäre es innerhalb des Master-Branches , weil das der aktuelle Act zum Verzweigen ist. Lassen Sie mich also eine Verpflichtung eingehen. Niederländischer Drei-Punkt-dxdy, git füge drei Punkte hinzu dxdy. Und wir werden ein drittes Commit innerhalb des Master Branch machen . Wenn ich das tue, werden Sie all diese drei Akten sehen. Aber wenn ich zu Feature One Branch wechsle, erhalte ich switch und den Namen des Zweigs, zu dem ich wechseln möchte. Feature eins. Sie können auch den Befehl git checkout und den Namen des Zweigs head away verwenden. Wie Sie sehen können, haben wir auf einen Zweig umgestellt. Sie können es auch erkennen, indem Sie hier nachschauen. Können Sie sich vorstellen, was all die Akten sehen werden, wenn ich das mache? Nun, wir sollten nur einen Punkt dx dy und dx dy sehen können . Und dxdy wurde nicht freigegeben , weil Drei-Punkt-Text erstellt und Master-Zweig erstellt wird, nachdem wir diesen Feature-Branch erstellt haben. Wie Sie sehen können, sehen wir nur einen Punkt d x in Rho-TXT-Dateien, was erwartet wird. Jetzt, da wir uns innerhalb des Feature-Eins-Zweigs befinden, alle Kommentare, die ich jetzt machen werde, in Feature One Branch gefangen . Lass uns einen Kommentar abgeben. Ich möchte eine Datei erstellen, tippen Sie auf. Nennen wir es, das sind 13-Punkt-TXT-Dateinamen wie diese, nur damit wir wissen, dass dies zu Feature One Branch gehört . Vorerst. Git hinzufügen. Wir bleiben als diese Datei, git commit m, und fügen Feature 13-Datei hinzu, fügen Feature 13-Datei hinzu in der ein Zweig, was auch immer. Also haben wir den Kommentar gemacht, wenn ich das jetzt mache, willst du all diese Dateien sehen. Lass mich zurückgehen. Das Arbeitsverzeichnis. Du wirst dir all diese Akten ansehen. Schauen wir uns an, was passieren würde, wenn ich zu Master Branch wechseln würde. Also benutze ich bekommt welchen Befehl. Oder ich könnte auch git checkout verwenden und dann den Namen der Filiale. In dem Moment, in dem ich das mache, können Sie sehen, dass das Arbeitsverzeichnis aktualisiert wurde , das zu Master Branch passt Machen Sie sich also der Momentaufnahme des neuesten Commit-Diamanten-Master-Zweigs bewusst . Und es wird das Arbeitsverzeichnis so aussehen lassen , wie es aussah , als wir das letzte Commit im Master-Branch gemacht haben. Und wenn ich wieder zum Feature-Branch wechseln würde, werden Sie erneut sehen, dass das Arbeitsverzeichnis entsprechend aktualisiert wird. Wir sehen keine drei Punkte, Ddy. Und Feature-Branch würde jetzt auf den letzten Commit verweisen , der in diesem Branch durchgeführt wurde. Wenn Sie sich also den Inhalt von Feature One Branch ansehen, wird der HashCode jetzt aktualisiert verweist auf den letzten Commit in einem zukünftigen Zweig. Wenn Sie git log machen, würden Sie sehen, dass dies das letzte Commit ist, das in diesem Zweig durchgeführt wurde. Jetzt ist es wirklich wichtig, dass Sie verstehen, wie genau das funktioniert. Ich möchte, dass du damit experimentierst. Erstellen Sie Dateien auf mehreren Branches, wechseln Sie zwischen mehreren Branches und versuchen Sie zu verstehen, wie gut sich Branches verhalten. Wenn du nicht übst, ist es fast sicher , dass du dich bald verwirren wirst . Also zögere nicht zu üben. Sie haben das Gefühl, alles zu wissen, aber wenn Sie tatsächlich üben, Sie vielleicht Überraschungen erleben. Also zögern Sie nicht, damit zu experimentieren. Nehmen Sie sich etwas Zeit und üben Sie, was ich gerade gelehrt habe , und stellen Sie sicher , dass Sie mit Zweigen vertraut sind. 28. 0306 Verstehen von 'HEAD' freistehender Head State Head in Aktion: Lassen Sie uns verstehen, was vor uns liegt und erhalten Sie. Mein Branch ist eine Referenz auf einen Commit, head-bezogen auf einen Branch oder auf einen bestimmten Commit. Wenn der Head auf einen bestimmten Commit zeigt, wird er als losgelöster Kopfzustand bezeichnet. Lass mich dir erklären, was ich meine. Wenn Sie ein Projekt ohne andere Zweige außer dem Master-Branch haben , head standardmäßig auf den Master-Branch. Nehmen wir nun an, dass Sie zwei Zweige haben, Master und Feature One Branch. Angenommen, Sie haben auf Feature One Branch umgestellt. Der Kopf würde jetzt auf einen Zweig zeigen. Und basierend auf dem Kopf erfahren Sie, in welchem Zweig die Änderungen vorgenommen werden müssen. Wenn der Kopf auf den Master-Branch zeigt, wird Git die Kommentare innerhalb des Master-Zweigs abgeben, oder der Kopf zeigt auf anderen Branch wie Feature One Branch. Git wird Commits innerhalb des Feature-Eins-Zweigs machen. Sie können den Kopf auch auf ein bestimmtes Commit zeigen lassen. Und wir hatten uns bereits in einer unserer vorherigen Vorlesungen ein Beispiel dafür angesehen. Sie könnten zum Beispiel git checkout oder good switch sagen. Und dann geben Sie den HashCode eines bestimmten Commits für Objekte an. Der Head würde dann auf diesen bestimmten Commit zeigen und get wird das Projekt-Arbeitsverzeichnis so aktualisieren , dass es so aussieht , als ob Sie diesen bestimmten Commit gemacht haben. Und was sind die Kommentare, die Sie während des abgetrennten Kopfzustands machen ? All diese Kommentare gehen verloren, wenn Sie zu einem der Zweige zurückkehren. Sie fragen sich vielleicht, warum wir zur Kasse gehen oder zu einem bestimmten Commit wechseln können. Nun, es kann Anwendungsfälle geben, in denen Sie zum vorherigen Status des Projekts zurückkehren möchten . wir zum Beispiel an, Nehmen wir zum Beispiel an, Sie möchten einen Blick darauf werfen, wie unser Projekt aussieht, als Sie ein bestimmtes Commit gemacht haben. Nehmen wir an, Sie möchten einige der Änderungen abrufen , die wurden zuvor in einem der vorherigen Kommentare gelöscht. Nun, Sie können sich den jeweiligen Commit ansehen. Sie schauen sich alle Änderungen an, kopieren vielleicht den Code , der gelöscht wurde, und verwenden diesen Code in Ihrem aktuellen Projekt. Sobald Sie zurück zum Branch gewechselt sind oder ein anderer Anwendungsfall des distanzierten Kopfzustands wäre, wir an, Sie möchten in die Vergangenheit zurückgehen und einige experimentelle Commits machen. Sie möchten jedoch nicht, dass all diese Commits in Ihrer Codebasis verfügbar sind. Und wenn Sie fertig sind, würden Sie einfach zu einem der Zweige zurückkehren und all diese experimentellen Commits würden verloren gehen. Schauen wir uns das alles in Aktion an. Okay, wir befinden uns derzeit im Feature-Eins-Zweig. Lassen Sie uns zunächst versuchen herauszufinden, wo der Kopf tatsächlich befindet. Im Git-Ordner. Du wirst diese Datei mit dem Namen head finden. Da wir uns jetzt in Feature One Branch befinden, zeigt head auf Feature One Branch. Mal sehen, was passieren wird. Wenn wir zum Master Branch wechseln. Werfen wir einen Blick auf den Inhalt der Kopfdatei dot get. Und wie Sie sehen können, zeigt head jetzt auf Master Branch. Schauen wir uns nun die Liste der Commits in diesem Master-Zweig an , git log. Und wie du siehst, haben wir derzeit drei Commits. Und Sie können hier auch sehen , dass der Kopf auf den Master-Branch zeigt. Wenn Sie zu Feature One Branch wechseln würden, sagen wir mal. Und logge zum Beispiel git. Sie werden sehen, dass der Kopf auf einen Zweig zeigt. Wenn Sie einen Blick auf die gesamte Liste der verfügbaren Zweige werfen möchten , heißt es git branch. Und dann siehst du die ganze Liste der Zweige. Und da der aktuelle Zweig oder der ACT to Branch oder der sogenannte Head Branch ein Feature-Eins-Zweig ist, wird er grün hervorgehoben. Wir sehen auch ein Sternzeichen, das uns einen Hinweis darauf gibt , dass dies der tatsächliche Zweig oder der aktuelle Zweig ist . Also wenn ich git log, kannst du sehen, dass wir derzeit drei Commits haben. Wir haben uns bereits angeschaut, wie wir einen einer unserer vorherigen Vorträge lesen oder zu ihm wechseln können vorherigen Kommentare in einer unserer vorherigen Vorträge lesen oder zu ihm wechseln können. Also werde ich das nicht tun. Ich würde stattdessen einen anderen Befehl namens Git checkout verwenden . Oder du könntest auch einen guten Schalter benutzen. Verwenden wir das, weil es das neueste ist. Und dann sagst du Kopf in Großbuchstaben. Und dann wirst du dieses Symbol benutzen, was auch immer es ist. Und dann geben Sie die Anzahl der Commits an, zu denen Sie zurückkehren möchten. Sagen wir, wenn ich hier eins sage, dann können wir das Depository oder das Arbeitsverzeichnis sehen, wie es vor einem Commit aussah. Lassen Sie mich diesen Befehl ausführen. Und dieses Mal, wenn ich git log, okay, dieser Befehl hat im Grunde nicht funktioniert. Es fordert uns auf, diese Option detach hinzuzufügen. Also lass uns das schnell machen. Jetzt lass uns Git Log machen. Und du wirst nur ein paar Kommentare sehen. Derzeit befinden wir uns im Zustand des abgetrennten Kopfes. Lassen Sie mich versuchen, hier einen Kommentar abzugeben. Berühren Sie vielleicht Apple dot dx, dy. Und dann git, füge Apple Dot TXT hinzu. Komm her, binde sie. Eine Nachricht. Es ist egal. Wenn ich git log. Sie würden sicherlich sehen, dass sich das verpflichtet. Aber sobald ich zu einem der Zweige zurückwechsle, würden Sie dieses Commit nicht mehr sehen. Dieses Commit wäre verloren. Also mache ich den Git Checkout. Oder Sie könnten auch sagen, Good Switch Feature One, Git Log. Und Sie würden den Kommentar, den wir gerade abgegeben haben , nicht mehr sehen . 29. 0307 Entleere die Änderungen mit Git HEAD zurücksetzen: Okay, lassen Sie uns sehen, wie wir unsere Änderungen rückgängig machen können , indem wir die Kommentare, die wir gemacht haben, rückgängig machen. Um Ihnen Zeit zu sparen. Ich habe tatsächlich einen brandneuen Ordner oder ein brandneues Projekt erstellt . Und wir haben im Grunde diese drei Dateien. Jede dieser Dateien wurde in ihren eigenen Kommentaren festgeschrieben. Wenn ich zum Beispiel git log, siehst du, dass wir drei Commits haben. Im ersten Kommentar habe ich eine Punkt-TXT-Datei festgeschrieben. Im zweiten Kommentar habe ich mich zur Punkt-TXT-Datei verpflichtet und Commit eingegeben. Wir haben eine Drei-Punkt-TXT-Datei festgeschrieben. Dies dient nur dazu, Zeit zu sparen. Wir erstellen Projekte und erstellen Dateien und fügen sie dem Staging-Bereich hinzu und übernehmen diese Änderungen seit Dateien und fügen sie dem Staging-Bereich hinzu einiger Zeit. Ich hoffe, dass ich dir das nicht immer wieder durchgehen muss . Wir haben derzeit keine anderen Filialen. Wir haben den standardmäßigen Master-Branch. Schauen wir uns an, wie wir auch unsere Undo-Commits ändern können . Und wir werden auch über ein paar weitere Kommentare sprechen ein paar weitere Kommentare über die ich jetzt sprechen möchte. Nehmen wir an, ich habe diese Änderungen versehentlich übernommen und wollte diese Änderungen rückgängig machen. Jetzt gibt es drei Möglichkeiten für mich. Ich kann dieses Commit einfach rückgängig machen, aber die Dateien im Arbeitsverzeichnis behalten . Das ist Option eins. Option zwei ist, dass ich dieses Commit rückgängig machen kann, die Änderungen im Arbeitsverzeichnis beibehalten und diese Dateien auch bereitstellen lassen kann. Und dann die dritte Option, ich mache dieses Commit rückgängig lösche alle Änderungen, die in diesem Kommentar vorgenommen wurden. Lassen Sie mich also all diese Szenarien demonstrieren. Und der Befehl dafür ist git reset. Und ich sage „Kopf“. Was ist das Symbol? Ich weiß nicht, was das Symbol ist. Ich schätze es heißt Tilda. Wenn ich mich nicht irre, hoffe ich, dass ich recht habe. Und dann gebe ich hier eine Nummer an. Wenn ich hier zwei spezifiziere, möchte ich Kommentare rückgängig machen. Versuchen wir es mit einem Commit. Ich habe Enter gedrückt. Was das getan hat, ist, dass das letzte Commit rückgängig gemacht wurde. Aber wir haben die Dateien immer noch im Arbeitsverzeichnis, aber nicht im Staging-Bereich. Also wenn ich jetzt git log, wirst du nur das erste, zweite Commit sehen. Aber wenn ich das tue, wirst du eine Drei-Punkte-TXT-Datei sehen. Denn wie ich bereits erwähnt habe, haben wir immer noch die Änderungen im Arbeitsverzeichnis. Wenn ich jetzt den Git-Status mache, siehst du, dass diese Datei nicht bereitgestellt wird. So können wir alle Änderungen einführen , die wir einführen wollten. Nehmen Sie alle Updates vor. Sobald ich einige Änderungen in der Drei-Punkte-TXT-Datei vorgenommen habe , die ich jetzt übernehmen wollte. Also kann ich diese Änderungen aufrufen , sobald ich diese Änderungen vorgenommen habe, füge ich die Punkt-TXT-Datei erneut hinzu. Und dann wiederhole ich das das Commit-Git-Protokoll . Jetzt sehen Sie, dass wir all diese drei Kommentare haben. Nun wollen wir sehen, was passieren würde, wenn ich diesen Befehl mit der Soft-Option ausführen würde, dies für Lambda, diesen Kampf. Aber wir haben die Dateien immer noch sowohl im Arbeitsverzeichnis als auch im Staging-Bereich. Ich führe diesen Befehl aus. Git Protokoll. Du siehst nur zwei Commits. Und wenn du das tust, wirst du alle drei Dateien sehen. Wenn du den Git-Status verwendest, wirst du auch sehen, dass diese Änderungen inszeniert sind. Also kann ich diese Änderungen einfach übernehmen. Ich werde diesen Kommentar abgeben. Und das Leben ist wieder normal. Nehmen wir an, ich habe einen furchtbaren Fehler begangen. Und ich möchte nicht nur diese Änderungen rückgängig machen , die unter dem Commit stehen, sondern ich möchte auch alle Änderungen loswerden , die ich in diesem Kommentar vorgenommen habe. Nun, die Option dafür ist, dass Sie git reset head tilda verwenden müssen, Anzahl der Kommentare, zu denen Sie zurückkehren möchten. Und dann werden Sie die Option hart nutzen. Wenn du jetzt git log machst, würdest du offensichtlich zwei Commits sehen. Aber wenn du das jetzt tust, wirst du nur zwei Dateien sehen. Es ist, als hätte ich die dritte Bemerkung überhaupt nicht gemacht. 30. 0308 Das verlorene Geheimnis mit reflog wiederherstellen: Gehen wir nun davon aus, dass Sie Ihre Meinung geändert haben. Sie haben das Gefühl, das Comeback versehentlich rückgängig gemacht zu haben, und möchten all diese Änderungen abrufen. Dafür gibt es einen Weg. Zum Glück behalten wir diese Commit-Objekte und ihr Projektarchiv für einen guten Zeitraum bevor es beschließt , sie zu löschen. Wenn es die Garbage-Collection macht und alles. Schauen wir uns also an, ob wir all diese Änderungen abrufen können . Zuallererst müssen wir uns den HashCode des Commits besorgen . Diese Änderungen möchten abgerufen werden. Woher kennen wir die Commit-ID? Im Moment können wir einfach nach oben scrollen und die Commit-ID abrufen. Möglicherweise können Sie jedoch nicht jedes Mal nach oben scrollen. Wenn ich zum Beispiel dieses Fenster schließe und erneut öffne, ist es weg. Wie werden wir also von der Commit-ID abgezogen? Nun, get bietet einen Befehl an , der uns hilft, denn genau dieser Befehl ist log, unser Referenzprotokoll. Immer wenn wir unsere Freunde im lokalen Repository aktualisiert haben. Aber wenn Sie einen Befehl ausführen, haben Referenzprotokolle eine Aufzeichnung davon. Und Sie können all diese Datensätze sehen indem Sie diesen Befehl ausführen. Hier können Sie den HashCode dieses Commits abrufen. Nun könnte ich einfach git checkout hinzufügen und zu diesem Commit gehen. Und das würde uns in einen distanzierten Kopfzustand bringen. Sie können jedoch einfach all diese Änderungen kopieren, all diese Änderungen vornehmen und ein neues Commit vornehmen. Aber wir haben einen besseren Weg, damit umzugehen. Also anstatt Git Checkout und dann den HashCode dieses Commits anzugeben. Was wir tun werden, ist die Option Bindestrich b anzugeben, und ich gebe einen Namen an. Und dieser Name wird im Wesentlichen der Name des Zweigs sein , den wir gerade erstellen werden. Nehmen wir zum Beispiel new branch an. Übrigens würden wir für Zweignamen niemals Whitespaces verwenden. Wir würden stattdessen Bindestrich verwenden wollen. Was dieser Befehl also macht ist, wenn wir diese Option Bindestrich b haben, wird dies nicht nur diesen speziellen Zweig erstellen, sondern wir werden auch zu diesem Zweig wechseln. Und es wird auf diesen Kommentar hinweisen. Führen wir diesen Befehl aus. Und wie Sie sehen können, haben wir auf die neue Filiale umgestellt , die wir gerade erstellt haben. Und wenn ich jetzt git log, können Sie sehen, dass wir den dritten und die anderen beiden Kommentare tatsächlich aus dem Master-Branch stammen und den Branch eskalieren von dem aus wir diesen Branch erstellt haben. Aber wie bekommen wir den Commit Three Changes in unseren Master Branch? Nun, das können wir mit emerge machen. Wir haben nicht über Fusionen gesprochen. Wir werden in den kommenden Vorlesungen darüber sprechen. Aber vielleicht zeige ich es Ihnen schnell, nur um Ihnen ein Gefühl dafür zu geben, was eine Zusammenführung ist. Dafür möchte ich zurück zum Master Branch wechseln. Ich verwende den Befehl git, merge out, spezifiziere den Zweig, den ich in den Master-Branch zusammenführen möchte . In diesem Fall ist es ein neuer Zweig. Wenn ich mich jetzt im Master-Zweig logge, werden Sie sehen, dass wir diese neuen Änderungen haben. Was wir gerade gemacht haben, ist ein sogenanntes Fast Forward Merge. Auch hier werden wir gerade in den kommenden Vorlesungen über mehr sprechen . Denk nicht zu viel darüber nach. Eine letzte Sache, die ich erwähnen möchte, ist, dass Sie die Änderungen rückgängig machen oder einen Commit rückgängig machen. Aber wenn Sie diese Änderungen bereits in das Remote-Repository übertragen haben, wird das ein Problem verursachen. Da wir nicht über zentralisiertes Repository und Teamzusammenarbeit gesprochen haben , werde ich nicht über den Seder sprechen , aber als Faustregel gilt Denken Sie daran, wenn Sie den Commit rückgängig machen möchten, tun Sie es, bevor Sie all diese Änderungen tatsächlich in das Remote-Repository übertragen. 31. 0401 Schnelle Vorwärtsverbindung: Das Ziel einer Funktion oder eines fehlerbehobenen Zweigs besteht darin all diese Änderungen im Mainstream der Evolution zusammenzuführen , all diese Änderungen im Mainstream der Evolution zusammenzuführen , der normalerweise der Master-Branch sein würde. Lassen Sie uns in diesem Video darüber sprechen, was Schnellvorlauf ist. Stellen Sie sich vor, Sie haben ein Projekt mit Master Branch und diesen drei Kommentaren. Und zu diesem Zeitpunkt habe ich beschlossen, an Feature One zu arbeiten. Und so habe ich einen Feature-Eins-Zweig erstellt und darin auch eine Reihe von Commits gemacht. Nehmen wir nun an, wir haben keine weiteren zusätzlichen Kommentare im Master-Branch. einmal an, nachdem ich den Feature-Branch erstellt habe, Nehmen wir einmal an, nachdem ich den Feature-Branch erstellt habe, bin ich mit all der Arbeit fertig, die ich innerhalb des Feature-Eins-Zweigs erledigen muss. Ich habe all diese Änderungen getestet. Und ich möchte jetzt alle Feature-One-Branch-Änderungen innerhalb des Master-Branches haben . Oder mit anderen Worten, ich möchte Feature One Branch in den Master-Branch zusammenführen . Nun eine Frage an Sie, was kann ich hier tun, damit der Master-Branch alle Änderungen von Feature One Branch haben. Halten Sie das Video an und versuchen Sie es herauszufinden. Nun, lass mich dir einen Hinweis geben. Ich werde dieses Diagramm von hier auf dieses umschreiben . Ich hab nichts getan. Ich habe das Feature nur einen Ast angehoben, aber nach oben. Aber das sollte dir einen Hinweis geben was wir tun können, um alle Änderungen von Feature 1 innerhalb des Master-Branches zu haben alle Änderungen von Feature 1 innerhalb des . Versuch es mal. Nun, ich gebe dir noch einen Hinweis. Wir nennen dies aus diesem Grund eine schnelle Vorlaufzusammenführung. Was ist der FastForward-Teil dabei? Nun, wie wäre es, wenn wir den Master gebeten hätten, auf den neuesten Commit zu verweisen oder einen Branch zu zeigen Würde es das Problem nicht lösen? Im Wesentlichen wurde der Hauptzweig an eine Reihe von Kometen weitergeleitet . Der Master-Branch zeigt jetzt auf einen Commit , der einen Snapshot enthält, auf alle Änderungen des Master-Branches plus alle Änderungen in Feature One Branch verweist. Und da wir mit Feature One Branch fertig sind und ich all diese Änderungen im Master-Branch zusammengeführt habe. Wir können diesen Zweig ganz löschen. schnelle Vorlaufzusammenführung funktioniert jetzt nur, wenn Sie nach dem Erstellen des Feature-Branches keine Kommentare innerhalb des Master-Branch abgeben des Feature-Branches keine Kommentare innerhalb des Master-Branch . Nun noch eine Frage an Sie. Wir haben gerade gesehen, wie wir alle Änderungen von Feature One Branch mithilfe der Schnellvorlaufzusammenführung in den Master-Branch zusammenführen können alle Änderungen von Feature One Branch mithilfe der . Nun wäre es sinnvoll zu sagen, dass ich alle Änderungen von Master Branch in den Feature-Eins-Zweig zusammenführen möchte alle Änderungen von Master Branch in den Feature-Eins-Zweig . Es macht keinen Sinn da Feature One Branch bereits alle Commits enthält sind alle Änderungen des Master-Branches. Wenn Sie jedoch im Master-Branch Kommentare abgegeben haben , nachdem Sie den Feature-Branch erstellt haben, ist das eine ganz andere Geschichte. Und wir werden in den kommenden Vorlesungen darüber sprechen. Im nächsten Video werden wir uns jedoch all diese Untätigkeit ansehen. Wir sehen uns im nächsten. 32. 0402 Schnelle Weiterleitung in Aktion: Um den Schnellvorlauf Merge zu erklären, habe ich das Projekt in diesen Zustand gebracht. Wir haben den Master-Zweig mit diesen drei Dateien, ABC, und es werden in drei verschiedenen Commits ausgeliefert. In ähnlicher Weise haben wir einen Zweig mit den Dateien D, E , F, und sie werden alle in drei verschiedenen Kommentaren geliefert. Schauen wir uns nun viel Untätigkeit im Schnellvorlauf an. Auf der linken Seite haben wir die Git Bash. Auf der rechten Seite haben wir das Arbeitsverzeichnis. Sie können gleichzeitig beobachten, was im Arbeitsverzeichnis passiert , während wir Befehle auf der Git Bash ausführen. Momentan bin ich im Master Branch und du siehst also ABC-Dateien. Wenn ich zum Feature-Branch wechseln würde, werden Sie sehen, dass das Arbeitsverzeichnis werden Sie sehen, dass das Arbeitsverzeichnis mit allen Dateien gefüllt wird , einschließlich Änderungen des Master-Branches sowie des Feature-Branches. Schauen wir uns nun an, auf welche Commits diese Marke nur hinweist. Ich werde Git Refs machen, Head Master. Schauen wir uns in ähnlicher Weise an, was die Feature-Branches wollen. Und wenn ich git log, können Sie sehen, dass der Feature-Branch auf den allerletzten Commit verweist, aber der Master-Branch zeigt auf seinen letzten Commit im Master-Zweig, der das wäre. Jetzt kann ich den Master-Branch nicht in den Feature-Branch zusammenführen , da Feature-Branches bereits alle Änderungen des Master-Branches aufweisen alle Änderungen des Master-Branches Dies macht keinen Sinn. Also müssen wir zurück zum Master Branch wechseln. Und dann werden sie verstehen, dass wir alle Änderungen des Feature-Branches in den Master-Branch einbringen wollen . Und sobald ich diesen Befehl ausgeführt habe, sollten wir in der Lage sein, den Master-Zweig zu sehen dieses Commit zeigt. Es erhält also den Befehl git merge name des Zweigs, den Sie zusammenführen möchten. In diesem Fall handelt es sich um einen Zweig. Und wie Sie sehen können, zeigt die Zusammenfassung, dass dies alle Dateien sind , die jetzt Teil des Master-Zweigs sind. Und sogar das Arbeitsverzeichnis wird mit all diesen Dateien aktualisiert. Wenn Sie sich ansehen, auf welchen Master Branch zeigt, dann zeigt das auf den exakten Commit. Dieser Feature-Zweig zeigt. Das ist viel schneller Vorlauf für dich. Jetzt können wir den Feature-Branch löschen, aber wir werden in der nächsten Vorlesung darüber sprechen. Eine Sache, die ich erwähnen möchte, ist, dass Sie den Zweig möglicherweise nicht immer löschen möchten , wenn Sie damit fertig sind. Manchmal möchten Sie es vielleicht für eine Weile behalten , da es Fälle geben kann , in denen Sie diese Änderungen in letzter Minute vornehmen müssen . Oder es gibt bestimmte Fixes , die Sie als Teil derselben Filiale bereitstellen möchten. Sie werden also denselben Feature-Branch erneut verwenden , um all diese Änderungen vorzunehmen, testen, sie überprüfen zu lassen und dann schließlich all diese Änderungen im Master-Branch zusammenzuführen . Und ja, Sie können denselben Branch wiederverwenden und denselben Branch immer wieder zusammenführen. den meisten Fällen erstellen wir jedoch einen weiteren Branch für Fehlerbehebungen oder Änderungen in letzter Minute und führen diese Änderungen dann im Master-Branch zusammen. Eine weitere Sache, die ich erwähnen möchte, ist, dass dies normalerweise auf GitHub in einer zentralen Polsterung geschieht. Da wir GitHub nicht erforscht haben, macht es für mich keinen Sinn, jetzt darüber zu sprechen. Nichtsdestotrotz ist die Fusion in bestimmten Fällen auch die lokale Verwahrstelle in London. Wir sehen uns als Nächstes. 33. 0403 Löschen des Zweiges und Wiederherstellen: Lassen Sie uns sehen, wie wir einen Branch löschen können , um dies zu erklären. Das Projekt wurde erneut in diesen Zustand zurückversetzt. Ich bin gerade im Bild-Eins-Zweig. Wenn ich versucht habe, den Zweig zu löschen, während ich tatsächlich darin bin, wird ein Fehler ausgegeben, der besagt, dass Sie einen Jet-Punkt-Zweig nicht löschen können. Lass mich das versuchen. Also der Befehl, den ich verwenden muss, um die Zweige zu löschen , git branch. Und dann verwende ich die Option Bindestrich D, stelle sicher, dass es klein geschrieben ist d. Und dann werde ich den Namen des Zweigs angeben. Es wird ein Fehler angezeigt, der besagt, dass die Zweigfunktion nicht gelöscht werden kann, die im Ordner „so und so“ ausgecheckt wurde. Ich werde zurück zum Master-Branch wechseln , um Feature One Branch löschen zu können. Wenn ich jetzt versuche zu löschen, wird get to uns tatsächlich eine Warnung geben , dass keine der Änderungen in einem Zweig enthalten ist, was eigentlich in anderen Zweigen am meisten ist. Und wie Sie es so sehen können, ist das erste Branch-Feature nicht vollständig zusammengeführt. Aber woher weiß es, dass dieser Zweig nicht zusammengeführt wird? Es wird ein Blick auf das letzte Commit von Feature One Branch geworfen. Und es stellt fest, dass es keinen anderen Zweig gibt , der auf dieses Commit verweist. Get warnt uns. Darüber hinaus schlägt es uns vor, dass wir, wenn wir diesen Zweig immer noch löschen möchten, dies mit der Option Bindestrich d tun können. Dies ist ein großes D im Vergleich zu D in Kleinbuchstaben, das wir zuvor verwendet hatten. Und get hat uns tatsächlich den Standardbefehl zur Verfügung gestellt. Ich kann es einfach hier drüben kleben. Und das würde den Zweig löschen. Und natürlich werden wir alle Änderungen verlieren , die in Feature One Branch eingeführt wurden. Als wir diesen Branch gelöscht haben, hat uns Git tatsächlich den HashCode des letzten Commits zur Verfügung gestellt , nur Fall, dass wir etwas damit anfangen wollen. Nehmen wir nun an, dass ich beim Löschen dieses Zweigs einen Fehler gemacht habe und ihn zurückholen wollte. Was ist ein Befehl, der mir hilft, diesen Zweig wiederzufinden? Auch hier kennen Sie das bereits. Wir hatten es in einer unserer vorherigen Vorlesungen verwendet. Nun, es ist git , check Bindestrich b. Und dann geben Sie einen Zweignamen an. Wir können jeden Namen unserer Wahl nennen. Aber ich werde den gleichen Namen machen, Pizza eins. Dann geben wir den HashCode des Kampfes an, auf den dieser Zweig zeigen soll. Im Wesentlichen erstellt dieser Befehl nicht nur das erste Branch-Feature, sondern wir wechseln auch zu diesem Branch, wobei das letzte Commit wobei das letzte Commit HashCode-Funktion dieses Commit ein Branch würde erstellt und dieser Branch würde auf diesen Commit verweisen , den wir gerade gelöscht haben. Wenn Sie diesen Befehl nach einer sehr langen Zeit ausführen, nachdem Sie den Branch gelöscht haben, können Sie dieses Commit möglicherweise nicht mehr sehen und Sie würden die Daten tatsächlich verlieren. Also lasst uns diesen Zweig noch einmal abrufen. Und wie Sie sehen können, haben wir auf diese neue Filiale umgestellt. Und wenn Sie git log, können Sie sehen, dass der Branch auf genau denselben Commit zeigt. Tatsächlich hat die richtige Betrachtungsweise einen Blick darauf geworfen, was sich in einer Verzweigungsdatei von Feature One befindet. Und wie erwartet deutet es auf dieses Commit hin. Jetzt können wir alle Änderungen zusammenführen indem wir zurück zum Master-Branch wechseln. Und das haben wir bereits in unserer vorherigen Vorlesung gesehen. Git, füge Feature eins zusammen. Und das geht. Sie können jetzt fortfahren und diesen Zweig mit der Option d in Kleinbuchstaben löschen diesen Zweig mit der Option d in Kleinbuchstaben und es gibt keinerlei Probleme. Werfen wir einen Blick auf die Liste der Zweige. Und du wirst sehen, dass der einzige Zweig, den wir haben, jetzt der Meister ist. 34. 0404 Verstehen von Three und Zusammenführung: Lassen Sie uns über Drei-Wege-Zusammenführung sprechen und erhalten. Nehmen wir an, dies ist der aktuelle Stand unseres Projekts. Wir haben den Master-Zweig mit drei Commits, m1, m2 und m3. Und dann haben wir auch den Feature-Zweig mit den Commits F1, F2 und F3. Und stellen Sie sich vor, dass wir in jedem dieser Commits eine einzige Datei geliefert haben. Zum Beispiel liefern wir beim M1-Commit m1 Punkt TXT. Im M2-Commit liefern wir m2 dot TXT usw. für den Rest der Kommentare. Jetzt werde ich die Dateinamen in diesem Diagramm nicht behalten , nur um es sauber zu halten. Nehmen wir nun an, dass ich, während ich an Feature-Eins-Änderungen arbeite, zwei zusätzliche Kommentare und einen Master-Branch habe. Nun eine Frage an Sie: Wenn ich mich entscheide, Feature eins jetzt mit Master zusammenzuführen, können wir in diesem Fall erwarten, dass wir in diesem Fall eine Schnellvorlaufzusammenführung durchführen? Die Antwort lautet nein, das wird sie nicht können. Okay, lassen Sie uns hypothetisch annehmen, dass das Gute im Schnellvorlauf zusammengeführt wurde. Wir haben jetzt den Master-Zweig, der den neuesten Commit-Off-Feature-Ein-Branch verweist. Kannst du erraten, was passieren wird? Nun, wir wollten die eingeführten Änderungen und die vier - und m-Phi-Kämpfer verlieren eingeführten Änderungen und die vier - und m-Phi-Kämpfer weil sie nicht unter die übergeordnete Hierarchie des Commits fallen , auf den der Master-Zweig zeigt. Dies ist keine ideale Sache und das Gute führt in diesem Fall keine schnelle Vorwärtszusammenführung durch. Welche IT-Leistung ist jedoch eine sogenannte Drei-Wege-Merge. Was also im Wesentlichen funktioniert, ist wenn wir uns dazu entschließen, Feature 1 in den Master-Branch zusammenzuführen, gingen wir in den Master-Branch und baten get, die Zusammenführung durchzuführen. Und wenn wir es so sagen, wird get künstlich ein Commit erstellen, mit dem, was wir initiieren. Dieses Commit wird zwei Elternteile haben. Mit anderen Worten, dieses Commit-Objekt würde auf zwei andere gemeinsame Objekte verweisen und diese Kommentare geben die letzten Kommentare dieser beiden Zweige aus dieser beiden Zweige Dieses Commit wird Merge-Commit genannt. Und die daraus resultierende Momentaufnahme dieses Commits, die Kombination von Änderungen die in beiden Zweigen eingeführt wurden. Wenn Sie das Arbeitsverzeichnis des Master Branch nach der Zusammenführung anzeigen möchten, werden Sie im Wesentlichen des Master Branch nach der Zusammenführung anzeigen möchten, alle Änderungen sehen, die in beiden Zweigen eingeführt wurden. Sobald wir mit der Zusammenführung fertig sind, können wir den Feature-Eins-Zweig löschen. Beachten Sie, dass das Löschen von Feature One Branch nur diesen Branch löschen würde, aber nicht die Commits, die sich im Feature-Branch befinden. Weil Merge-Commit auf Commit verweist. Also Feature Branch, also get wird das nicht löschen können , sind sie für die Garbagecollection qualifiziert. Wir sprechen jetzt über das Best-Case-Szenario. Am häufigsten haben wir sogenannte Merge-Konflikte. Zum Beispiel, wenn ich dieselbe Datei in beiden Zweigen hinzugefügt habe . Und als wir dann versuchten, diese Zweige zusammenzuführen, wird get uns sagen, dass es in beiden Zweigen erst dann einen Konflikt von Änderungen gibt in beiden Zweigen , wenn wir diesen Zusammenführungskonflikt gelöst haben. Nun, der Git führt alle Zweige zusammen. Ich werde in den kommenden Vorlesungen über Zusammenführungskonflikte sprechen. Und Sie fragen sich vielleicht, warum dies als Drei-Wege-Merge bezeichnet wird . Nun, darauf werden Sie auch in den kommenden Vorlesungen eine Antwort finden . Einmal nachdem wir über die Zusammenführungskonflikte gesprochen haben. Als Nächstes schauen wir uns ein Beispiel für eine Drei-Wege-Zusammenführung an, vorausgesetzt, wir haben keine Konflikte. Wir sehen uns im nächsten. 35. 0405Drei-Wege-Zusammenführung in Aktion: Um das Projekt viel ins Ausland getrieben zu erklären , wurde das Projekt in diesen Staat getrieben. Ich habe zunächst M1, M2, M3 im Master-Zweig festgelegt, und dann habe ich den Feature-Branch-Switch dazu erstellt und dort auch drei Kommentare abgegeben. F1, F2 und F3. wieder zum Master gewechselt und habe zusätzliche Commits gemacht, M4, M5. Und das ist der aktuelle Stand unseres Projekts. Und ganz zu schweigen davon, dass ich für jeden Commit ihre spezifischen Dateien festgeschrieben habe. Jetzt schauen wir mal, wie viel getan wird. Momentan bin ich im Master. Und so können Sie all diese fünf Dateien sehen die all diesen fünf Commits entsprechen. Wenn ich zu Feature One Branch wechseln würde, werden Sie M1, M2, M3 und F1, F2 und F3 sehen , aber nicht m vier und m phi, die im Master-Zweig kamen nachdem wir Feature One Branch erstellt hatten. Und das ist der Grund, warum wir keine Schnellvorlaufzusammenführung durchführen können . Jetzt schalten wir den Master-Branch zurück und führen die Zusammenführung durch, um zu sehen, was passieren wird. Git Merge Funktion eins. Und wir müssen es innerhalb des Master-Branches tun , weil wir alle Feature-One-Änderungen in den Master-Branch einbringen wollen alle Feature-One-Änderungen in den Master-Branch einbringen . Und wenn ich diesen Befehl ausführe, hat er tatsächlich den Standard-Texteditor geöffnet den Standard-Texteditor , den ich bei der Installation des Guten ausgewählt habe. In meinem Fall ist es Notepad Plus, Plus. In deinem Fall könnte es sich um etwas anderes handeln, je nachdem, was du bei der Installation von Git ausgewählt hast. Und wir werden gebeten , eine Art Botschaft einzugeben. Dies ist die Nachricht, die mit dem Merge-Commit verknüpft wäre . Ich kann den Text in etwas anderes in Master ändern, so etwas. Speichern Sie die Datei und schließen Sie das Fenster. Und das hat den Merge-Commit erstellt. Alternativ kann ich während der Ausführung dieses Befehls auch die Option bindestrich m angeben und die Nachricht bereitstellen. Auf diese Weise öffnet get den Texteditor nicht. Okay, jetzt schauen wir uns get log n z an. Wenn Gott einen Merge-Commit erstellt hat. Und tatsächlich hat es den Merge-Commit erstellt. Und es wurde auch erwähnt, dass dieser Ausschuss auf diesen beiden Commits basiert. Dies sind nichts als die letzten Kometen der beiden Zweige. Wir haben also diesen HashCode aus dem Master-Zweig, und dieser gehört zum Feature-Branch. Werfen wir einen Blick darauf, was sich in diesem Merge-Commit-Objekt befindet. Also kopiere ich es. Ich drücke Q, um zur Befehlszeile zurückzukehren , damit ich einige Befehle eingeben kann. Git cat-Datei, Bindestrich b und hashCode des Merge-Commits. Und wenn Sie bemerken, dass es auf diese beiden Commits hinweist. Einer ist der letzte Commit, der Master-Branch , der das wäre. Und dies ist der letzte Feature-Branch. Schauen wir uns an, was sich in diesem Baumobjekt befindet. Ich verwende genau den gleichen Befehl. Und mal sehen, was sich in diesem Baumobjekt befindet. Und lass mich expandieren. Dieses Baumobjekt ist eigentlich eine Kombination aller Änderungen, die in beiden Zweigen vorgenommen wurden. Sie sehen also all diese Dateien, F1-Punkt TXT, nach dxdy, F drei, M1, M2, M3, M4 und M5. Und selbst im Arbeitsverzeichnis werden Sie jetzt alle Änderungen des Feature-Branches sehen . Wenn Sie jedoch zurück zum Feature-Branch wechseln , werden Sie feststellen , dass hier keine Änderungen vorgenommen wurden. Es ist genau das gleiche Arbeitsverzeichnis wie zuvor, die Hypothek. Jetzt können wir tatsächlich weitermachen und den Feature-Eins-Zweig löschen. Aber zuerst sollten wir zurück zum Master Branch wechseln, da wir den Branch dem wir uns gerade befinden , nicht löschen können. Also verwende ich den Befehl get. Ich werde Git Branch Bindestrich D sagen, Feature eins. Und das hat den Zweig gelöscht. 36. 0406 Verstehen von Merge: Lassen Sie uns über Merge-Konflikte sprechen und davon ausgehen, dass ich im Master-Branch einen Commit gemacht habe , nennen wir es M1. Und als Teil dieses Kommentars habe ich die Datei product dot TXT mit ein paar Codezeilen vorgestellt . Jetzt macht es offensichtlich keinen Sinn, Code und eine Punkt-TXT-Datei zu schreiben. Sie müssen davon ausgehen, dass dies eine Art Quelldatei ist, wie die Java-Datei Python oder was auch immer. Jetzt sollte ich auch erwähnen, dass wir normalerweise nie dazu neigen, Commits im Master Branch zu machen. Was wir normalerweise im Master-Branch haben, oder sogenannte Merge-Commits, die wir zuvor besprochen haben. Wenn wir über zentralisiertes Repository und Teamzusammenarbeit sprechen. Sie werden verstehen, wie jeder seine eigenen Zweige erstellen würde , um seine eigenen Funktionen zu nutzen, und dann all diese Änderungen im Master-Branch im zentralen Repository zusammenführen all diese Änderungen . Und wenn wir das Projekt dann lokal aktualisieren, werden wir all diese Merge-Commits von anderen Teammitgliedern in unserem Master-Branch erledigen lassen . Wenn das verwirrend klingt, müssen Sie warten, bis wir über zentrales Repository und Teamzusammenarbeit sprechen . für dieses Beispiel vorerst an, Nehmen wir für dieses Beispiel vorerst an, dass wir Commits im master-Branch machen. Ich habe M1 Commit gemacht dieses Dateiprodukt dot TXT mit ein paar Codezeilen eingeführt . Und dann habe ich noch einen Commit gemacht, nennen wir es m2. Dieses Mal habe ich die Produktpunkt-TXT-Datei mit ein paar weiteren Codezeilen aktualisiert . Nehmen wir an, jetzt habe ich beschlossen, an einem anderen Feature zu arbeiten. Ratet mal was? Ich werde einen Feature-Branch erstellen , daran arbeiten und all diese Änderungen einführen. Und dann haben wir ein Commit gemacht dem ich die Produktpunkt-TXT-Datei geändert habe, indem ich ein paar zusätzliche Codezeilen geschrieben zusätzliche Codezeilen , die für Feature 1 relevant sind. In der Zwischenzeit bin ich zurück zum Master Branch gewechselt. Unsere Projektdatei würde also ungefähr so aussehen weil Master Branch zum Commit auf m zeigt. Und dann nehmen wir an, dass ich einen weiteren engagierten Master-Branch erstellt habe einen weiteren engagierten Master-Branch die Produkt-Dot-TXT-Datei zu aktualisieren, wie Sie hier sehen. Nun eine Frage an dich. Nehmen wir an, ich habe beschlossen, Feature-Branch in den Master-Branch zusammenzuführen . Und ich führe den Befehl aus und kann den Zweig zusammenführen. Würden Sie erwarten, dass get die Zusammenführung durchführt? Die Antwort lautet nein. Warum? Weil wir ein paar Versionen der Produkt-Dot-TXT-Datei haben. In der Master-Branche haben wir Produktpunkt TXT, den Sie auf der linken Seite sehen. Und im Feature-Branch haben wir die Datei, die Sie auf der rechten Seite sehen. Wenn wir good zum Zusammenführen auffordern , können nicht beide Dateien beibehalten werden. Verwirren Sie sich darüber , welche dieser Änderungen beibehalten oder welche Änderungen überhaupt beibehalten werden müssen. Offensichtlich ist es nicht intelligent genug , um Änderungen an unsere Bedürfnisse anzupassen. Es wird uns also überlassen, alle Änderungen vorzunehmen und die Konflikte zu lösen. Nur dann wird tatsächlich die Zusammenführung durchgeführt und ein Merge-Commit erstellt. Wenn Sie den Befehl zum Zusammenführen ausführen, wird im Wesentlichen ein Fehler ausgegeben, der besagt, dass er in einigen Dateien komplex gefunden wurde. Und erst nachdem sie gelöst wurden, werden die Änderungen zusammengeführt und ein Merge-Commit erstellt? Warum wird diese Zusammenführung als Drei-Wege-Merge bezeichnet? Sie fragen sich vielleicht, nun, es liegt im Grunde daran, dass diese Zusammenführung drei Schnappschüsse umfasst, drei Schnappschüsse umfasst, die letzten beiden Kommentare und den Konvekt, der ein unmittelbarer Vorgänger dieser beiden Kommentare ist. Dieser Kollege wird die Datei im unmittelbaren Vorgänger-Snapshot mit den Dateien in den neuesten Schnappschüssen in diesen beiden Zweigen vergleichen unmittelbaren Vorgänger-Snapshot mit . Wenn du es nicht verstanden hast, ist es völlig okay. Es lohnt sich nicht wirklich, es zu wissen. Um es zu erklären. Nun, ich muss tatsächlich tief gehen und mich wieder HashCode und allem befassen, was ich nicht will, weil es überhaupt nicht das ist, was man sich nur daran erinnert, dass diese Art von Modell als Drei-Wege-Merge bezeichnet wird. Und das sollte genügen. Und der Schnellvorlaufmodus wird auch als emerge bezeichnet , da er nur ein paar Schnappschüsse beinhaltet. Als Nächstes werden wir uns all dies in Aktion ansehen und sehen, wie wir die Konflikte lösen können. 37. 0407 Zusammenführen von Konflikten in Aktion Teil 1: In Ordnung, werfen wir einen Blick auf Zusammenführungskonflikte, Untätigkeit. Und zu diesem Zweck habe ich einen neuen Ordner, der momentan nichts hat. Wir werden alles von Grund auf neu machen. In diesem Video versuchen wir, ein Szenario zu erstellen , in dem es zu Konflikten kommt. Und dann werden wir im nächsten Video tatsächlich sehen, wie wir diese Konflikte lösen können , um die Zweige zusammenführen zu können. Das Wichtigste zuerst: Lassen Sie uns das Projekt initialisieren. Nehmen wir nun an, ich habe ein Projekt von einem der Kunden erhalten, während ich gebeten wurde, eine Produktmanagement-Anwendung zu erstellen. Innerhalb des Projekts habe ich vielleicht diese Dateien. Möglicherweise haben wir eine Produktdatei, die den produktbezogenen Quellcode enthält. Und dann haben wir vielleicht eine Lagerbestandsdatei und dann vielleicht auch eine Admin-Datei. Offensichtlich können diese Dateien keine Punkt-TXT-Dateien sein. Sie müssen davon ausgehen, dass es sich um eine Art Quelldatei wie Java, Python, Node.JS oder was auch immer handelt eine Art Quelldatei wie Java, Python, . Lassen Sie uns nun etwas in dieser Datei füllen und simulieren, dass wir tatsächlich Quellcode schreiben. Beginnen wir mit der Produkt-Dot-TXT-Datei. So wie. Sie müssen davon ausgehen, dass es sich tatsächlich um eine Art Quellcode handelt. Speichern Sie die Datei und schließen Sie sie. Und ich werde dasselbe auch für die anderen beiden Dateien tun . Speichern Sie die Datei und schließen Sie sie. Lassen Sie uns dasselbe für die Admin-Datei tun. Speichern und schließen Sie das. Lassen Sie uns all diese Akten inszenieren. Git hinzufügen. Ich verwende Platzhalterzeichen , um alle Dateien zu inszenieren. Und lassen Sie uns diese Änderungen vornehmen. Wie auch immer, eine Nachricht. Nehmen wir nun an, ich habe angefangen an einem anderen Feature zu arbeiten. Deshalb muss ich einen weiteren Zweig erstellen, um an all diesen Feature-bezogenen Änderungen zu arbeiten. Ich verwende den Befehl git checkout Bindestrich b und dann den Namen des Zweigs. Dieser Befehl erstellt also einen Feature-Eins-Zweig und wechselt zu ihm. Wir befinden uns derzeit also innerhalb des Feature-Eins-Zweigs. Lassen Sie uns einige Änderungen vornehmen und diese beiden Dateien Inventar sowie Produktpunkt-TXT-Datei. Aber wir lassen die Admin-Punkt-TXT-Datei so wie sie ist. Ich füge einfach noch ein paar Codezeilen hinzu. Aber ich werde Feature am Anfang dieser Zeilen sagen, nur damit wir wissen, dass diese Linien im Feature-Branch eingeführt werden. Sie kennen den Zweck davon in nur ein bisschen. Ich werde dasselbe für die Inventar-Punkt-TXT-Datei tun. Speichern Sie die Datei auf diese Weise und schließen Sie sie. Lassen Sie uns all diese Änderungen inszenieren. Einige melden und übernehmen alle Änderungen. Lass mich noch einmal zum Master zurückkehren. Lassen Sie uns den Bildschirm löschen und versuchen, die Produktpunkt-TXT-Datei zu aktualisieren. Belassen Sie jedoch diese beiden Dateigrößen. Offensichtlich werden wir hier nicht all diese funktionsbezogenen Änderungen sehen all diese funktionsbezogenen Änderungen , da wir zurück zum Master Branch gewechselt sind. Schließen wir die Datei, inszenieren diese Änderungen und übernehmen diese Änderungen. So wie. Um zu wiederholen, was wir getan haben, haben wir alle diese drei Dateien nicht so gestellt, wie sie sind, bevor die Zweigstelle erstellt wurde . Die Lagerbestandsdatei wurde im Feature-Branch aktualisiert, aber nicht im Master-Branch , seit wir den Zweig erstellt haben, aber die Produktdatei wurde in beiden Zweigen geändert. Können Sie jetzt raten, welche dieser Dateien Konflikte haben werden? Wenn wir versucht haben, zusammenzuführen, werden die Änderungen ab dem nächsten Video fortgesetzt. 38. 0408 Zusammenführen von Konflikten in Aktion Teil 2: Das alles. Lassen Sie uns versuchen, die Zusammenführung durchzuführen und zu sehen , was passieren würde. Ich bin gerade im Master-Zweig und wann muss ich den Befehl git merge feature one ausführen . Gut sagt, dass es Konflikte in der Produktpunkt-TXT-Datei ausgelöst hat . Und es heißt, dass die automatische Zusammenführung fehlgeschlagen ist, die Konflikte behoben und dann das Ergebnis festgeschrieben wird. Das ist ziemlich selbsterklärend. Darüber hinaus sagt Gateway, dass sich unser Projekt im Zusammenführungszustand befindet . In der Verwaltung des Staates. Git formatiert all diese widersprüchlichen Dateien so, dass es für uns einfacher wird, den Komplex zu verstehen und zu lösen. Sie werden gleich wissen, was ich meine. Aber lassen Sie uns versuchen, den Befehl git status auszuführen und zu sehen, was er zu sagen hat. Es heißt, dass wir nicht verschmolzene Pfade haben. Und es fordert uns auf, den Komplex zu reparieren und dann den Befehl git commit auszuführen. Was ist, wenn wir uns entscheiden, aus diesem verschmolzenen Zustand herauszukommen? Wir können diesen Befehl mit dash, dash, ich habe die Option gekauft, das werde ich den Emerging State kaufen und das Projekt wieder so bringen , wie es war, bevor ich den merge-Befehl ausführte. Es hat die Inventarpunkt-TXT-Datei bereitgestellt, da es keine Konflikte gibt. Es ist bereit, zusammengeführt zu werden. Aber während die Produkt-Dot-TXT-Datei unter nicht zusammengeführten Pfaden kategorisiert wird. Also müssen wir alle Dateien, die in diesem Abschnitt aufgeführt sind, die Konflikte lösen und get bitten, all diese Änderungen zu übernehmen , um den Zusammenführungsvorgang abzuschließen und den Merge-Commit zu erstellen. Schauen wir uns nun den Inhalt der Produktpunkt-TXT-Datei an. Während sich unser Projekt im Zusammenführungszustand befindet. Ich wollte Cat Product Dot TXT-Datei sagen. Und Sie können sehen, dass es ein bisschen anders ist , als Sie es vielleicht erwartet hätten. Sie würden dasselbe sehen, selbst wenn Sie die Datei in einem externen Editor öffnen würden . Dies bedeutet im Wesentlichen, dass dieser Codeabschnitt zu head gehört, was bedeutet, dass dieser Aufruf zu dem Zweig gehört , auf den er verwies. Dies sind im Wesentlichen die Änderungen , die im Master-Branch eingeführt wurden. Dann haben wir diese Änderungen , die in Feature One Branch eingeführt wurden. Wenn Sie den Emerging State gekauft haben, indem Sie git merge hyphen sagen , hat Bindestrich gekauft. Sie würden sehen, dass all diese Formatierungen weg sind. Und unser Projekt ist im Nachlass von wesentlicher Bedeutung als hätten wir den Merge-Befehl überhaupt nicht ausgeführt. Versuchen wir erneut, uns zusammenzuschließen und zu sehen, wie wir diese Konflikte lösen können. Jetzt müssen Sie als Programmierer entscheiden , welche dieser Änderungen Sie beibehalten möchten. Oder wenn Sie diese beiden Änderungen beibehalten möchten, können Sie dies auch tun. Man kann buchstäblich Wasser machen, das wir machen wollen. Und wenn Sie fertig sind, bitten Sie einfach get diese Änderungen zu übernehmen und die Merge-Objekte zu erstellen. So beenden Sie die Zusammenführung der beiden Zweige. Also muss ich diese seltsamen Charaktere loswerden , die eingeführt wurden. Und dann möchte ich vielleicht diese Codezeile entfernen, aber all diese drei behalten. Nur ein Beispiel. Was, oh, das ergibt Sinn. Den Code möchtest du behalten. Speichern und schließen Sie es. Und sobald Sie all diese komplexen Probleme manuell gelöst haben, können Sie loslegen und git commit sagen. Bevor wir reinkommen, müssen wir diese Datei, die Produktpunkt-TXT-Datei, tatsächlich bereitstellen. Und dann können wir weitermachen und mit den Änderungen werden wir aufgefordert, eine Commit-Nachricht einzugeben. Ich bin mit der Standardeinstellung zufrieden. Ich wollte diese Datei speichern, schließen. Und dies hat erfolgreich ein Merge-Commit erstellt, was bedeutet, dass unsere Marge jetzt erreicht ist. Und so würden Sie das Status-More-Gen nicht mehr sehen. Schauen wir uns nun den Inhalt all dieser Dateien an. Die Admin-Punkt-TXT-Datei würde unverändert bleiben da sie in keinem der Zweige geändert wurde . Wie auch immer. In der Lagerbestandsdatei werden all diese hinzugefügten Funktionsänderungen angezeigt . Und diese wurden aus dem Feature-Branch zusammengeführt. Fügen Sie die Produkt-Dot-TXT-Datei ein. Es würde den Code enthalten, den wir bei der Lösung der Konflikte aktualisiert haben . Außerdem hoffe ich, dass Sie ein Gefühl dafür bekommen , dass Sie ein robusteres Tool zur Verwaltung Ihres Projekts und seiner Dateien benötigen . Und auch in der Lage sein, alle historischen Veränderungen zu visualisieren , und so weiter. Und hier würden Tools wie Visual Studio, Code, GitHub , Desktop, Quellbaum usw. ins Spiel kommen. Wir werden sie in den kommenden Vorlesungen untersuchen. 39. 0409 Installieren und Einrichten von Visual Studio Code für die Arbeit an Git: Okay, es ist an der Zeit, es zu installieren und eines der verfügbaren Tools zu verwenden , um unser Projekt besser zu verwalten, da wir nicht einfach weiterhin das Windows-Dateisystem und Git Bash verwenden können, um an unserem Projekt zu arbeiten. ein Projekt immer komplexer wird, benötigen wir ein Tool, das uns hilft, unser Projekt besser zu verwalten und einige der historischen Änderungen oder die Liste der von uns durchgeführten Commits anzeigen zu können . Schauen Sie sich die Liste der Zweige an können Sie gleichzeitig einige der Operationen ausführen , ohne Befehle in der Git Bash ausführen zu müssen . Es gibt also viele Tools online und es gibt kein einziges Tool , das für alle möglichen Dinge geeignet ist. Wenn Sie auf die offizielle Website von gate gehen, die Git SCM.com ist, python SCM.com. Und wenn Sie zu diesem Abschnitt gehen rasterlinien, werden Sie sehen , dass sie alle diese Werkzeuge empfehlen. Wenn Sie eines dieser Tools verwenden, sollte es für Sie nicht schwierig sein, eines der anderen hier verfügbaren Tools zu verwenden . Denn obwohl sie sich in Bezug auf die grafische Benutzeroberfläche unterscheiden , boten sie so ziemlich genau die gleiche Funktionalität. Github, Desktop und Source Tree, oder zwei der beliebtesten Optionen. Aber wir werden Visual Studio Code verwenden. Der Grund, warum ich das empfehle, ist dass Visual Studio Code einer der beliebtesten Code-Editoren ist . Es ist eine der beliebtesten Optionen für die Entwicklung von JavaScript-Python-Anwendungen Entwicklung von JavaScript-Python-Anwendungen und unterstützt eine Vielzahl anderer Programmiersprachen. Was Visual Studio-Code jedoch von einigen dieser Tools unterscheidet von einigen dieser Tools , ist die Fähigkeit, Erweiterungen zu installieren. Und so werden wir eine gute Erweiterung installieren. Dadurch erhalten Sie einige der Funktionen, die einige dieser Tools bieten . Diese Tools sind hier drin. Visual Studio Code ist eher ein ganzheitliches Tool, als nur gezielt zu werden. Sobald Sie Visual Studio Code verwendet haben, sollte es für Sie sehr einfach sein, einige dieser Tools UND Gates zu verstehen. Wenn Sie sich für eines dieser Tools entscheiden möchten, können Sie dies tun , wenn Sie damit vertraut sind. Aber ich werde Visual Studio Code mit einer schnellen Google-Suche verwenden . Wir sind auf diese Seite gekommen. Laden Sie Visual Studio herunter, je nachdem, welches Betriebssystem Sie verwenden. Das hab ich schon gemacht. Lassen Sie mich das Installationsprogramm starten. Die Installation ist ziemlich einfach. Sie können einfach alles auf den Standardeinstellungen belassen , es sei denn, Sie möchten etwas ändern. Okay, es ist installiert. Starten wir Visual Studio Code. Lassen Sie uns zunächst zum Explorer gehen und wann Sie das Projekt öffnen, indem Sie auf Ordner öffnen klicken. Ich wähle meine App aus , die wir zuvor erstellt haben. Darüber hinaus gehe ich zum Abschnitt Erweiterungen. Ich würde nach Get suchen. Get Lens ist eine der beliebtesten Optionen. Get graph ist auch eine gute Wahl. Lassen Sie es uns installieren. Ordnung, im nächsten Video werden wir sehen, wie wir mit Zusammenführungskonflikten in Visual Studio-Code umgehen können . Das gibt Ihnen also einen gewissen Einblick Visual Studio Code mob die get-Operationen, die wir damit ausführen können. Wir sehen uns als Nächstes. 40. 0410 Erforschen des VS und Durchführung von GIT Operations: Okay, bevor wir uns tatsächlich ansehen, wie man Zusammenführungskonflikte erstellt und sie im Visual Studio-Code löst. Lassen Sie mich Sie nur durch den aktuellen Stand unseres Projekts führen. Wenn Sie sich erinnern, haben wir unsere Änderungen von Feature eins zu Master Branch zusammengeführt . Dies sind alle Dateien in unserem Projekt. Du kannst einfach auf sie klicken, um einen Blick auf ihren Inhalt zu werfen. Und wenn Sie zu diesem Abschnitt gehen Quellcodeverwaltung, können Sie auch dorthin gehen, indem Sie Strg Umschalt G drücken. Und da wir diese Erweiterung Good Graph installiert haben, sollten Sie in der Lage sein, dieses Symbol anzusehen. Hier sehen Sie alle historischen Veränderungen, die wir eingeführt haben. Sie können auch die grafische Darstellung aller Commits sehen , die wir durchgeführt haben, der Branches, die wir erstellt hatten, und sogar der Zusammenführung, die wir zuvor durchgeführt hatten. Dies ist das erste Commit, das wir im Master-Branch vorgenommen haben, und dann erstellen wir einen Feature-Branch. Wir haben dort einen Kommentar abgegeben. Und dann haben wir einen Kommentar und einen Master-Branch gemacht und schließlich Feature-Branches innerhalb des Master-Branch zusammengeführt. Um den Merge-Befehl zu erstellen. Er hat nicht auf einen dieser Commits geklickt und sich die Änderungen angesehen, die in diesem bestimmten Commit eingeführt wurden, indem auf eine bestimmte Datei geklickt hat. Und Sie können die Änderungen sehen. Lassen Sie uns nun Konflikte schaffen, in denen wir Menschen von Natur aus gut sind. Kehren wir zum Explorer zurück. Aber vorher wollen wir sehen, wie wir einen neuen Branch erstellen können. Ich werde gleich hier eine neue Filiale erstellen. Also werde ich mit der rechten Maustaste auf dieses spezielle Commit klicken und Create Branch sagen. Nennen wir es Feature to Branch, was auch immer. Und ich würde auch gerne zu dieser Branche wechseln. Also aktiviere ich dieses Kontrollkästchen Zweig erstellen. Also haben wir auf die Funktion umgestellt , die wir gerade erstellt haben. Sie können es erkennen, indem Sie einen Blick darauf werfen hier. Hier sehen Sie die gesamte Liste der Filialen. Sobald Sie darauf klicken, können Sie die gesamte Liste der Zweige sehen. Wenn Sie zu einer der Filialen wechseln möchten , klicken Sie einfach darauf. Also wollen wir nur den Zweig beherrschen. Und genau das siehst du hier drin. Lassen Sie mich zurück zu Feature Two Branch wechseln und ein Commit machen. Ich gehe zum Explorer. Lassen Sie mich nur einige Änderungen vornehmen und die Lagerbestandsdatei an Änderungen in der Lagerbestandsdatei oder was auch immer ändern. Ich gehe zurück zu diesem Abschnitt Quellcodeverwaltung. Ich klicke auf dieses Häkchensymbol. Indem ich das mache. Es zeigt mir eine Nachricht, dass keine inszenierten Änderungen folgen werden. Möchtest du alle Änderungen inszenieren und direkt übernehmen? Wenn ich jetzt auf Ja klicke, werden die Änderungen vor dem Commit inszeniert , ohne dass ich das tun muss. Oder wenn Sie es alleine machen möchten, können Sie das auch tun. Klicken Sie einfach mit der rechten Maustaste auf diese Datei, die sich derzeit in der Kategorie Änderungen Und dann klicken Sie auf Stage Changes. Dies würde diese Datei in die Kategorie der gestaffelten Änderungen verschieben. Und jetzt, wenn Sie zu uns kommen, sollten Sie kein Problem oder was auch immer haben. Aber lassen Sie uns eine Art Commit-Nachricht eingeben. Was auch immer. Klicken Sie auf dieses Symbol und machen Sie gerade ein neues Commit und Feature Two Branch. Schauen wir uns die Grafik an. Und wie Sie sehen können, haben wir jetzt ein neues Commit in der Grafik hinzugefügt. Und hier ist es. Wechseln wir jetzt zurück zum Master-Branch. Lassen Sie uns Änderungen in derselben Lagerbestandsdatei vornehmen. Um Konflikte zu erzeugen, speichern Sie die Datei. Geh zurück. Dieses Mal. Drücken wir die Taste S. Wenn Sie diese Eingabeaufforderung nicht erneut sehen möchten, können Sie einfach nie drücken. Gehen wir zurück, um noch einmal ein Diagramm zu erhalten. Und wie Sie sehen können, haben wir jetzt einen neuen Commit - und Master-Branch. Lassen Sie uns nun versuchen, die Zusammenführung durchzuführen. Wie leisten wir viel in Visual Studio Code? Aber diese Erweiterung ist ziemlich einfach. Klicken Sie einfach mit der rechten Maustaste auf einen der Zweige. Ich werde auf Feature klicken, um zu verzweigen. Und Sie können diese Option wählen, die besagt aktuellen Zweig zusammenführen. Was ist der aktuelle Zweig dh Maske? Nun, es ist einfach der Zweig , auf den dies hingewiesen hat. Mit anderen Worten, es ist der Master-Branch. Lass uns darauf klicken und sehen, was passiert. Es fragt uns, ob wir einen neuen Commit erstellen wollen, auch wenn eine schnelle Vorwärtszusammenführung möglich ist? Ich antworte nicht gern. Ja, zusammenführen. Wie erwartet haben wir einen Konflikt Auto Merging Inventor oder dxdy. Und dann heißt es, wir haben einen Konflikt. Verwerfen Sie es, gehen Sie zum Explorer, gehen Sie zu dieser Datei. Und dieses Mal hat es ein Format bei uns auf diese Weise, genau wie zuvor. Aber wir benutzen heute Gott hat uns nur wenige Optionen gegeben. Wenn Sie dies bemerken, akzeptieren aktuelle Änderungen, akzeptieren Sie eingehende Änderungen oder die Änderungen, die von der Funktion zur Verzweigung eingehen, an den Master-Branch. Oder akzeptiere beide Änderungen. Oder Sie können die Änderungen auch vergleichen. Du kannst wählen. Jede dieser Optionen wenn Sie Ihre eigene Bearbeitung vornehmen möchten, sodass Sie dies auch tun können. Löschen Sie einfach alles und nehmen Sie Ihre eigenen Änderungen vor oder bearbeiten Sie die vorhandene. Was auch immer. Fügen wir hinzu, um beide Änderungen beizubehalten, oder klicken Sie darauf, dass Sie die Änderungen akzeptieren. Speichern Sie jetzt die Datei. Kehren Sie zur Quellcodeverwaltung zurück. Bevor wir es begehen. Lassen Sie uns inszenieren, diese Veränderungen sind fair inszeniert. Klicken wir auf diese Checkbox. Ich bin mit der vorhandenen Nachricht zufrieden. Und ratet mal was? Dies hat gerade den Merge-Commit erstellt. Wenn Sie nun ein anderes Tool verwenden, nicht den Visual Studio Code, sollten Sie in der Lage sein, all diese Operationen auf die eine oder andere Weise zu betrachten . Nur die grafische Benutzeroberfläche kann sich ändern. In all diesen Tools können Sie jedoch fast die gleichen Operationen ausführen. Wenn Sie zum Beispiel auf die offizielle Website von source tree gehen , können Sie viel erzählen, indem Sie sich dieses Bild ansehen. Wir haben also eine Geschichte, die die historischen Veränderungen zeigt. Sie haben auch dieses Diagramm, genau wie das, das wir im Visual Studio Code haben. Du kannst auch in diesen Verzweigungsabschnitt gehen um einen Blick auf die Zweige zu werfen und etwas damit zu tun, wie sie zu erstellen, zu löschen usw. Sie können auch Commits ausführen. Und einige der anderen Operationen, die wir nicht untersucht haben. Wir werden es in den kommenden Vorlesungen auf jeden Fall erkunden. Aber ich hoffe du hast den Punkt verstanden. Es spielt keine Rolle , welches Tool Sie verwenden. Letztlich hat jedes Tool den gleichen Zweck, nämlich Ihre Arbeit zu vereinfachen. Jetzt können wir diesen Zweig wohl löschen. Wir würden es nicht länger brauchen. Also klicke ich mit der rechten Maustaste auf diesen Zweig und sage Zweig löschen. Kann dieselbe Funktion ausführen, auch einen Zweig. Und natürlich löscht die führende Marke ihre Commits nicht. Wie wir bereits besprochen hatten. Hoffe es macht Sinn, oder? Um das zu tun, was ich gerade in Visual Studio Code gemacht habe , und ein Gefühl dafür zu bekommen , wie alles funktioniert. Und lassen Sie sich nicht einschüchtern Sie sich dieses Tool ansehen. Es ist ziemlich einfach. Tool ist einfach wie ein Texteditor mit einigen wirklich coolen Funktionen. Es soll unser Leben einfacher machen, nicht schwieriger. Wir sehen uns als Nächstes. 41. 0411 Git Rebase vs Merge: Lass uns über Git Rebase sprechen. Git Rebase ist eine Art Alternative zu Merge. Es dient so ziemlich dem gleichen Zweck wie beim Zusammenführen. Davon abgesehen können Sie das eine nicht durch das andere ersetzen. Wir können VBS nicht durch die Zusammenführung ersetzen, und umgekehrt können wir die Zusammenführung nicht durch die Rebase ersetzen. Es hat seine eigenen Vor- und Nachteile und jedes hat seinen eigenen Zweck. Und darüber werden wir in dieser Vorlesung und den nächsten Vorlesungen sprechen . Lassen Sie uns zunächst versuchen zu verstehen, was genau Rebase ist. Im Falle einer Drei-Wege-Merge fordert GET an, ein Merge-Commit zu erstellen dessen Snapshot die Änderungen beider Zweige darstellen würde . Das klingt zwar nicht nach einem Problem, aber wir sehen einige Probleme damit, insbesondere wenn unser Projekt immer größer wird. Zuallererst würde das Zusammenführen diesen zusätzlichen Merge-Commit erzeugen , der möglicherweise unnötig ist. Zweitens entsteht das Problem der sogenannten Spaghetti-Commit-Geschichte. Wenn Sie in Ihrem Projekt zu viele Zusammenführungsvorgänge ausführen. So könnte unsere Projektgeschichte aussehen. Wenn Sie sich nun alle historischen Commits ansehen würden, nehmen wir vielleicht an, dass Sie den Befehl git log im master-Branch ausgeführt haben . Alles, was Sie sehen werden, sind ein paar Merge-Commits. Sie sehen nicht die Änderungen, die einzelnen Zweigen eingeführt wurden. Sie müssen durch die übergeordnete Hierarchie navigieren , um alle branchenbezogenen Änderungen oder Kommentare anzeigen zu können. Das wird viel Verwirrung stiften. Rebus hat diese Probleme, die wir bei Merge-Commits sehen, irgendwie angesprochen. Um zu verstehen, wie Rabatte genau funktionieren, nehmen wir an, dass wir die Zusammenführung dieser beiden Zweige nicht durchgeführt haben . Und das ist der aktuelle Stand unseres Projekts. Nehmen wir nun an, dass ich in Feature One Branch bin und den Befehl git rebase ausgeführt habe. Was jetzt gut tun würde, ist zunächst einmal zu versuchen, den gemeinsamen Vorfahren beider Zweige zu finden , was in diesem Fall N3-Commit ist. Und dann werden all diese Änderungen, die in Feature 1 eingeführt wurden, vorübergehend gespeichert . Irgendwo im Projektarchiv. Es würde dann das Feature einen Zweig auf die Spitze des Master-Zweigs verweisen , was in diesem Fall m phi commit ist. Git wendet alle diese gespeicherten Commits nacheinander erneut an. Dies ist so, dass wir den Zweig AT MY commit erstellt und all diese Funktionen eingeführt haben commit erstellt und all diese Funktionen eingeführt , die zu Änderungen im Feature-Branch führen. Früher haben unsere Feature-Zweige auf M3-Commit basiert. Jetzt, nachdem der Befehl rebase ausgeführt wurde, wird er jetzt auf m phi umbasiert. Während dieses Vorgangs können Sie jetzt genauso gut Konflikte sehen. Wir können sie genauso lösen, wie wir Konflikte im Falle eines Zusammenführungsvorgangs gelöst hatten . Ein Beispiel dafür haben wir uns in den kommenden Vorlesungen angesehen. Wenn Sie sich nun dieses Diagramm ansehen, stellen Sie fest, dass wir tatsächlich eine Schnellvorlaufzusammenführung wie folgt durchführen können . Ratet mal was? Es wurden keine zusätzlichen Kommentare eingebracht. Allo-Commits sind linear mit der Zusammenführungsoperation. Wenn Sie das Problem der Spaghetti-Commit-Geschichte mit Rebase hatten , haben wir eine lineare Entwicklung, wie Sie hier sehen, was es uns leichter macht, einen Blick auf die Commit-Historie zu werfen. Und wenn Sie jetzt den Befehl git log ausführen, werden Sie nicht nur sehen, wie die Änderungen im Master-Branch eingeführt wurden werden Sie nicht nur sehen , sondern auch alle funktionsbezogenen Kommentare linear. Jetzt denken Sie vielleicht , dass wir Rebase verwenden können und dass wir niemals wieder Merge verwenden müssen. Du könntest falsch liegen. Es gibt bestimmte Szenarien, in denen Rebasing ideal ist, und es gibt andere Szenarien in denen vieles eine bessere Option ist. Sie werden als Nächstes mehr darüber verstehen. 42. 0412 Durchführung von Rebase im VS-Code: Okay, schauen wir uns ein Beispiel für git rebase an. Aber vorher möchte ich Sie durch den aktuellen Stand unseres Projekts führen. Ich habe zu diesem Zweck tatsächlich ein brandneues Projekt erstellt und eine Reihe von Commits gemacht. Lassen Sie mich Ihnen einfach erklären, was genau ich getan habe. Seit dem Master-Zweig als Teil des allerersten Commits habe ich gerade diese TXT-Dateien, Admin-Inventar- und Produkt-Dot-TXT-Dateien eingeführt . Und in jeder dieser Dateien habe ich gerade ein paar Textzeilen hinzugefügt , als hätten wir Code geschrieben. Das nächste Commit ging auch innerhalb des Masters. Und davor habe ich natürlich einen Branch erstellt , der auf dem allerersten Commit basiert. Im Rahmen des zweiten Commits, wie die Nachricht uns nahelegt, Admin Edits und Master. Ich habe gerade eine Textzeile in die Admin-Punkt-TXT-Datei eingefügt. Und dann habe ich mein erstes Commit im Feature-Branch gemacht und schlägt die Nachricht Inventaränderungen von Feature One Branch vor. Ich habe gerade eine Textzeile in die erfundene oder TXT-Datei eingefügt . Nächstes Mal Commit im Master-Branch gemacht. Und dieses Mal habe ich der Produktpunkt-TXT-Datei eine Textzeile hinzugefügt . Und dann habe ich im Feature-Zweig noch einen Kommentar abgegeben, in dem ich die Produktpunkt-TXT-Datei bearbeitet habe . Auf der ganzen Linie. Wenn wir die Rebase durchführen, werden wir Konflikte in Produktpunkt-TXT-Datei haben, da wir einen Commit im Master durchgeführt haben, wo wir die Produktpunkt-TXT-Datei bearbeitet haben, und dasselbe wird in der Feature Branch auch. Nächstes Mal machte ich noch einen engagierten Master-Branch. Nun, das ist nicht wirklich nötig, um das zu erklären, aber ich habe diesen Kommentar nur gemacht , damit das Diagramm so aussieht, wie wir es wollen. Im Grunde stellt diese blaue Linie derzeit den Master-Zweig dar, während die rote Linie den Feature-Branch darstellt. Dies ist jedoch möglicherweise nicht immer der Fall. Welchen Zweig wir auch machen, der letzte Commit, der zuerst angezeigt wird. Wenn ich zum Beispiel einen weiteren Feature-Branch kommentieren würde , würde der Feature-Branch blau und der Master-Branch rot werden. Es könnte verwirrend aussehen. Und deshalb habe ich dieses zusätzliche Commit hinzugefügt , damit zuerst der Master-Branch und dann der Feature-Branch angezeigt wird. Bevor wir nun fortfahren, ist es wirklich wichtig, dass du verstehst, was genau vor sich geht und welche Änderungen wir bei jedem dieser Commits vorgenommen haben . Deshalb stelle ich Ihnen dieses Projekt zum Download zur Verfügung. Sie können es einfach in Visual Studio-Code importieren und sich die gesamte Liste der Änderungen ansehen, sie verstehen und erst dann fortfahren. Andernfalls wirst du anfangen, dich selbst zu verwirren. Wenn du mitmachen kannst, ist das großartig. Wenn nicht, machen Sie eine Pause, verstehen Sie, was hier vor sich geht, und schauen Sie dann weiter zu. Wie Sie sehen können, basiert Feature One Branch derzeit auf dem allerersten Commit auf dem Master-Branch. Wir wollen jetzt Feature einen Branch auf den neuesten Commit Off-Master-Branch rebasen . Wie machen wir das? Nun, klicken wir mit der rechten Maustaste auf den allerletzten Commit, den Master-Branch. Und dann haben wir diese Option namens Rebase current branch bei diesem Commit. Der aktuelle Zweig ist Master-Branch. Wann soll zum Feature-Branch gewechselt werden? Und wir wissen, dass wir auf einen Zweig gedrängt haben , weil dieser Kreis genau hier auf Feature einen Branch zeigt , bevor er auf den Master-Branch zeigte. wir nun mit der rechten Maustaste auf den letzten Commit Off-Master-Branch und wählen diese Option mit der Bezeichnung Aktuelle Verzweigung rebase. Dabei weisen die aktuellen Zweige einen Zweig auf. Und das sollte idealerweise neu basieren, sofern wir keine Konflikte haben. Natürlich werden wir Konflikte sehen, da wir, wie ich bereits erwähnt habe, die Produktpunkt-TXT-Datei in beiden Zweigen bearbeitet haben. Klicken wir also auf Rebase. Wie Sie sehen können, haben wir Konflikte. Lass uns das abweisen. Nun, wir sollten diese Dateien idealerweise mit komplex sehen , lass mich aktualisieren. Und da hast du es. Sie können die Konflikte so lösen, wie Sie es möchten. In meinem Fall möchte ich nur beide Änderungen akzeptieren. Speichern Sie die Datei. Und dann drücke ich dieses Plus-Symbol, um diese Datei zu inszenieren. Und dann kann ich auf dieses Häkchensymbol klicken , um mit dem Rebase-Vorgang fortzufahren. Und die Nachricht, die hier standardmäßig aufgefüllt wird , ist die Nachricht der Kommentarfunktion, eines Zweigs, der den Konflikt tatsächlich erzeugt. Wir haben diesen Editor geöffnet. Aber ich lasse die Nachricht einfach so wie sie ist, schließe die Datei. Und damit sollte der Rebase-Vorgang abgeschlossen sein. Wie Sie sehen können, sind die ersten vier Commits außerhalb Master-Branches und die anderen beiden Kommentare gehören zum Feature-Branch. Jetzt können wir weitermachen und den Fast Forward March durchführen. Also wechsle ich zurück zum Master Branch. Rechtsklick auf dieses Commit. Und dann kann ich in aktuellen Zweig zusammenführen wählen. Also möchte ich Feature One Branch in den Master-Branch zusammenführen . Ich möchte kein neues Commit für die schnelle Vorwärtszusammenführung erstellen . So führen Sie also Rebase durch. Und wenn Sie bemerken, haben wir diese lineare Entwicklung, was wir von Rebase erwarten . Wir sehen uns als Nächstes. 43. 0413 Git Rebase in Git Bash Konflikte überspringen und die Rebase abbrechen: Okay, lass uns sehen, wie wir Git Rebase von Git Bash aus durchführen können . Momentan sind wir in Master Branch, um zu Feature One Branch zu wechseln , um diesen Befehl ausführen zu können. Übrigens haben wir das Projekt wieder so gebracht , wie es am Anfang unseres vorherigen Videos aussah . Damit wir Dinge wiederholen und sehen können wie es von Git Bash aus funktioniert. Ich werde zum Feature-Branch wechseln. Es kann gleichzeitig beobachten, was in diesem Diagramm passiert. Git rebase. Wo möchte ich rebasen, um ein Commit durchzuführen? Dieser Master-Zweig zeigt auf jemanden, der Meister sagt. Und wie Sie erwarten können, werden wir die Konflikte sehen. Lassen Sie uns weitermachen und sie auflösen. Meiner Meinung nach würde ich wieder nicht beide Änderungen akzeptieren, die Datei speichern und zu Git Bash zurückkehren, um diese Datei zu inszenieren, git add product dot TXT-Datei. Und dann müssen wir diesen Befehl ausführen. Git Rebase, Bindestrich, Bindestrich führen weiterhin das Rebasing durch. Und genau das werde ich tun. Sie haben auch die Möglichkeit zu überspringen. Wenn du diesen Befehl ausführst, überspringt Git einfach den Commit, der die Konflikte verursacht. Es ist so, als ob Sie den Feature-Branch zum Kommentieren, der die Konflikte verursacht, nicht erstellt haben Feature-Branch zum Kommentieren . Wenn Sie diesen Befehl ausführen, vielleicht nachdem Sie das Rebasing erfolgreich durchgeführt haben, möchten Sie möglicherweise alle diese Änderungen manuell erneut anwenden. Da wir den Komplex jedoch gelöst haben, müssen Sie diese Option nicht verwenden, sondern können gerne damit experimentieren. Sobald ich diesen Befehl ausgeführt habe. Auch hier wird es uns die Botschaft zeigen. Wir können es so lassen wie es ist. Oder wenn Sie es ändern möchten, können Sie es ändern. Lass uns schließen. Und wie Sie hier sehen können, haben wir unseren Feature-Branch mit dem Master-Branch neu basiert . Lassen Sie uns nun den Merge-Teil durchführen , den wir zurück zu Master Git Merge Feature One wechseln Master Git werden. Und wie Sie sehen können, stimmen beide Zweige überein. Wenn jetzt ein Bone von git log Befehl ist, werden Sie alle Commits, die in beiden Zweigen eingeführt wurden, linear sehen , was wir brauchen. Und übrigens eine gut funktionierende Rebase-Operation. Und aus irgendeinem Grund haben Sie beschlossen, es abzubrechen, dann können Sie diese Option verwenden, git rebase, hyphen, hyphen, die ich gekauft habe. Wir sehen uns als Nächstes. 44. 0414 Git Interaktive Rebase: Halten Sie das, lassen Sie uns über interaktives Rebase sprechen. Und zu diesem Zweck habe ich das Projekt 1 Sekunde auf das zurückgebracht , was es früher war. Bevor Sie den Rebase-Vorgang ausführen. Lassen Sie mich zu Feature One Branch wechseln und das Rebasing durchführen. Ich möchte mit der rechten Maustaste auf den neuesten Commit Off Master klicken und auf aktuellen Zweig in diesem Kommentar rebase klicken. Aber dieses Mal werde ich diese Option wählen, die blonde interaktive Rebase im neuen Terminal besagt . Dies entspricht dem Ausführen des Befehls git rebase mit der Option dash, dash interact to. Klicken wir auf Ja Rebase. Und dieses Mal öffnen wir den Texteditor. Hier siehst du die Liste der Inhaber von Commits, die Teil des Feature-Eins-Zweigs sind. Was interaktives Rebase uns ermöglichen würde, ist, dass wir tatsächlich viele Anpassungen vornehmen können tatsächlich viele Anpassungen vornehmen , die auf unsere Bedürfnisse zugeschnitten sind. Wenn du siehst, haben wir hier eine Reihe von Befehlen, die wir verwenden können, um Git mitzuteilen was wir mit den Commits machen wollen oder einen Zweig zeigen. Standardmäßig wird dieser Befehl pick verwendet, was bedeutet, dass wir dieses Komitee verwenden möchten. Das bedeutet im Wesentlichen, dass wir wollen, dass diese Kometen von Feature One Branch Kandidaten für die Rebase-Operation sind. Sie können diesen Befehl jedoch je nach Anforderung in einen anderen Befehl ändern . Zum Beispiel möchte ich vielleicht diesen Befehl reward verwenden, was bedeutet, dass Commit verwendet wird, aber die Commit-Nachricht hinzugefügt wurde. Im Wesentlichen können Sie diesen Befehl verwenden, wenn Sie die Nachricht in eine andere Nachricht ändern möchten , wenn Sie die Nachricht in eine andere . Lassen Sie uns, ich möchte die Botschaft dieses speziellen Ausschusses ändern . Und lass uns das machen. Ich möchte diesen Drop-Befehl verwenden. Um diesen speziellen Commit fallen zu lassen. Ich weiß, dass dieser Kommentar zu Konflikten führen wird weil wir die Produkt-Dot-TXT-Datei in diesem Commit bearbeitet haben. Also werde ich das fallen lassen. Ebenso haben Sie eine Reihe anderer Befehle , die Sie verwenden können. Sie können einfach die Beschreibung durchgehen und prüfen, ob sie Ihren Bedürfnissen entspricht. Speichern Sie die Datei und schließen Sie sie. Wir werden also eine weitere Aufforderung sehen, die uns auffordert, die Botschaft dieses Commits zu verketten. Wenn Sie sich an diesen speziellen Commit erinnern, hatten wir den Befehl reward verwendet. Das ist der Punkt, an dem ich das erhalte, was uns dazu veranlasst , die Botschaft an etwas anderes zu ketten. Sie können das ändern , was Sie wollen. Sag natürlich nicht blah, blah, tippe etwas Sinnvolles. Ich möchte die Datei speichern und schließen. Also dieses Mal, wenn du bemerkst, dass wir nur fünf Commits haben. Weil wir einen der Commits im Feature-Branch gelöscht haben, in dem wir Änderungen an der Produktpunkt-TXT-Datei vorgenommen haben. Und auch für die andere Kommentarfunktion würde ein Zweig die Nachricht in bla, bla ändern. Versuchen Sie also, mit interaktivem Rebase zu experimentieren . Wir sehen uns als Nächstes. 45. 0501 Git Rebase vs Merge: Lass uns über Git Rebase sprechen. Git Rebase ist eine Art Alternative zu Merge. Es dient so ziemlich dem gleichen Zweck wie beim Zusammenführen. Davon abgesehen können Sie das eine nicht durch das andere ersetzen. Wir können VBS nicht durch die Zusammenführung ersetzen, und umgekehrt können wir die Zusammenführung nicht durch die Rebase ersetzen. Es hat seine eigenen Vor- und Nachteile und jedes hat seinen eigenen Zweck. Und darüber werden wir in dieser Vorlesung und den nächsten Vorlesungen sprechen . Lassen Sie uns zunächst versuchen zu verstehen, was genau Rebase ist. Im Falle einer Drei-Wege-Merge fordert GET an, ein Merge-Commit zu erstellen dessen Snapshot die Änderungen beider Zweige darstellen würde . Das klingt zwar nicht nach einem Problem, aber wir sehen einige Probleme damit, insbesondere wenn unser Projekt immer größer wird. Zuallererst würde das Zusammenführen diesen zusätzlichen Merge-Commit erzeugen , der möglicherweise unnötig ist. Zweitens entsteht das Problem der sogenannten Spaghetti-Commit-Geschichte. Wenn Sie in Ihrem Projekt zu viele Zusammenführungsvorgänge ausführen. So könnte unsere Projektgeschichte aussehen. Wenn Sie sich nun alle historischen Commits ansehen würden, nehmen wir vielleicht an, dass Sie den Befehl git log im master-Branch ausgeführt haben . Alles, was Sie sehen werden, sind ein paar Merge-Commits. Sie sehen nicht die Änderungen, die einzelnen Zweigen eingeführt wurden. Sie müssen durch die übergeordnete Hierarchie navigieren , um alle branchenbezogenen Änderungen oder Kommentare anzeigen zu können. Das wird viel Verwirrung stiften. Rebus hat diese Probleme, die wir bei Merge-Commits sehen, irgendwie angesprochen. Um zu verstehen, wie Rabatte genau funktionieren, nehmen wir an, dass wir die Zusammenführung dieser beiden Zweige nicht durchgeführt haben . Und das ist der aktuelle Stand unseres Projekts. Nehmen wir nun an, dass ich in Feature One Branch bin und den Befehl git rebase ausgeführt habe. Was jetzt gut tun würde, ist zunächst einmal zu versuchen, den gemeinsamen Vorfahren beider Zweige zu finden , was in diesem Fall N3-Commit ist. Und dann werden all diese Änderungen, die in Feature 1 eingeführt wurden, vorübergehend gespeichert . Irgendwo im Projektarchiv. Es würde dann das Feature einen Zweig auf die Spitze des Master-Zweigs verweisen , was in diesem Fall m phi commit ist. Git wendet alle diese gespeicherten Commits nacheinander erneut an. Dies ist so, dass wir den Zweig AT MY commit erstellt und all diese Funktionen eingeführt haben commit erstellt und all diese Funktionen eingeführt , die zu Änderungen im Feature-Branch führen. Früher haben unsere Feature-Zweige auf M3-Commit basiert. Jetzt, nachdem der Befehl rebase ausgeführt wurde, wird er jetzt auf m phi umbasiert. Während dieses Vorgangs können Sie jetzt genauso gut Konflikte sehen. Wir können sie genauso lösen, wie wir Konflikte im Falle eines Zusammenführungsvorgangs gelöst hatten . Ein Beispiel dafür haben wir uns in den kommenden Vorlesungen angesehen. Wenn Sie sich nun dieses Diagramm ansehen, stellen Sie fest, dass wir tatsächlich eine Schnellvorlaufzusammenführung wie folgt durchführen können . Ratet mal was? Es wurden keine zusätzlichen Kommentare eingebracht. Allo-Commits sind linear mit der Zusammenführungsoperation. Wenn Sie das Problem der Spaghetti-Commit-Geschichte mit Rebase hatten , haben wir eine lineare Entwicklung, wie Sie hier sehen, was es uns leichter macht, einen Blick auf die Commit-Historie zu werfen. Und wenn Sie jetzt den Befehl git log ausführen, werden Sie nicht nur sehen, wie die Änderungen im Master-Branch eingeführt wurden werden Sie nicht nur sehen , sondern auch alle funktionsbezogenen Kommentare linear. Jetzt denken Sie vielleicht , dass wir Rebase verwenden können und dass wir niemals wieder Merge verwenden müssen. Du könntest falsch liegen. Es gibt bestimmte Szenarien, in denen Rebasing ideal ist, und es gibt andere Szenarien in denen vieles eine bessere Option ist. Sie werden als Nächstes mehr darüber verstehen. 46. 0502 Durchführung von Rebase in VS-Code & Umgang mit Konflikten: In Ordnung, schauen wir uns ein Beispiel für Git Rebase an. Aber vorher möchte ich Sie durch den aktuellen Stand unseres Projekts führen. Ich habe zu diesem Zweck tatsächlich ein brandneues Projekt erstellt und eine Reihe von Commits gemacht. Lassen Sie mich Ihnen einfach erklären, was genau ich getan habe. Seit dem Master-Zweig als Teil des allerersten Commits habe ich gerade diese TXT-Dateien, Admin-Inventar- und Produkt-Dot-TXT-Dateien eingeführt . Und in jeder dieser Dateien habe ich gerade ein paar Textzeilen hinzugefügt , als hätten wir Code geschrieben. Das nächste Commit ging auch innerhalb des Masters. Und davor habe ich natürlich einen Branch erstellt , der auf dem allerersten Commit basiert. Im Rahmen des zweiten Commits, wie die Nachricht uns nahelegt, Admin Edits und Master. Ich habe gerade eine Textzeile in die Admin-Punkt-TXT-Datei eingefügt. Und dann habe ich mein erstes Commit im Feature-Branch gemacht und schlägt die Nachricht Inventaränderungen von Feature One Branch vor. Ich habe gerade eine Textzeile in die erfundene oder TXT-Datei eingefügt . Nächstes Mal Commit im Master-Branch gemacht. Und dieses Mal habe ich der Produktpunkt-TXT-Datei eine Textzeile hinzugefügt . Und dann habe ich im Feature-Zweig noch einen Kommentar abgegeben, in dem ich die Produktpunkt-TXT-Datei bearbeitet habe . Auf der ganzen Linie. Wenn wir die Rebase durchführen, werden wir Konflikte in Produktpunkt-TXT-Datei haben, da wir einen Commit im Master durchgeführt haben, wo wir die Produktpunkt-TXT-Datei bearbeitet haben, und dasselbe wird in der Feature-Branch auch. Nächstes Mal machte ich noch einen engagierten Master-Branch. Nun, das ist nicht wirklich nötig, um das zu erklären, aber ich habe diesen Kommentar nur gemacht , damit das Diagramm so aussieht, wie wir es wollen. Im Grunde stellt diese blaue Linie derzeit den Master-Branch dar, während die rote Linie den Feature-Branch darstellt. Dies ist jedoch möglicherweise nicht immer der Fall. Welchen Branch wir auch immer machen der letzte Commit, der zuerst angezeigt wird. Wenn ich zum Beispiel einen weiteren Feature-Branch kommentieren würde , würde der Feature-Branch blau und der Master-Branch rot werden. Es könnte verwirrend aussehen. Und deshalb habe ich dieses zusätzliche Commit hinzugefügt , damit zuerst der Master-Branch und dann der Feature-Branch angezeigt wird. Bevor wir nun fortfahren, ist es wirklich wichtig, dass du verstehst, was genau vor sich geht und welche Änderungen wir bei jedem dieser Commits vorgenommen haben . Deshalb stelle ich Ihnen dieses Projekt zum Download zur Verfügung. Sie können es einfach in Visual Studio-Code importieren und sich die gesamte Liste der Änderungen ansehen, sie verstehen und erst dann fortfahren. Sonst wirst du anfangen, dich selbst zu verwirren. Wenn du mitmachen kannst, ist das großartig. Wenn nicht, machen Sie eine Pause, verstehen Sie, was hier vor sich geht, und schauen Sie dann weiter zu. Wie Sie sehen können, basiert Feature One Branch derzeit auf dem allerersten Commit auf dem Master-Branch. Wir wollen jetzt Feature einen Branch auf den neuesten Commit Off-Master-Branch rebasen . Wie machen wir das? Nun, klicken wir mit der rechten Maustaste auf den allerletzten Commit, den Master-Branch. Und dann haben wir diese Option namens Rebase current branch bei diesem Commit. Der aktuelle Zweig ist Master-Branch. Wann soll zum Feature-Branch gewechselt werden? Und wir wissen, dass wir auf einen Zweig gedrängt haben , weil dieser Kreis genau hier auf Feature einen Branch zeigt , bevor er auf den Master-Branch zeigte. wir nun mit der rechten Maustaste auf den letzten Commit Off-Master-Branch und wählen diese Option mit der Bezeichnung Aktuelle Verzweigung rebase. Dabei weisen die aktuellen Zweige einen Zweig auf. Und das sollte idealerweise neu basieren, sofern wir keine Konflikte haben. Natürlich werden wir Konflikte sehen, da wir, wie ich bereits erwähnt habe, die Produktpunkt-TXT-Datei in beiden Zweigen bearbeitet haben. Klicken wir also auf Rebase. Wie Sie sehen können, haben wir Konflikte. Lass uns das abweisen. Nun, wir sollten diese Dateien idealerweise mit komplex sehen , lass mich aktualisieren. Und da hast du es. Sie können die Konflikte so lösen, wie Sie es möchten. In meinem Fall möchte ich nur beide Änderungen akzeptieren. Speichern Sie die Datei. Und dann drücke ich dieses Plus-Symbol, um diese Datei zu inszenieren. Und dann kann ich auf dieses Häkchensymbol klicken , um mit dem Rebase-Vorgang fortzufahren. Und die Nachricht, die hier standardmäßig aufgefüllt wird , ist die Nachricht der Kommentarfunktion, eines Zweigs, der den Konflikt tatsächlich erzeugt. Wir haben diesen Editor geöffnet. Aber ich lasse die Nachricht einfach so wie sie ist, schließe die Datei. Und damit sollte der Rebase-Vorgang abgeschlossen sein. Wie Sie sehen können, sind die ersten vier Commits außerhalb Master-Branches und die anderen beiden Kommentare gehören zum Feature-Branch. Jetzt können wir weitermachen und den Fast Forward March durchführen. Also wechsle ich zurück zum Master Branch. Rechtsklick auf dieses Commit. Und dann kann ich in aktuellen Zweig zusammenführen wählen. Also möchte ich Feature One Branch in den Master-Branch zusammenführen . Ich möchte kein neues Commit für die schnelle Vorwärtszusammenführung erstellen . So führen Sie also Rebase durch. Und wenn Sie bemerken, haben wir diese lineare Entwicklung, was wir von Rebase erwarten . Wir sehen uns als Nächstes. 47. 0503 Git Rebase in Git Bash Konflikte überspringen und die Rebase abbrechen: Okay, lass uns sehen, wie wir Git Rebase von Git Bash aus durchführen können . Momentan sind wir in Master Branch, um zu Feature One Branch zu wechseln , um diesen Befehl ausführen zu können. Übrigens haben wir das Projekt wieder so gebracht , wie es am Anfang unseres vorherigen Videos aussah . Damit wir Dinge wiederholen und sehen können wie es von Git Bash aus funktioniert. Ich werde zum Feature-Branch wechseln. Es kann gleichzeitig beobachten, was in diesem Diagramm passiert. Git rebase. Wo möchte ich rebasen, um ein Commit durchzuführen? Dieser Master-Zweig zeigt auf jemanden, der Meister sagt. Und wie Sie erwarten können, werden wir die Konflikte sehen. Lassen Sie uns weitermachen und sie auflösen. Meiner Meinung nach würde ich wieder nicht beide Änderungen akzeptieren, die Datei speichern und zu Git Bash zurückkehren, um diese Datei zu inszenieren, git add product dot TXT-Datei. Und dann müssen wir diesen Befehl ausführen. Git Rebase, Bindestrich, Bindestrich führen weiterhin das Rebasing durch. Und genau das werde ich tun. Sie haben auch die Möglichkeit zu überspringen. Wenn du diesen Befehl ausführst, überspringt Git einfach den Commit, der die Konflikte verursacht. Es ist so, als ob Sie den Feature-Branch zum Kommentieren, der die Konflikte verursacht, nicht erstellt haben Feature-Branch zum Kommentieren . Wenn Sie diesen Befehl ausführen, vielleicht nachdem Sie das Rebasing erfolgreich durchgeführt haben, möchten Sie möglicherweise alle diese Änderungen manuell erneut anwenden. Da wir den Komplex jedoch gelöst haben, müssen Sie diese Option nicht verwenden, sondern können gerne damit experimentieren. Sobald ich diesen Befehl ausgeführt habe. Auch hier wird es uns die Botschaft zeigen. Wir können es so lassen wie es ist. Oder wenn Sie es ändern möchten, können Sie es ändern. Lass uns schließen. Und wie Sie hier sehen können, haben wir unseren Feature-Branch mit dem Master-Branch neu basiert . Lassen Sie uns nun den Merge-Teil durchführen , den wir zurück zu Master Git Merge Feature One wechseln Master Git werden. Und wie Sie sehen können, stimmen beide Zweige überein. Wenn jetzt ein Bone von git log Befehl ist, werden Sie alle Commits, die in beiden Zweigen eingeführt wurden, linear sehen , was wir brauchen. Und übrigens eine gut funktionierende Rebase-Operation. Und aus irgendeinem Grund haben Sie beschlossen, es abzubrechen, dann können Sie diese Option verwenden, git rebase, hyphen, hyphen, die ich gekauft habe. Wir sehen uns als Nächstes. 48. 0504 Git Interaktive Rebase: Halten Sie das, lassen Sie uns über interaktives Rebase sprechen. Und zu diesem Zweck habe ich das Projekt 1 Sekunde auf das zurückgebracht , was es früher war. Bevor Sie den Rebase-Vorgang ausführen. Lassen Sie mich zu Feature One Branch wechseln und das Rebasing durchführen. Ich möchte mit der rechten Maustaste auf den neuesten Commit Off Master klicken und auf aktuellen Zweig in diesem Kommentar rebase klicken. Aber dieses Mal werde ich diese Option wählen, die blonde interaktive Rebase im neuen Terminal besagt . Dies entspricht dem Ausführen des Befehls git rebase mit der Option dash, dash interact to. Klicken wir auf Ja Rebase. Und dieses Mal öffnen wir den Texteditor. Hier siehst du die Liste der Inhaber von Commits, die Teil des Feature-Eins-Zweigs sind. Was interaktives Rebase uns ermöglichen würde, ist, dass wir tatsächlich viele Anpassungen vornehmen können tatsächlich viele Anpassungen vornehmen , die auf unsere Bedürfnisse zugeschnitten sind. Wenn du siehst, haben wir hier eine Reihe von Befehlen, die wir verwenden können, um Git mitzuteilen was wir mit den Commits machen wollen oder einen Zweig zeigen. Standardmäßig wird dieser Befehl pick verwendet, was bedeutet, dass wir dieses Komitee verwenden möchten. Das bedeutet im Wesentlichen, dass wir wollen, dass diese Kometen von Feature One Branch Kandidaten für die Rebase-Operation sind. Sie können diesen Befehl jedoch je nach Anforderung in einen anderen Befehl ändern . Zum Beispiel möchte ich vielleicht diesen Befehl reward verwenden, was bedeutet, dass Commit verwendet wird, aber die Commit-Nachricht hinzugefügt wurde. Im Wesentlichen können Sie diesen Befehl verwenden, wenn Sie die Nachricht in eine andere Nachricht ändern möchten , wenn Sie die Nachricht in eine andere . Lassen Sie uns, ich möchte die Botschaft dieses speziellen Ausschusses ändern . Und lass uns das machen. Ich möchte diesen Drop-Befehl verwenden. Um diesen speziellen Commit fallen zu lassen. Ich weiß, dass dieser Kommentar zu Konflikten führen wird weil wir die Produkt-Dot-TXT-Datei in diesem Commit bearbeitet haben. Also werde ich das fallen lassen. Ebenso haben Sie eine Reihe anderer Befehle , die Sie verwenden können. Sie können einfach die Beschreibung durchgehen und prüfen, ob sie Ihren Bedürfnissen entspricht. Speichern Sie die Datei und schließen Sie sie. Wir werden also eine weitere Aufforderung sehen, die uns auffordert, die Botschaft dieses Commits zu verketten. Wenn Sie sich an diesen speziellen Commit erinnern, hatten wir den Befehl reward verwendet. Das ist der Punkt, an dem ich diese Aufforderung erhalte , die Botschaft an etwas anderes zu ketten. Sie können das ändern , was Sie wollen. Sag natürlich nicht blah, blah, tippe etwas Sinnvolles. Ich möchte die Datei speichern und schließen. Also dieses Mal, wenn du bemerkst, dass wir nur fünf Commits haben. Weil wir einen der Commits im Feature-Branch gelöscht haben, in dem wir Änderungen an der Produktpunkt-TXT-Datei vorgenommen haben. Und auch für die andere Kommentarfunktion würde ein Zweig die Nachricht in bla, bla ändern. Versuchen Sie also, mit interaktivem Rebase zu experimentieren . Wir sehen uns als Nächstes. 49. 0505 Rebase auf bestimmte Commit oder auf einen anderen Funktionszweig: In diesem Video werden wir uns ansehen, wie wir uns auf ein bestimmtes Commit umstellen können . Wir müssen nicht unbedingt bis zur Spitze eines Zweigs rebasen. Wir können uns auch auf ein bestimmtes Commit stützen. Derzeit oder Feature One Branch basiert auf dem allerersten Commit des Master-Zweigs, aber ich kann es auf den zweiten Commit Off Master Branch rebasen . In Visual Studio Code muss ich zu diesem Zweig wechseln , den ich rebasen möchte. Ich wähle Feature One Branch. Sobald ich das getan habe, werde ich mit der rechten Maustaste auf den Commit klicken, wo ich das Feature One Branch zwei neu erstellen möchte . Und dann kann ich diese Option wählen, die besagt, dass aktuelle Zweig bei diesem Commit rebasen wird. Wenn Sie dasselbe von der Git Bash hier bis zum Fast-Twitch tun würden , um einen Zweig zu zeigen. Und dann sagst du git rebase. Und dann der hashCode des Commits, auf den Sie rebasen möchten. In diesem Fall wird es das zweite Commit des Master Branch sein . Ich werde die ersten paar Zeichen dieses Commits so kopieren . Geh zurück zu Git Bash, füge es hier ein. Und das sollte jetzt einen Zweig zu diesem Kommentar rebasen . Nun, dieses Diagramm sieht vielleicht nicht so offensichtlich aus. Aber wenn Sie bemerken, haben wir das Feature One Branch, das auf dem zweiten Commit Off Master Branch basiert . Diese beiden Commits , die zum Master-Branch gehörten , sind nicht Teil des Feature-Eins-Zweigs. Wie erwartet würde das Diagramm offensichtlicher aussehen, wenn wir im Master-Branch einen weiteren Kommentar abgeben würden. Also lass uns das ganz schnell machen. Ich wechsle zurück zum Master Branch. Ich füge einfach eine Codezeile hinzu, Produktdatei, und speichere die Datei. Gehen wir zurück und übernehmen diese Änderungen im Master-Branch mit der Nachricht. Wenn Sie jetzt zum Diagramm zurückkehren, haben wir einen Master-Zweig in Blau und einen Feature-Branch in Rot. Aber wenn Sie Feature-Branches bemerken , die jetzt auf dem zweiten Kommentar zum Master-Branch basieren, weil wir ihn darauf umbasiert haben. Und wir müssen nicht unbedingt immer auf den Master-Branch rebasen. Wir können auch am besten einen bestimmten Branch zu einem anderen Branch machen, der kein Master-Branch ist. Lass mich dir zeigen, was ich meine. Lassen Sie uns zunächst einen neuen Zweig erstellen. Aber dieses Mal werde ich das bei diesem speziellen Commit tun, anstatt einen Branch an der Spitze des Master-Branches zu erstellen . Und ja, wir können auch neue Branches erstellen , die auf einem bestimmten Commit basieren . Ich kann einfach mit der rechten Maustaste auf den Commit klicken, von dem aus ich einen Branch erstellen möchte. Und dann klicken Sie auf Create Branch, geben Sie den Namen der Filiale ein und alles ist gut. Aber mal sehen, wie wir das Gleiche von Git Bash aus machen können. Lassen Sie mich zum Beispiel zu master, git branch, wechseln zum Beispiel zu master, git branch, und dann zum Namen des Branches , der erstellt werden möchte. Nennen wir es Feature zwei. Und dann werden Sie angeben , dass dies basierend auf dem, was Sie diesen Zweig erstellen möchten, angezeigt wird. Ich werde die ersten Zeichen aus diesem Commit-Objekt kopieren . Geh zurück zu Git Bash, füge es hier ein. Wenn Sie diesen Befehl ausführen, müssen Sie eigentlich nicht wirklich zu Master-Marken wechseln. Sie können es von jedem anderen Branch aus ausführen. Wir haben jetzt also einen Zweig geschaffen, der auf diesem speziellen Kampf basiert. Und du kannst den Zweig hier sehen. Lassen Sie uns in diesem Zweig ein Commit machen. Lassen Sie mich dazu zu Feature Two Branch wechseln. Gehe zu vielleicht einer Produktakte. Das Produkt ändert sich von Funktion zu was auch immer. Speichern Sie die Datei. Und lassen Sie uns diese Änderungen in der Funktion auf Branch übertragen. Wenn Sie bemerken, stellt die erste Zeile das zu verzweigende Feature dar und basiert auf dem dritten Commit des Master-Branches. Das ist also FY21 be Hash , den wir zuvor eingegeben haben. Und dann steht diese rote Linie für den Master-Zweig, Grün für den Feature-Eins-Zweig. Wenn Sie möchten, dass dieses Diagramm offensichtlicher aussieht, lassen Sie uns einen Commit im Master-Branch vornehmen. Noch einmal. Lassen Sie uns diese Änderungen mit der Nachricht übernehmen. Wenn Sie zum Diagramm zurückkehren, sehen Sie, dass wir den Master-Branch haben, Feature-Branch von Feature One Branch, der auf dem zweiten Commit basiert , und Feature Two Branch, der auf dem dritten basiert Kommentar. Lassen Sie uns nun weitermachen und das beste Feature einen Zweig bis zur Spitze des zu verzweigenden Features lesen . Wechseln wir zunächst zu Feature One Branch. Und dann klicke ich mit der rechten Maustaste auf diesen Commit. Rebase den aktuellen Zweig in diesem Ausschuss. Wir haben einen Konflikt. Lassen Sie uns diese schnell lösen. Übernehmen Sie beide Änderungen, die die Datei gespeichert haben, bleibt die Datei. Und dann engagiert. Dies sollte einen Editor öffnen. Schließ es einfach. Und das würde den Rebase-Vorgang beenden. Auch hier sieht das Diagramm möglicherweise nicht so aus , dass offensichtlich noch ein Kommentar abgegeben wird. Im Master-Zweig. Ich wechsle zurück zum Master Branch, gehe zum Produkt dot TXT und füge einfach eine weitere Codezeile hinzu. Ich verwende den gleichen Text wie die Commit-Nachricht. Und lassen Sie uns zu diesem Zeitpunkt festschreiben, wenn Sie bemerken, dass die erste Zeile den Master-Branch darstellt. Aber der Punkt hier ist, dass wir Feature einen Zweig an der Spitze des Features zu verzweigen rebasen konnten . Diese beiden Commits gehörten also zu Pitcher One Branch, der nur auf zwei Branches umbasiert wird . Wenn Sie möchten, können Sie jetzt einfach diese beiden Zweige zusammenführen und diese beiden Zweige zusammenführen und einen von ihnen löschen oder was auch immer tun. Wenn Sie dasselbe von Git Bash aus tun möchten , wechseln Sie einfach zurück zu Feature One Branch, git rebase, Feature zwei. Und dies sollte Ihr Feature auf Zweig an der Spitze des zu verzweigenden Features rebasen . Da wir das bereits gemacht haben, muss ich diesen Befehl nicht ausführen. Aber ich hoffe du hast den Punkt verstanden. Experimentieren Sie also damit, spielen Sie mit allem, was ich gerade besprochen habe. Wenn Sie nicht üben, würde alles nach Ländern aussehen und dann würden Sie anfangen, frustriert zu werden. Wir sehen uns als Nächstes. 50. 0506 Wann du Rebase verwendest, und wann du usecases versenden verwendest.: Also rebase oder merge. Lass uns darüber reden. Stellen Sie sich vor, dies ist der aktuelle Stand Ihres Projekts. Sie haben einen Feature-Branch-Out oder den allerersten Commit auf dem Master-Branch erstellt . Und dann haben Sie nach der Erstellung des Feature-Branches eine Reihe von Commits im Master-Branch vorgenommen . Nehmen wir nun an, dass Sie aus irgendeinem Grund feststellen, dass Sie zu früh sind, um diesen Zweig zu erstellen. Vielleicht brauchten Sie einige der Änderungen, die im Master-Branch eingeführt wurden, nachdem Sie den Feature-Branch erstellt hatten. Ratet mal was? Sie können den Feature-Branch einfach auf einen bestimmten Commit umbasen , der danach erfolgte, sodass Sie all diese Änderungen im Master-Branch haben, die im Feature-Branch verfügbar wären. Dies ist ein Anwendungsfall , in dem Sie möglicherweise Rebase über eine Zusammenführung verwenden möchten . Ein weiterer Anwendungsfall aus Rebase. Nehmen wir an, Sie haben ein paar Zweige erstellt , wie Sie sie hier sehen. Nehmen wir an, Sie haben erkannt, dass diese beiden Zweige nicht in zwei verschiedenen Zweigen befinden sollten. Sie befassen sich möglicherweise mit demselben Problem oder gehören zu derselben Funktion. Vielleicht möchten Sie sie als Teil einer einzelnen Filiale haben . Ratet mal was? Sie können einfach einen der Zweige mit dem anderen rebasen Zweige mit dem anderen rebasen , und schon kann es losgehen. Es gibt jedoch bestimmte Szenarien in denen Rebus nicht die beste Option ist. Rebase Sie ändern und schreiben die gute Geschichte neu. Bei jedem Rebasing schreiben Sie die Comment-Objekte neu, die auf ein anderes übergeordnetes Objekt verweisen. Das ist bei vielem nicht der Fall. Sie behalten den Commit-Verlauf und verlassen die Zusammenführung. Und das ist ein Grund, warum Sie Rebase vermeiden sollten. Wenn mehrere Entwickler an einem einzigen Branch arbeiten. Stellen Sie sich zum Beispiel vor, wir haben ein stumpfes und langweiligeres B2, und dann haben wir auch das zentrale Repository. Und das ist die aktuelle Projektstruktur. An all diesen Orten haben wir den Master-Zweig mit ein paar Kommentaren und Feature-Branch mit einem einzigen Commit. Nehmen wir an, der Dollar pro Eins wurde auf ein anderes Commit umgestellt. Es wird sich nicht im gesamten anderen System widerspiegeln. Zum Beispiel alle anderen Entwickler und sogar im zentralen Repository. es kurz zu machen, dies wird viele Inkonsistenzen erzeugen und könnte den eigentlichen Zweck zerstören, warum wir Rebasing haben, nämlich einen sauberen Commit-Verlauf zu haben. Denken Sie als Faustregel daran, wenn Sie der einzige sind, der an einem bestimmten Branch, einem Feature-Branch, arbeitet . Nehmen wir an, wir können Rebase verwenden bevor wir diesen Code tatsächlich pushen in das zentrale Repository. Wenn mehrere Entwickler beteiligt sind und alle zur gleichen Branche beitragen. Dann fusioniert Option für Sie In diesem Fall. Wir sehen uns als Nächstes. 51. 0601 Was ist Stashing Es ist usecases Beispiel für Stashing: Lass uns über das Verstauen sprechen. Lassen Sie uns gerade an Änderungen im Zusammenhang mit Feature 1 arbeiten . Und so bin ich derzeit in der Feature-Eins-Branche. Jetzt, während ich noch daran arbeite, kommt mein Chef an meinen Schreibtisch und bittet mich, weiter an Feature zwei zu arbeiten und es zuerst zu liefern , bevor ich an Feature eins arbeite Vielleicht ist dieser Kunde eifrig warte auch auf Feature. In der Hoffnung auf eine Bewertung könnte ich jetzt meinem Chef Ja sagen und ich möchte nicht auch mit der Arbeit an Features beginnen. Aber was ist, wenn ich in Feature 1 einige nicht festgeschriebene Änderungen habe? Lassen Sie mich tatsächlich einige Änderungen an einer dieser Dateien vornehmen. Als ob ich einige Änderungen in Bezug auf Feature eins einführen würde. Ich füge einfach eine Textzeile hinzu, speichere die Datei und schließe sie. Lass mich zurück zu Git Bash gehen. Daher haben wir einige Änderungen für Feature eins eingeführt. Und dann wollte ich jetzt an Feature arbeiten , damit ich zu Feature zu Branch wechseln kann. Also bin ich gerade in der Funktion, um zu verzweigen. Nun, wenn ich diese Datei admin dot TXT öffne, würden Sie die Änderungen sehen , die ich gerade eingeführt habe? Lassen Sie uns einen Blick darauf werfen. Sie sehen immer noch diese Änderungen. liegt daran, dass zwischen Branches all diese nicht festgeschriebenen Änderungen mit Ihnen führt . Dies sind die Änderungen, die sich auf Feature eins beziehen. Und ich kann es auch nach dem Wechsel zu Feature zwei sehen . Warum ist das ein Problem? Nun, wenn Sie an Funktionen für verwandte Änderungen arbeiten, kann dies tatsächlich zu großer Verwirrung führen, insbesondere wenn Sie versuchen, insbesondere wenn Sie versuchen all diese Dateien im Zusammenhang mit Feature 2 in Szene zu setzen. Möglicherweise stoßen Sie auf Änderungen in Bezug auf die erste Funktion und verwirren sich möglicherweise selbst. Was ist also die Lösung hier? Eine Lösung besteht offensichtlich darin, Änderungen im Zusammenhang mit Feature 1 zu übernehmen bevor Sie zu Feature Two Branch wechseln. Aber das ist keine Lösung, da wir auch mit den Änderungen an Feature 1 noch nicht fertig sind. Nun, wie wäre es, wenn wir die Funktion haben, die es uns ermöglicht , all unsere nicht festgeschriebenen Änderungen vorübergehend irgendwo im Projektarchiv zu speichern . Und dann könnten wir sie abrufen, wann immer wir wollen. Das ist genau das, was sich in Git versteckt. Ich bin derzeit in einer zukünftigen Filiale. Bevor ich also zu Feature zwei wechsle und mit der Arbeit daran beginne, möchte ich all unsere nicht festgeschriebenen Änderungen speichern. Der Befehl dafür ist gut. Versteck. Jetzt speichert dieser Befehl standardmäßig nur die verfolgten Dateien. Um eine von Git verfolgte Datei zu erstellen. Wie Sie vielleicht bereits wissen, müssen wir es mindestens einmal inszenieren. Wenn wir also eine brandneue Datei haben , die noch nie zuvor bereitgestellt wurde, können wir sie nicht speichern. Wenn Sie auch all diese nicht verfolgten Dateien speichern möchten, enthält Inuit eine Option. Enthält einen nicht verfolgten Bindestrich. Müssen diesen Befehl mit dieser Option ausführen , damit sowohl inszenierte als auch inszenierte Änderungen, selbst die neuen Dateien, die noch nie zuvor verfolgt wurden, gespeichert werden. Alternativ besteht die Abkürzung für diese Option einfach darin, den Bindestrich neu zu verwenden. Derzeit haben wir sowieso keine Dateien , die nicht verfolgt werden. Wir sehen also die Meldung Gespeichertes Arbeitsverzeichnis und Indexdatum. Wip steht für Working Progress auf Feature One Branch. Und es zeigt auf das letzte Commit von Feature One Branch, was bedeutet, dass dieser Befehl Änderungen gespeichert hat, die nach dem letzten Commit, diesem Branch, eingetreten sind. Wenn Sie nun die Admin-Punkt-TXT-Datei öffnen, Sie nicht mehr all diese Änderungen sehen da diese nur versteckt waren. Jetzt können wir zu Feature Two Branch wechseln. Und hier arbeite ich an Features zu verwandten Änderungen oder mache eine Menge Commits. Und wenn ich damit fertig bin, kann ich wieder zu Feature eins zurückkehren. Und ich kann all diese verstauten Änderungen mit dem Befehl git stash, pop abrufen . Führen wir diesen Befehl aus. Der gute Pop-Befehl. Nachdem alle nicht festgeschriebenen Änderungen wieder abgerufen wurden, werden diese Änderungen aus dem temporären Speicher gelöscht. Aber hinter den Kulissen hat es im Wesentlichen ein Commit-Objekt erstellt, und das ist der HashCode davon. Und dieses Commit-Objekt wird nicht Teil eines Branches sein. History ist nur ein temporäres Commit-Objekt, zusammen mit dem Snapshot nur zum Zweck des Versteckens erstellt wurde . Und wie Sie an dieser Zeile sehen können, wurde dieses Commit-Objekt gelöscht. Wenn Sie jetzt admin dot TXT öffnen, können Sie wieder all die Änderungen sehen , die zuvor gespeichert wurden. Es gibt noch andere Anwendungsfälle, in denen es versteckt wird und sich als nützlich erweisen könnte. Wir werden sie in unseren kommenden Vorlesungen exportieren . Wir sehen uns als Nächstes. 52. 0602 Anwenden des Stash über mehrere Zweige: Es kann eine Zeit oder einen Anwendungsfall geben, in dem Sie möglicherweise dieselben Änderungen über mehrere Zweige hinweg anwenden müssen . In diesem Fall erfüllt Git Stash Pop nicht den Zweck. Wenn Sie git stash verwenden, bewerben Sie sich für dasselbe. Lass mich dir zeigen, was ich meine. Ich bin derzeit in einer zukünftigen Filiale und wir haben bestimmte nicht festgeschriebene Änderungen. Lass mich zurück zu Git Bash gehen und all diese nicht festgeschriebenen Änderungen speichern. Also haben wir ein Backup davon erstellt und wir würden diese Änderungen nicht mehr sehen. Jetzt lass uns git, stash, bewerbe dich. Und mal sehen, was es bewirken wird. Wieder einmal hat good all diese nicht festgeschriebenen Änderungen aus dem temporären Speicher zurückgebracht . Aber dieses Mal wurden nicht all diese Änderungen aus dem temporären Speicher gelöscht , wie es bei Gas Off Git Stash Pop der Fall war. Das heißt, wir können diese Änderungen auch in einer anderen Branche anwenden . Aber lassen Sie mich vorher all diese Änderungen vornehmen. Nehmen wir an, ich bin mit allen Änderungen in Bezug auf Feature eins fertig . Stellen Sie diese Dateien zuerst bereit und übertragen Sie dann die Änderungen. Lassen Sie mich nun zu Feature zwei Branch Git Stash wechseln . Ich kann jetzt den Befehl apply ausführen , um all diese versteckten Änderungen zu übernehmen. Auch hier haben wir derzeit nicht all diese Änderungen in Zukunft für Branch. Aber nachdem ich diesen Befehl ausgeführt habe, werden Sie diese Änderungen hier sehen. 53. 0603 Abrufen eines bestimmten stash Stashes Umgang mit Konflikten: Lassen Sie uns sehen, wie wir uns eine Liste von Stashes ansehen und in der Lage sein können, einen bestimmten Stash abzurufen? Ja, das ist möglich. Lass mich dir zeigen, was ich meine. Um das besser zu erklären, habe ich das Projekt noch einmal auf das zurückgebracht, was es zu Beginn dieses Kapitels war. Wir haben also im Grunde überhaupt keine Vorräte. Ich bin in Feature-Eins-Zweig. Lassen Sie mich weitermachen und eine der Dateien bearbeiten. Lassen Sie mich einfach eine Textzeile hinzufügen, speichern Sie die Datei, schließen Sie sie, gehen Sie zurück zu Git Bash und lassen Sie uns diese Änderungen speichern. Geh zurück und öffne die Datei. Ich würde all diese Änderungen nicht mehr sehen , weil sie nur versteckt waren. Lassen Sie mich noch eine Textzeile hinzufügen, speichern Sie die Datei und schließen Sie sie. Lassen Sie mich auch diese Änderungen speichern. Jetzt haben wir ein paar Mal das Stashing durchgeführt, und das muss irgendwo im Projektarchiv beibehalten worden sein. Wie sehen wir es uns an? Der Befehl dafür ist git stash list. Dies würde auf der gesamten Liste der Stashes aufgeführt sein. Wir können einen bestimmten Stash abrufen, indem wir seine ID verwenden. Aber wenn Sie bemerken, ist die Nachricht hier nicht sehr beschreibend. Dies ist nur der letzte Commit On-Feature-Ein-Branch und wird auch für alle Stashes verwendet. Nun, im Laufe der Zeit, wenn deine Stashes vergrößert werden, könnte es schwierig sein zu identifizieren, ob Stash welche Änderungen hat? Glücklicherweise erlaubt uns Git, eine beschreibende Nachricht zu geben , während wir uns verstecken. Lassen Sie mich also eine andere Datei bearbeiten. Vielleicht erfunden oder TXT so. Und ich werde dasselbe auch für die Produktakte tun. Speichern Sie es und schließen Sie es. Also habe ich gerade Änderungen und ein paar Dateien vorgenommen. Lassen Sie mich diese Änderungen verbergen, aber dieses Mal werde ich eine beschreibende Botschaft geben. Speichern ist die Option, die wir verwenden müssen , und Sie werden eine Nachricht wie diese bereitstellen . Unsere Änderungen sind versteckt. Um einen Blick auf die Liste der Stashes zu werfen. Jetzt sehen Sie eine beschreibende Nachricht. Lassen Sie mich nun versuchen, diesen speziellen Vorrat wiederzugewinnen. Noch einmal können wir entweder Pop die Änderungen übernommen werden, die Änderungen. Lassen Sie mich die Änderungen übernehmen. Ich wollte die Idee der verstauähnlichen Zelle spezifizieren. Sie können sehen, dass die Änderungen abgerufen und angewendet wurden. In ähnlicher Weise können wir auch diesen speziellen Stash abrufen. Und wir werden diese Änderungen in der Admin-Punkt-TXT-Datei sehen . Aber lassen Sie uns sehen, was passieren würde, wenn ich diesen speziellen Stash abrufen würde, in dem wir genau dieselbe Datei bearbeitet haben. Bei dieser Operation sollte ich wirklich scheitern. Und tatsächlich haben wir einen Pfeil, der besagt, dass Ihre lokalen Änderungen an den folgenden Dateien durch Zusammenführen überschrieben werden. Bitte schreiben Sie fest, dass Ihre Änderungen vor dem Zusammenführen gespeichert werden. Im Grunde wird dieser Stash also auf die Änderungen reagieren, die mit unseren vorhandenen nicht festgeschriebenen Änderungen in Konflikt geraten könnten . Wofür ist also die Lösung? Die Lösung ist bereits hier verfügbar. Wir können all diese Änderungen festschreiben oder sie erneut speichern und dann diesen speziellen Stash abrufen. Oder alternativ können wir einfach den Befehl git restore dot verwenden , um alle nicht festgeschriebenen Änderungen zu löschen. Und auf diese Weise sollten wir in der Lage sein einen bestimmten Vorrat problemlos abzurufen. Aber dann haben wir auch alle Änderungen verloren. Wir werden tatsächlich darüber sprechen, wie wir beim Verstauen mit Konflikten umgehen können . Wenn wir über Git sprechen, ziehen Sie in späteren Kapiteln nach. Wir sehen uns als Nächstes. 54. 0604 Selektive Änderungen stashing und sie abrufen: Es ist nicht notwendig, dass wir alle Änderungen speichern müssen. Wir können uns auch dafür entscheiden, alle Änderungen, die wir speichern möchten, und Änderungen, die wir nicht verbergen möchten, zu wässern . Und für dieses Beispiel habe ich das Projekt noch einmal auf das zurückgebracht, was es zu Beginn dieses Kapitels war. Wir haben also im Moment keine Vorräte. Lassen Sie mich ein paar Dateien bearbeiten. So wie. Ich habe die Datei gespeichert. Aber dieses Mal sollten wir teilweise Änderungen verbergen. Dieses Mal verwende ich die Option Bindestrich P steht für teilweise. Und mal sehen, was es uns ermöglicht. Es hat uns eine Reihe von Optionen geboten. Wenn Sie nicht wissen, worum es bei diesen Optionen geht, können Sie einfach ein Fragezeichen eingeben und eine Beschreibung davon sehen. Im Grunde würde dieser Befehl Sie alle Änderungen, die wir vorgenommen haben, nacheinander auffordern . Anhand dieser Optionsliste können wir sagen, was mit diesen Änderungen geschehen soll . Derzeit zeigt es also diese spezielle Änderung, die zur Inventarpunkt-TXT-Datei gehört . Wenn wir y eingeben, wird das Stück verstaut. Sie können sich Hunk als eine Veränderung vorstellen , die hier vorgestellt wird. Das ist also eine neue Textzeile, die gerade hinzugefügt worden wäre. Wenn Sie N eingeben, bedeutet das, dass Sie es nicht als Teil des Speichers aufnehmen möchten. Das bedeutet, dass Sie diese Änderungen nicht speichern möchten . Q wie in witzelte, verstaue dieses Stück oder einen der verbleibenden nicht. Aber was sind all die Kerle, zu denen Sie vielleicht Ja gesagt haben könnten , was beim Beenden immer noch versteckt ist. Im Wesentlichen werden wir diesen Vorgang beenden gleichzeitig alle Änderungen speichern, zu denen wir hier Ja gesagt haben, würde bedeuten diesen Hunk und alle späteren Kerle in der Datei zu verstauen. In derselben Datei. D würde bedeuten, dass sie diesen Brocken oder einen der späteren Kerle in der Datei nicht versteckt haben, es ist entgegengesetzt zu Option a. Er würde bedeuten, den aktuellen Brocken manuell zu bearbeiten. Das würden wir niemals benutzen. Ich persönlich habe es nie benutzt. Ich denke nicht an einen Anwendungsfall, um das zu benutzen. Im Grunde genommen, wenn wir etwas bearbeiten wollen, würden wir es lieber tun, indem wir einen Baum entlang gehen und dann die Änderungen speichern. Nehmen wir an, ich möchte diese Änderungen verbergen. Also sage ich hier „y“. Dann werden wir mit dem zweiten Hunk aufgefordert , der zur Produktpunkt-TXT-Datei gehört. Und das sind die Änderungen. Nehmen wir an, ich möchte niemanden verstecken, der dazu n sagt. Lassen Sie uns git restore dot machen , um einfach unser Arbeitsverzeichnis zu bereinigen. Nennen wir es mit diesem Befehl. Wir löschen all diese nicht festgeschriebenen Änderungen. Lassen Sie mich versuchen, den Vorrat erneut aufzubringen. Dieser Befehl würde nur den neuesten Stash anwenden , den wir in der Liste haben. Aber bevor ich diesen Befehl ausführe, stellen wir sicher, dass unsere Änderungen verloren gehen. Wie Sie sehen können, sind unsere Änderungen nicht da. Aber sobald wir diesen Befehl ausgeführt haben, werden wir sehen, dass Änderungen in der Inventarpunkt-TXT-Datei angewendet werden. Weil dieses Stück versteckt war. Wo in der Produktpunkt-TXT-Datei sehen wir keine Änderungen. Wir sehen uns als Nächstes. 55. 0605 Erforschen im VS-Code Löschen eines Stash: Schauen wir uns nun an, wie wir Visual Studio Code speichern können . Und zu diesem Zweck habe ich das Projekt wieder auf das gebracht, was es am Anfang dieses Kapitels war. Und wir haben derzeit überhaupt keine Vorräte. Lassen Sie uns einige dieser Dateien bearbeiten. Kann eine Textzeile wie eine Admin-Punkt-TXT-Datei hinzufügen. Und lassen Sie mich dasselbe in der Inventarpunkt-TXT-Datei tun, die Datei gespeichert. Gehen wir zur Quellcodeverwaltung. Klicken Sie auf diese drei Punkte und Sie sehen die Option zum Ausführen von Stash. Hier finden Sie also eine Routine, die wir bisher in diesem Kapitel gelernt haben . Wir können Stash aufführen. Stash, der auch nicht verfolgte Dateien enthält. Wir können den neuesten Vorrat beantragen. Das ist so gut wie wir den Befehl git stash apply ausführen. Oder wir können diese Option wählen , die „Stash anwenden“ besagt. Und dann können wir den einen der gespeicherten Vorräte auswählen. Lass uns weitermachen und Stashing durchführen. Es fordert uns auf, eine Nachricht einzugeben, Center oder etwas anderes zu drücken, die Eingabetaste zu drücken. Das muss also gespeichert haben, wie sich Änderungen ändern. 1 Sekunde, lass uns zum Versteck gehen. Wir können auf Briefvorrat anwenden klicken, oder wir können diese Option wählen , die einen Plus-Vorrat enthält. Und dann können wir den Vorrat auswählen , den wir anwenden möchten. Derzeit haben wir nur einen Vorrat und sagen, dass er angezeigt wird. Wenn wir eine Liste von Stashes hätten, würden diese ebenfalls angezeigt. Lass mich darauf klicken. Und wie Sie sehen können, wurden die Änderungen vorerst in diesen beiden Dateien übernommen. Mal sehen, welche anderen Optionen wir haben. Wir haben auch die Möglichkeit , den neuesten Stash zu knallen, einen bestimmten Stash zu knallen. Oder wir können sogar diesen Dash fallen lassen oder alle Vorräte fallen lassen. Im Wesentlichen würde Drop bedeuten, einen Stash zu löschen. Dies ist vergleichbar mit dem Ausführen des Befehls git stash drop. Und dann geben Sie diese Dash ID an. Oder du kannst einfach Git Stash sagen, klar. Und das würde alle Stashes löschen. Wir können es entweder von hier aus tun oder wir können den Befehl auch ausführen. Lassen Sie mich den Befehl ausführen. Jetzt. Wenn ich eine Git-Stash-Liste mache, wirst du nichts sehen, weil wir gerade alles gelöscht haben. Aber so verwenden Sie Stashing in Visual Studio Code. Wir sehen uns als Nächstes. 56. 0701 Git Ignore und es ist wichtig (Crash-Kurs): Lassen Sie uns über Gitignore und seine Bedeutung sprechen. Es kann bestimmte Dateien geben, die Sie nicht übertragen möchten, oder Sie möchten nicht, dass sie anderen zum Herunterladen und Verwenden zur Verfügung stehen. Einige Beispiele für solche Dateien lauten wie folgt. Möglicherweise haben wir Protokolldateien, die während der Laufzeit generiert werden. Und natürlich wollen wir sie nicht festschreiben und sie in einem zentralen Repository für andere zum Herunterladen zur Verfügung stellen in einem zentralen Repository für andere zum Herunterladen zur Verfügung . In ähnlicher Weise haben wir möglicherweise Code wie Punktklassendateien oder Punkt-P-Y, C-Dateien usw. kompiliert . Oder Sie haben lokale Abhängigkeitsordner wie Node-Module für den Fall von Node-Projekten. Aber wir können diese Dateien ignorieren, indem wir sie einfach nicht inszenieren und nicht übertragen. Aber es kann Fälle geben, in denen Leute dazu neigen , versehentlich einige dieser Dateien zu übertragen, wodurch ein Chaos entsteht , das nicht beabsichtigt ist. Also gitignore-Datei ist dort praktisch. Gitignore-Datei können Sie bestimmte Muster angeben. Und alle Dateien und Ordner, die mit diesen Mustern übereinstimmen , würden für die Bereitstellung von Anpassungen ignoriert. Wenn Sie versuchen, die Dateien beizubehalten, die mit diesen in Punkt-Ignorieren-Datei angegebenen Mustern übereinstimmen , wird ein Fehler angezeigt. Schauen wir uns einige Beispiele für solche Muster an . Wenn Sie zum Beispiel Sternpunktprotokoll sagen, wird Stern als Platzhalterzeichen betrachtet. Das bedeutet, dass Sie jede Datei in Ihrem Repository oder Ihrem Projekt mit einem beliebigen Namen haben können. Solange es eine Punktlog-Erweiterung hat, werden diese Dateien ignoriert. Hier sind einige Beispiele für Dateien, die ignoriert würden, wenn Sie dieses Muster in der Datei doubt ignore angegeben haben . Wir haben dot log im Wurzelverzeichnis und dann info dot log unter logs-Ordner hinzugefügt . Beide Dateien würden ignoriert. Schauen wir uns noch ein Beispiel für ein Muster an. Wir haben Lungenschlitze. Wenn Sie einen Schrägstrich angeben, würde das ein Verzeichnis bedeuten. Dieses Muster würde im Wesentlichen den gesamten Inhalt ignorieren, einschließlich der Unterverzeichnisse aller Ordner mit den Namensprotokollen. Und hier sind einige Beispiele für Dateien, die mit diesem Muster ignoriert würden. Halte das Video an, nimm dir eine Sekunde und versuche das zu verstehen. Alle diese Dateien gehören zum Verzeichnis Logs. Und so würden all diese Dateien ignoriert. Wir können sie nicht inszenieren, und deshalb können wir nicht einmal zu ihnen kommen. Angenommen, Sie haben diese Projektstruktur. Normalerweise haben wir eine Punkt-Ignorieren-Datei , die in das Stammverzeichnis des Projekts verschoben wird. Es verhindert jedoch nicht, dass Sie auch Dateien in den Unterverzeichnissen ignorieren . Die Punkt-Ignorieren-Datei und ihre Muster werden auf den Ordner angewendet, in dem sie sich befindet, einschließlich ihrer Unterordner. Daher sind alle Muster in der Punkt-Ignorieren-Datei, die sich in einem Unterordner befindet der Punkt-Ignorieren-Datei, die sich in einem Unterordner befindet, nur auf einen Ordner anwendbar. Und all seine Unterverzeichnisse, einschließlich aller Dateien. Sie gilt jedoch nicht für den übergeordneten Ordner , der in diesem Fall mein App-Ordner ist. Es kann Fälle geben , in denen Musterkonflikte auftreten können . Zum Beispiel könnten wir ein Muster haben, das in diesen beiden Punkt-Ignorierdateien widersprüchlich sein könnte . In diesem Fall haben die Muster von Unter-Eins-Ordnern einen höheren Vorrang vor den Mustern in meinem App-Ordner. Wir werden uns als Nächstes ein Beispiel dafür ansehen. Und dadurch haben Sie eine bessere Klarheit. Wenn Sie Muster haben, die nicht für das gesamte Team gelten , sondern nur für Ihre lokale Registrierung gelten. Sie können den Massenteil der Ausschlussdatei angeben. Und die Tatsache, dass diese Datei zum dot git-Ordner gehört , bedeutet , dass dies nicht verschlechtert werden oder Sie diese Änderungen nicht übernehmen können. Und für alle Muster, die für das gesamte Team gelten , würde eine Punkt-Ignorieren-Datei ins Bild kommen und sie ist versioniert, was bedeutet, dass, sobald Sie eine Aktualisierung in der Punkt-Ignorieren-Datei vorgenommen haben, Sie würden sie übertragen und all diese Änderungen tatsächlich an das zentrale Repository übertragen, sodass alle anderen die Dart-Inore-Datei herunterladen. Und alle Dateimuster in dieser Datei würden für alle ignoriert. Somit wäre niemand in der Lage, all diese Dateien zu übertragen , die nicht dazu gedacht sind , im Team geteilt zu werden. Sie können auch globale Muster angeben, die in allen Projekten als Repositorys in Ihrer lokalen Registrierung gelten in allen Projekten . Sie können dies tun, indem Sie diesen Befehl ausführen , den Sie hier sehen. Dies würde im Wesentlichen eine zusätzliche Konfiguration in der Git-Konfigurationsdatei hinzufügen eine zusätzliche Konfiguration in , die sich im Benutzerverzeichnis befindet. Wir sehen uns als Nächstes. 57. 0702 Git Ignore in Aktion Globale config ausschließen: Sagen wir, git ignoriere eine Aktion. Was wir hier haben, ist unsere gute alte my-App-Anwendung mit einer Menge Dateien und vielleicht auch mit einigen Commits. Vergessen Sie alle Commits, die wir gemacht haben , und kümmern Sie sich einfach nicht um die darin enthaltenen Dateien. Konzentrieren wir uns einfach auf Gitignore. Stellen Sie sich nun vor, ich habe dieses Projekt aus dem zentralen Repository heruntergeladen und starte sogar die Anwendung. Wenn ich das mache, sehe ich möglicherweise , dass in Protokolldateien automatisch von der Anwendung generiert wird. Jetzt, da wir keine laufende Anwendung haben , lassen Sie uns das Verhalten simulieren indem wir die Protokolldateien manuell erstellen. Lassen Sie mich vielleicht eine der beiden Punktprotokolldateien erstellen. Hier wurde davon ausgegangen , dass diese Datei tatsächlich so ist , wie man sie von der Anwendung erstellt. Kann auch einen Ordner mit dem Namen info erstellen , in dem wir möglicherweise Protokolle haben. Lassen Sie mich also eine Datei mit dem Namen für Punktprotokoll erstellen . So wie. Wenn ich jetzt Git Bash starte, kann ich diese Dateien tatsächlich bereitstellen. Git fügt Punktprotokoll hinzu. Wie Sie sehen können, kann ich diese Datei inszenieren , was ich nicht tun möchte. Lassen Sie mich diese Datei also schnell auf die Bühne stellen. Wie verhindere ich nun, dass ich diese Protokolldateien versehentlich bereitstelle ? Nun, eine Lösung ist, dass Sie in die Dot Git-Ordnerinformationen gehen . Und dann haben wir diese Ausschlussdatei , in der Sie die Muster angeben können , die ignoriert werden sollen. Wir könnten also ein Mustersternpunktprotokoll angeben, und auf diese Weise können wir sie nicht inszenieren oder übertragen. Aber dieses Mal wollen wir diese Datei nicht verwenden. Kannst du erraten warum? Weil diese Protokolldateien nicht lokal für meine Registrierung sind. Sie gilt für alle Teammitglieder im Team. Jeder in meinem Team, der diese Projekte herunterlädt und die Anwendung ausführt, kann diese Protokolldateien sehen. Ich möchte auch nicht, dass sie diese Dateien und das zentrale Repository übertragen können . Nun, da kommt Gitignore ins Spiel. Lassen Sie mich eine Punkt-Gitignore-Datei erstellen, dot git. Ignorieren. Stellen Sie sicher, dass Sie den richtigen Namen erhalten. Öffnen wir die Datei und fügen dieses Mustersternpunktprotokoll hinzu. Das sollte also alle Protokolldateien in unserem Projekt ignorieren. Wenn ich jetzt zu Git Bash zurückkehre und versuche, diese Datei zu inszenieren, wird tatsächlich ein Fehler angezeigt der besagt , dass die folgenden Teile von einer Ihrer Punkt-Ignorierdateien ignoriert werden . Wenn ich diese Datei trotzdem hinzufügen möchte, kann ich diese Option Bindestrich F verwenden , um diese Datei vierstufig zu gestalten, die ignoriert werden sollte. Aber du willst das nicht tun, wenn du nicht weißt, was du tust. Wir können nicht einmal ein Punktprotokoll bereitstellen, das sich im Info-Ordner befindet. Wir bekommen den gleichen Fehler. Und wenn Sie Dateien haben, die Sie ignorieren möchten , und Sie möchten all diese Muster für alle Repositorys auf Ihrem lokalen Computer gelten . Dann möchten Sie die globale Ausschlussdatei mit dem Befehl git config global angeben . Und dann sagen Sie Core-Ausschlussdatei. Und hier würden Sie den Pfad angeben, die Punkt-Ignorieren-Datei. Sobald Sie diesen Befehl ausführen, wird die globale Git-Konfigurationsdatei aktualisiert. Das befindet sich im Verzeichnis Ihres Benutzers. Ich bringe dich tatsächlich hin. Derzeit gibt es nur die globalen Anmeldeinformationen , die ich für alle Repositorys in meiner lokalen Registrierung verwenden möchte . Nachdem Sie diesen Befehl ausgeführt haben, werden Sie jedoch feststellen, dass diese bestimmte Eigenschaft in dieser Datei gefüllt wird. Unabhängig davon, welche Datei sie ignorieren, auf die sie verweist, ihre Muster für alle Repositorys auf Ihrem lokalen Computer anwendbar . Im Allgemeinen möchten Sie die Muster angeben, die die Betriebssystemdateien relevant sind, wie Punkt-, DS-, Store- usw. und nicht projektbezogene Dateien. Da wir nichts haben, will ich es einfach nicht ausführen. Nachdem Sie die dot Git ignore Datei erstellt oder aktualisiert haben, möchten Sie diese Änderungen übernehmen und Ihre Änderungen sogar an das zentrale Repository übertragen, damit all diese Muster anwendbar für alle Leute in Ihrem Team. Wir werden in späteren Kapiteln darüber sprechen, wie Sie Ihre lokalen Commits in das Remote-Repository übertragen können. Aber jetzt kann ich weitermachen und in die Gitignore-Datei kommen. Git add, git, ignoriere Status, git commit, binde sie, was auch immer. Und wir sind in der Lage, diese Änderung zu begehen. Wir sehen uns als Nächstes. 58. 0703 Vorrangstelle übergeordnetes Pattern: Lassen Sie uns über Präzedenzfälle sprechen. Nehmen wir an, wir haben eine weitere Punkt-Gitignore-Datei in einem der Unterverzeichnisse. Lassen Sie mich diese Datei tatsächlich so in das Info-Verzeichnis kopieren . Aber statt dieses Musters möchte ich dieses Muster haben. Oder dieses Muster bedeutet, dass wir alle Dateien ignorieren möchten , die keine Punktprotokollerweiterung haben. Wenn Sie jetzt feststellen, dass wir einen Musterkonflikt haben. Im Root-Verzeichnis. Wir haben ein Muster, das besagt, dass wir alle Punktprotokolldateien ignorieren möchten. Aber während wir hier mit diesem Muster sagen, dass wir alle Dateien ignorieren wollen. Das ist keine Punktprotokolldatei. Welches Muster sollte folgen. Hier werden die Präzedenzfälle ins Spiel kommen. In diesem Fall würde dieses Muster dem Muster im übergeordneten Verzeichnis vorgezogen werden . Es funktioniert so, wenn Sie eine Datei wie info dot login haben , wird überprüft, ob sich im selben Verzeichnis, in dem sich diese Datei befindet, Punkt-Gitignore-Dateien befinden. Wenn ja, wird es versuchen, Muster zu finden, eine Übereinstimmung mit dieser Datei. Wenn es keine Muster gibt , die mit dieser Datei übereinstimmen, wird im übergeordneten Verzeichnis nach Mustern gesucht. Wenn es dort immer noch nicht gefunden wird, wird es versuchen, die Muster in der Exclude-Datei zu finden . Wenn dort auch keine Muster gefunden werden, stimmt das mit der jeweiligen Datei überein. Dann wird es hineingehen und die globale Ignorieren-Datei überprüfen. Wenn wir es konfiguriert hätten. Wenn es nirgendwo findet, können wir diese Datei bereitstellen. So würde ein Präzedenzfall entstehen. Wenn ich jetzt zu Git Bash gehe, schauen wir mal, ob wir das Info-Punkt-Log inszenieren können. Wie Sie sehen können, sind wir in der Tat in der Lage, Info-Punkt-Log zu inszenieren , weil das Muster in diesem Ordner, Verkäufe, dass wir diese Datei aufnehmen wollen und sie nicht ignorieren wollen. In den meisten Fällen, normalerweise in fast allen Projekten, hätten Sie jedoch normalerweise in fast allen Projekten, nur eine Punkt-Gitignore-Datei in das Stammverzeichnis verschoben wird. Aber ich teile das nur zu Ihrer Information. Ich sollte auch erwähnen , dass wir uns nicht auf ein paar Muster beschränken. Wir haben eine Reihe von Mustern , die wir verwenden können je nachdem, welche Dateien Sie ignorieren möchten. In den meisten Fällen ist dies normalerweise der Fall. Oder Sie geben am Ende einen solchen Ordner an. Alle Muster können Sie in der offiziellen Dokumentation nachlesen . Es gibt nicht viele. Kann einfach einen kurzen Blick darauf werfen und ein Gefühl für Gewicht bekommen , als Muster, die unterstützt werden. Es macht für mich keinen Sinn Sie durch jedes einzelne Muster zu führen und all Ihre Zeit in Anspruch zu nehmen. Lesen Sie einfach die Dokumentation und sie enthält alle Dinge, die Sie benötigen. Manchmal haben Sie vielleicht so viele ignorierte Dateien. Das macht es schwer zu verstehen, warum eine bestimmte Datei ignoriert wird. In diesem Fall haben wir einen Befehl zur Hand. Du sagtest Holen Sie sich, check. Ignore mit Bindestrich v Option steht für verbose. Und dann geben Sie den Namen der Datei an. Beispiel: Error dot loc. Und das wird drucken, warum diese Datei ignoriert wird. Wie Sie sehen können, haben wir Datei dot ignore im Stammverzeichnis. Und dieses Muster stimmt mit dieser Datei überein. Und deshalb wird es ignoriert. Dies kann sich als nützlich erweisen, insbesondere wenn Sie mehrere ignorierte Dateien haben oder sich nicht sicher sind , warum eine bestimmte Datei ignoriert wird. 59. 0704 Ignorieren von Dateien, die bereits begangen wurden: Was wäre, wenn wir bereits festgeschrieben hätten die Änderungen würden ignoriert werden? Lass mich dir zeigen, was ich meine. Zu diesem Zweck. Ich habe das Projekt wieder auf das gebracht , was es zu Beginn dieses Kapitels war. Wir haben wieder diese drei Dateien und beginnen von dort aus. Lassen Sie mich weitermachen und eine Protokolldatei erstellen. Nennen wir es error dot log. Lassen Sie mich diese Protokolldatei tatsächlich festschreiben. Als ob ich diese Datei versehentlich zusammen mit einer Reihe anderer Änderungen festschreiben würde. Git fügt error dot log, git, commit Typhon, eine Nachricht hinzu, und wir haben die Protokolldatei festgeschrieben. Stellen Sie sich jetzt vor, unser Projekt ist sehr neu, unser Team ist sehr neu. Niemand kennt die Punkt-Ignorieren-Datei. Nehmen wir an, wir haben eine Reihe von Dateien im Projektarchiv, die in dem zentralen Projektarchiv sind, die von einer Reihe von Leuten begangen werden sollten, ignoriert werden sollten. Jetzt ist es an diesem Punkt in der Zeit, dass ich eine Punkt-Gitignore-Datei in meinem Stammverzeichnis haben muss. Also werde ich es einbinden dot Git, ignoriere. Ich werde eine Reihe von Mustern spezifizieren, die ich ignorieren wollte. In meinem Fall sage ich einfach Sternpunkt mit. So wie. Lassen Sie mich diese Datei richtig umbenennen. Es soll gut sein. Ignoriere es so. Jetzt ist es schon zu spät, weil wir bereits alle Dateien festgeschrieben haben alle Dateien festgeschrieben , die nicht dabei sein sollen. Lassen Sie mich auch auf diese Datei eingehen. Git add, git, commit Typhon führe ignoriere Datei ein. Jetzt habe ich diese Datei vorgestellt, was großartig ist. Und das ignoriert jetzt alle Dateien, die ignoriert werden sollen. Aber wie wäre es mit all den Dateien , die bereits festgeschrieben wurden? Wie werden wir sie los? Nun, eine einfache Lösung besteht darin einfach all diese Dateien zu lokalisieren, sie zu löschen und dann einen Commit durchzuführen. All diese Dateien werden gelöscht. Und ab jetzt haben wir die Punkt-Gitignore-Datei, um das zu verhindern. Aber praktisch gesagt, wenn Sie viele Dateien haben, ist es wirklich unpraktisch, alle Dateien zu lokalisieren , die Sie entfernen wollten. Haben wir eine bessere Lösung? Die Antwort lautet ja. Wir haben eine hinterhältige Arbeit, um dieses Problem effektiver zu lösen. Lass mich dir zeigen, was ich meine. Ich gehe zurück zu Git Bash. Lass mich den Bildschirm räumen. Lass mich den Git-Status machen, um sicherzustellen, dass alles sauber ist. Lassen Sie mich jetzt den Befehl ausführen. Git RM, Bindestrich r steht für rekursiv. Und dann verwende ich die Option cached, gefolgt von einem Punkt. Was versuche ich hier zu tun? Ich versuche eigentlich, alle zwischengespeicherten Dateien zu löschen. Nun, im Wasser zwischengespeicherte Dateien, könnten Sie mich fragen, nun, zwischengespeicherte Dateien sind im Wesentlichen die Dateien, die von Git verfolgt werden. Git speichert alle Dateien, die es verfolgen möchte, in einem Cache. Und mit diesem Befehl räumen wir sie auf. Dies vermittelt den Eindruck , dass wir tatsächlich alle Dateien gelöscht haben , ohne tatsächlich aus dem Arbeitsverzeichnis löschen zu müssen. Lassen Sie uns diesen Befehl ausführen und sehen, was passiert. Und wie Sie sehen können , wurden all diese Dateien aus dem Cache entfernt. Das schließt also buchstäblich alle Dateien in unserem Arbeitsverzeichnis ein. Wie Sie sehen können, haben wir hier fünf Dateien. Und wir haben fünf Akten hier. Als Nächstes werden wir tatsächlich alle Dateien inszenieren und erkennen , was passieren wird. Aber vorher möchte ich den Befehl git status noch einmal ausführen. Und dieses Mal, wenn Sie im Abschnitt Änderungen, die übernommen werden sollen, feststellen , dass alle diese fünf Dateien aufgelistet wurden. liegt daran, dass wir denken, dass wir all diese Dateien tatsächlich gelöscht haben. Obwohl wir sie nicht aus dem Arbeitsverzeichnis gelöscht haben . Wir haben gerade den Cache geleert und sind uns sicher, dass wir diese Dateien tatsächlich zur gleichen Zeit gelöscht haben. Im Abschnitt Nicht verfolgte Dateien wurden alle Dateien aufgelistet , die derzeit nicht verfolgt werden. Machen Sie sich jetzt eine Notiz. Diese Liste enthält kein Fehlerpunktprotokoll da es jetzt Teil des Musters in der Punkt-Gitignore-Datei ist. Git will es nicht verfolgen. Lassen Sie uns nun all diese nicht verfolgten Dateien hinzufügen und sie von Git verfolgen. Git füge diesen Begriff hinzu. Ich werde Periodenzeichen verwenden , damit sogar die Dateien, die mit Punkt beginnen , hinzugefügt und von Git verfolgt werden. Wenn ich jetzt den Git-Status mache, wirst du sehen, dass error dot log die einzige Datei ist, in die wir kommen müssen. Es ist, als hätten wir diese Datei gelöscht und einen Kommentar abgegeben. Im Wesentlichen können wir damit alle Dateien löschen, die nicht festgeschrieben werden sollen, sind die Dateien, die ignoriert werden sollen. Jetzt, da wir diesen Stapel zum Löschen bereitgestellt haben, müssen wir noch eine letzte Sache tun, die Änderungen zu übernehmen. Aufräumen ignorierte fünf, es ist wie eine Zelle. Und get hat bei einem Punktprotokoll gelöscht. Würde einfach bedeuten, dass der neue Snapshot diese Datei nicht mehr hat. Aber natürlich haben wir es immer noch im Arbeitsverzeichnis. Das ist also nur eine hinterhältige Arbeit, um all die Dateien loszuwerden , die wir zuvor kommentiert hatten und die ignoriert werden sollen. Wenn Sie sich immer noch nicht sicher sind, nehmen Sie sich Zeit und experimentieren Sie mit diesen Befehlen, und Sie werden sie verstehen. Wir sehen uns als Nächstes. 60. 0705 Generieren der Ignorieren von Dateien für dein Projekt: Wenn Sie die Punkt-Gitignore-Datei in Ihr Projekt einführen , müssen Sie nicht wirklich überlegen welche Muster Sie in dieser Datei behalten möchten. Sie können einfach eines der vorhandenen Tools mit einem schnellen Git-Ignorieren-Generator für die Google-Suche verwenden der vorhandenen Tools mit . Ich bin auf diesen Link gestoßen. Es hat al.com gestoppt. Möglicherweise sehen Sie eine andere Website, aber sie generieren je nach Art des Projekts, das Sie erstellen, die gleichen Muster für Sie. Nehmen wir zum Beispiel an, ich erstelle eine Android-Anwendung. Also tippe ich einfach Android ein und klicke auf Erstellen. Und es hat mir eine Liste von Mustern zur Verfügung gestellt, die ich als Teil meiner Projekte dot gitignore-Datei hinzufügen kann. Wir sind bereits mit den meisten dieser Muster vertraut. Alle Zeilen mit Hash würden Kommentare bedeuten. Hier versuchen wir, das DOD Gradle-Verzeichnis zu ignorieren. Hier versuchen wir das Build-Verzeichnis zu ignorieren. Daher würden der gesamte Inhalt, alle Dateien sowie die alle Dateien sowie die Unterverzeichnisse für die Inszenierung ignoriert. Hier versuchen wir, die lokale Punkteigenschaftendatei zu ignorieren . Star Dot Log würde bedeuten, dass wir alle Protokolldateien ignorieren wollen. Und wir haben bereits ein Beispiel dafür gesehen. In ähnlicher Weise haben wir eine Reihe anderer Muster. Versuchen wir, Node einzugeben. Und mal sehen, was es generieren wird. Wieder einmal haben wir eine Reihe von Mustern, denen Sie vielleicht einen neuen Knoten hinzufügen möchten . JS-Projekt hat eine Zuweisung. Kopieren Sie einfach eine dieser Dateien und versuchen Sie mit diesen Mustern zu experimentieren und sehen Sie, welche Dateien ignoriert werden, und steuern Sie alle Dateien, die nicht ignoriert werden. Wir sehen uns als Nächstes. 61. 0801 Warum GitHub GitHub vs Bit Bucket vs GitLab: Okay, jetzt ist es an der Zeit, über GitHub zu sprechen. Wir haben das schon zu Beginn des Kurses angesprochen . Aber versuchen wir es noch einmal zu wiederholen und zu verstehen dass ein zentralisierter Code-Hosting-Dienst wie GitHub erforderlich ist. Wenn du der einzige bist, der an dem Projekt arbeitet, brauchst du so etwas wie GitHub nicht. Sie können einfach mit Git davonkommen, das lokal installiert ist , um die Versionen Ihres Projekts zu verwalten. Ihr Projekt jedoch größer wird, möchten Sie möglicherweise zusätzliche Personen einstellen , die zu Ihrem Projekt beitragen können. Obwohl nur ein oder zwei Personen, können Sie problemlos verwalten ohne einen Dienst wie GitHub verwenden zu müssen. Dutzende und Hunderte von Mitarbeitern , die vielleicht zu Ihrem Projekt beitragen möchten, dann brauchen Sie sicherlich eine bessere Möglichkeit, Ihren Code und seinen Versionsverlauf zu verwalten . Und hier würde GitHub ins Spiel kommen. Und GitHub verhält sich wie ein zentralisiertes Code-Repository , in das jeder seinen Code einbringt. Im Wesentlichen machen sie eine Menge Commits in ihrem lokalen Git und laden dann all diese Änderungen hoch oder übertragen sie in das zentrale Repository. Und dann könnten alle anderen alle Änderungen herunterladen, die von anderen Teammitgliedern eingeführt wurden. Angenommen, jeder hätte im Grunde eine Kopie des gesamten Projekts auf dem lokalen Computer. Wir haben auch eine Kopie des Projekts im zentralen Repository wie GitHub zusammen mit seinem Versionsverlauf. Und das ist, was ich bekomme, ist ein verteiltes Versionskontrollsystem. Get geht es jedoch nicht nur darum, Ihren Code hosten oder den Versionsverlauf verwalten zu können . Es bietet viele andere Funktionen , die für eine Organisation sehr nützlich sind. Zum Beispiel die Möglichkeit, Teammitglieder dahingehend zu verwalten , wer was tun kann. sind in der Lage, die von einem der Teammitglieder eingeführten Änderungen zu überprüfen , bevor sie in den Mainstream der Entwicklung aufgenommen werden. Sie können so ziemlich alles tun, was Sie in Ihrer lokalen guten Software tun können, wie den Code festschreiben , Zweige erstellen usw. Es bietet Ihnen auch die Möglichkeit, die Arbeit einer Person zu kommentieren. Wir können Dinge auch über die Community usw. diskutieren. GitHub ist jetzt nicht die einzige Option für uns. Wir haben auch andere Spieler dem Markt, die genau den gleichen Zweck gesehen haben. Welches Sie verwenden möchten, hängt ganz von Ihren Anforderungen ab. Wenn deine Organisation Atlassian-Ökosystemprojekte wie Jira, Bamboo usw. verwendet, ist Atlassian-Ökosystemprojekte wie Jira, Bamboo usw. verwendet, Bitbucket möglicherweise für dich sinnvoll , da es besser in diese Tools integriert werden kann. Und unter all diesen dreien ist git lab Open Source. Die anderen beiden haben sowohl kostenlose als auch kostenpflichtige Stufen. Und get lab und Bitbucket hat eine bessere Unterstützung für die kontinuierliche Integration, was ein Konzept von DevOps ist, das in meinem DevOps-Kurs besprochen wurde. GitHub ist jedoch der älteste unter diesen dreien. Es gibt Millionen von Projekten , die auf GitHub angewiesen sind, und es gibt Millionen und Abermillionen von Entwicklern auf der ganzen Welt, die GitHub aktiv nutzen. Github hat eine großartige Community und ist auch die beste Wahl für Open-Source-Projekte. Die Benutzeroberfläche ist ebenfalls recht minimalistisch, aber mit Kosten verbunden. Es hat nicht die integrierte Unterstützung für eine kontinuierliche Integration wie GitLab und Bitbucket. Aber es ist okay, dafür können Sie einige Tools von Drittanbietern verwenden . Es spielt jedoch keine Rolle, welches dieser Tools Sie lernen werden. Sie haben letztendlich das gleiche Ziel: Ihr Projekt zu verwalten. Sie können sich in Bezug auf die Benutzeroberfläche und die verwendeten Terminologien unterscheiden . Aber sonst haben sie alle den gleichen Zweck. 62. 0802 Creatig GitHub Konto: Okay, lass uns sehen, wie wir ein GitHub-Konto erstellen und sogar ein paar Repositorys erstellen können . Zu diesem Zweck habe ich tatsächlich ein gefälschtes Gmail-Konto erstellt, das unter Corp 96 bei gmail.com steht. Als ob dieses Unternehmen 1996 gegründet wurde oder WhatsApp. Jetzt wird cylinder als Freelancer ein GitHub-Konto für seine eigene Organisation erstellen , damit alle anderen und sein Team jetzt anfangen können zu dem Projekt auf GitHub beizutragen. Klicken wir auf Anmelden. Eigentlich sind die Anweisungen ziemlich einfach. Ich muss dir das nicht wirklich erklären, aber ich mache das nur als Formalität. Es fordert uns also auf, die E-Mail-Adresse einzugeben. Ich mache nur dieses Passwort. Ich habe es schon griffbereit. Also füge ich es einfach ein. Der Benutzername wird dort sein Corp. 96. Und steh auf sagt, dass das nicht verfügbar ist. Also müssen wir das in etwas anderes ändern, vielleicht 1996, jetzt ist es verfügbar. Lass uns weitermachen. Es fragt uns, ob wir die Updates und Ankündigungen per E-Mail erhalten möchten , ich würde vorerst nein sagen. Wenn Sie möchten, können Sie sich dafür entscheiden. Weiter. Es fordert uns auf, ein Rätsel zu lösen, um sicherzustellen , dass wir kein Bot sind. Ich muss mich nur für diese Spiralgalaxie entscheiden. In meinem Fall. Ich werde genau das tun. Ich habe dort hervorragende Arbeit geleistet, sodass ich das Konto erstellen kann. Wir haben diese E-Mail mit dem Code erhalten, ich nur kopieren und hier einfügen muss. Und wir sind fertig mit der Erstellung eines GitHub-Kontos. Ziemlich viel. Ich wollte diesen Schritt einfach überspringen. Wenn Sie möchten, können Sie wählen, wie viele Teammitglieder Sie haben und ob Sie Schüler oder Lehrer sind. Aber ich werde es vorerst einfach überspringen . Und wir sind fertig. Auf den ersten Blick dieser Willkommensseite, die Sie einmal sehen , nachdem Sie sich zum ersten Mal angemeldet haben, gibt uns get up bereits Vorschläge, was wir als nächstes tun können. Wir können ein Repository erstellen oder ein bestehendes importieren. Wir können eine Readme-Datei in unser Projekt einführen. Wir können sogar die Optionen prüfen , um einige der bestehenden Projekte beizutragen, über die wir zu einem späteren Zeitpunkt des Kurses sprechen werden. Und es gibt noch eine Menge anderer Dinge, die Sie sich einfach ansehen und ein Gefühl dafür bekommen können sich einfach ansehen und ein Gefühl dafür bekommen , worum es bei ihnen geht. Sie müssen nicht zu tief gehen, da wir in den kommenden Vorlesungen alles untersuchen werden . 63. 0803 Öffentliche und private Repositorien in GitHub erstellen und verstehen: Okay, mal sehen, wie wir GitHub-Repositorys erstellen können. Wir können das wichtige vorhandene Repository hinzufügen. Ich erstelle ein neues. Und genau das werde ich tun. Hier. Du wirst den Namen des Besitzers sehen. In diesem Fall haben wir nur einen Besitzer. Und das ist es, was standardmäßig gewählt wird. Hier müssen Sie den Namen des Repositorys angeben, den Namen des Repositorys , das Sie erstellen möchten. Jetzt müssen wir uns entscheiden, ob Sie das Projekt öffentlich oder privat machen wollen. Wenn Sie ein Open-Source-Projekt initiieren möchten, kann es für Sie sinnvoll sein hier die öffentliche Option zu wählen. Oder wenn Sie eine Organisation sind, in Ihre Software oder die Anwendung proprietär ist und Sie einen Kunden haben , für den Sie arbeiten, dann ist es möglicherweise sinnvoller eine private Endlager. Wenn es sich um ein öffentliches Repository handelt, kann jeder auf der ganzen Welt kann jeder auf der ganzen Welt den Inhalt Ihres Projekts anzeigen , Ihr Projekt herunterladen, es klonen usw. Wenn das Repository privat ist, können Sie wählen, wer tun kann was Sie zu dem Projekt beitragen können, wer das Projekt anzeigen kann usw. Ich werde die Erstellung von beiden demonstrieren. Das Repository geht davon aus, dass ich ein Open-Source-Projekt erstelle. Lass mich meine App als meine öffentliche App oder was auch immer bezeichnen. Wenn du möchtest. Sie können diese Namen auch durch einen Bindestrich trennen. Sie können kein Leerraumzeichen haben. Wenn Sie Leerzeichen verwenden, würde get automatisch ein Bindestrich annehmen, wie es vorschlägt. Übrigens könnte ich das Wort Git und GitHub je nach Kontext synonym verwenden . Das ist also der Name der App, die ich gegeben habe. Ich kann auch eine kurze Beschreibung über das Projekt schreiben, meine öffentliche App, was auch immer. Und dann steh auf. Es zeigt uns Optionen, einige dieser Dateien einzubeziehen, wie die ReadMe-Datei, die einige Details über das Projekt enthalten würde. Die Punkt-Ignorier-Datei, im Wesentlichen unabhängig von den Dateimustern Sie in diese Datei aufnehmen, würde ignoriert, um festgeschrieben zu werden. Dann können wir auch die Lizenzdatei auswählen. Es gibt bestimmte vordefinierte Lizenzen , die wir auf Wunsch verwenden können. Wenn Sie beispielsweise ein Open-Source-Projekt erstellen, eine GPU oder eine allgemeine öffentliche Lizenz Sie sinnvoll sein. Im Moment werde ich keine davon auswählen, da wir sie später hinzufügen können. Wenn Sie sich jedoch für eine dieser Dateien entscheiden, erstellt get automatisch einen Commit unserem Namen, der diese Dateien festschreibt. Es ist deine Entscheidung. Du kannst es wählen oder nicht. Beide sind ziemlich gleich. Wir werden sie sowieso in den kommenden Vorlesungen hinzufügen. Das wird also einfach ein öffentliches Repository erstellen. Klicken wir auf Create Repository. Und GitHub bietet einige nächste Schritte, über die Sie sich keine Gedanken machen müssen , da wir sie in den kommenden Vorlesungen sowieso untersuchen werden . Aber wenn Sie hierher zurückkehren, können Sie sehen, dass unser Repository hier aufgelistet ist. Wenn Sie den Link kopieren, würde der Link in etwa so aussehen. Du hast GitHub.com und dann den Benutzernamen Schrägstrich, den Namen des Repositorys. Und so könnte jeder auf Ihr öffentliches Repository zugreifen. Jetzt kann jeder auf der ganzen Welt auf diesen Link klicken, um Watsons Projekt sehen zu können , da es öffentlich ist. Erstellen wir jetzt auch ein privates Repository. Sie klicken auf einen neuen Namen des Repositorys wird sagen, Bank-App, was auch immer. meiner Bankanwendung wähle ich die Option privat, damit nur die Personen , denen ich Zugriff gebe , das Projekt sehen und dazu beitragen können. Ich spreche eigentlich von Mitarbeitern, die wir bald untersuchen werden. Dieses Mal. Lass mich vielleicht eine dieser Dateien aussuchen. Vielleicht möchte ich eine Lizenzdatei hinzufügen. Zum Beispiel. Dies kann wahrscheinlich keine allgemeine öffentliche Lizenz sein. Aber du kannst einfach alles gebrauchen. Sie müssen es nicht wirklich ernst meinen, es sei denn, Sie sind eine echte Organisation, die sich Sorgen um die Lizenzierung macht. Ich wähle einfach etwas Zufälliges aus und erstelle ein Repository. Dieses Mal hat Github eine Verpflichtung für uns gemacht. Und darin hat sich verpflichtet, die Lizenzdatei festgeschrieben zu haben. Sie können auf diese Datei klicken, um einen Blick auf ihren Inhalt zu werfen. Sie können dies ändern, wenn Sie möchten, und ein weiteres Commit vornehmen. Aber all das werden wir in den kommenden Vorlesungen untersuchen. Kehren wir zur Homepage zurück. Und jetzt können Sie diese beiden Repositorys sehen. Da es sich um ein privates Repository handelt, kann niemand anderes darauf zugreifen . Leider haben private Repositorys und GitHub nicht viele Funktionen , die öffentliche Repositorys haben. Wenn Sie diese Funktionen und privaten Repositorys möchten. Und mehr noch, tip erwägen Sie tatsächlich , einige der von GitHub angebotenen kostenpflichtigen Stufen in Anspruch zu nehmen. Sofern Sie keine Organisation sind, ist es für Sie nicht wirklich sinnvoll, dafür zu bezahlen. Und genau aus diesem Grund werden wir in diesem Kurs zum größten Teil das öffentliche Repository verwenden . Wir sehen uns als Nächstes. 64. 0804 Commits in GitHub erstellen und ReadMe-Datei verstehen: Mal sehen, wie wir unser erstes Commit machen und aufstehen können. Und das werden wir im öffentlichen Repositorium machen. Worauf wir kommen ist die Readme-Datei für unser Projekt. Was ist nun die Readme-Datei? Was auch immer Sie wissen lassen möchten, die Mitwirkenden Ihres Projekts würden in die Readme-Datei gehen , um es besser zu verstehen Schauen wir uns einige der vorhandenen Projekte und GitHub an und wie entvölkert die ReadMe-Dateien. Ich wähle einfach eines der zufälligen Projekte aus. Also klicke ich auf diesen Link, der besagt, dass du Berichte findest, die deine Hilfe benötigen. Ich wähle einfach eines der zufälligen Projekte aus, die hier verfügbar sind. Vielleicht ist das hier die Liste der Tupel, die erhöht werden sollen. Beide sind öffentlich. Lass mich das aussuchen. Alle Projekte und GitHub würden höchstwahrscheinlich die Readme-Datei haben. Und es befindet sich normalerweise im Stammverzeichnis des Projekts. Also hier ist es. Mal sehen, was da drin ist. Grundsätzlich können Sie Dinge wie Ihre Kontaktinformationen schreiben. Einige der Links, die Sie mit den Dollarnoten teilen möchten . Oder Sie können ihnen mitteilen, wie sie Probleme ansprechen können und an wen sie sich wenden können, falls es Probleme mit der Anwendung gibt. Sie können auch über die Anwendung und ihre Funktionen sprechen, wie sie es hier tun. Hier finden Sie eine Liste der Funktionen von dieser Anwendung unterstützt werden. Sie zeigen Anweisungen, wie sie dieses Projekt herunterladen können. Und eine Menge anderer Informationen , die wir in ihrer Roadmap teilen , damit Entwickler das gesamte Projekt aus der Vogelperspektive betrachten können. Hier scheinen sie alle Mitwirkenden aufgelistet zu haben , oder vielleicht die besten Mitwirkenden , die zu diesem Projekt beigetragen haben. So weiter und so fort. Lassen Sie uns fortfahren und eine Readme-Datei in unserem öffentlichen Repository erstellen . Ich wähle das öffentliche Repository aus, das erstellt wurde. Und derzeit haben wir keine Commits. Wir können entweder eine neue Datei erstellen oder eine vorhandene Datei hochladen, oder wir können eine dieser Optionen wählen. Und das Gate wird mit einigen Inhalten vorab gefüllt. Wir haben bereits gesehen, dass wir im Falle einer Lizenzdatei bereits einige vordefinierte Vorlagen haben. Wir haben auch bestimmte vordefinierte Vorlagen für Punkt-Ignorieren-Dateien. Aber das werden wir nicht verwenden, weil wir noch nicht darüber gesprochen haben. Lassen Sie mich die Datei „Readme“ wählen. Also ist es Read Me Dot MD-Datei. Es wurde MD Extension gelehrt. Hier. Du kannst schreiben, was du schreiben willst. Und wenn Sie fertig sind, können Sie nach unten scrollen und auf diese Schaltfläche klicken , auf der steht „Neue Datei übertragen“. Hier sehen Sie, dass einige Standardnachrichten bereits von GitHub gefüllt wurden. Es heißt Create, Read Me Dot RMD-Datei. Wenn Sie es ändern möchten, können Sie es ändern. Sie können auch die Beschreibung zu diesem Commit hinzufügen. Aber ich bin mit der Standardnachricht zufrieden. Also lasse ich es einfach so wie es ist und klicke auf Commit. ist kein Staging-Schritt erforderlich. Das würde intern diese Arbeit für uns erledigen. Sobald Sie die Datei festgeschrieben haben, sehen Sie diese Datei hier. Machen wir noch einen Commit, indem gegenseitig eine Datei vorstellen. Lassen Sie mich zurückgehen und auf diese Option klicken, die besagt Datei hinzufügen, neue Datei erstellen. Vielleicht möchte ich eine Vier-Punkt-TXT-Datei hinzufügen , Inhaltsinformationsdatei. Lassen Sie mich das erweitern. Ich scrolle nach unten. Und 1 Sekunde. Ich bin mit dem vorausgefüllten Text zufrieden, kann ihn aber auf Wunsch in etwas anderes ändern. Ich lasse diese Option so wie sie ist. Da wir nicht über Pull Request gesprochen haben. Ich kann Ihnen im Moment nicht erklären , worum es bei dieser Option geht. Wir werden in den kommenden Vorlesungen darüber sprechen. Komm mit der neuen Akte. Jetzt haben wir ein paar Kommentare. Wenn du auf diese Commits klickst, siehst du die Liste der Commits, die wir gemacht haben. Hier ist der HashCode für jeden dieser Kommentare, sodass Sie sie kopieren können, indem Sie auf dieses Symbol klicken. Sie können auch bei einem bestimmten Commit zu einem Status eines Projekts wechseln . Indem Sie darauf klicken. Wenn ich zum Beispiel darauf klicke, kommt der Komet in die ReadMe-Datei. Zu diesem Zeitpunkt haben wir die Info-Datei nicht, also sehen wir sie nicht. Lass mich zurückgehen. Hier. Du darfst die Filiale wählen. Derzeit haben wir nur einen Branch und das ist der Standard-Hauptzweig. Andernfalls würden Sie eine Liste von Filialen sehen und wir könnten zu einem der Zweige wechseln. So machst du also Kommentare und GitHub. Wir haben das Repository erstellt und auch einige der Basisdateien hinzugefügt , sodass es für andere bereit ist, zu unserem Projekt beizutragen. Wir sehen uns als Nächstes. 65. 0805 Branch erstellen und Änderungen begehen: Okay, lass uns sehen, wie wir einen neuen Branch erstellen und sogar Kommentare in GitHub abgeben können . Lassen Sie mich dafür zu einem der Repositorys gehen. Ich werde dafür das öffentliche Repository verwenden. Hier siehst du eine Liste von Filialen. Derzeit haben wir nur einen Zweig, den Hauptzweig, der auch der Standardzweig ist. Hier seht ihr diesen Link mit der Aufschrift Alle Filialen anzeigen. Sie können entweder hier klicken oder Sie können auch auf diesen Link klicken, der eine Filiale besagt. Es heißt eine Filiale, weil wir derzeit eine Filiale haben. Lass uns auf diesen Link klicken. Hier siehst du die Option , einen neuen Branch zu erstellen. Klicken Sie einfach auf diese Schaltfläche geben Sie den Namen ein, den Sie für diesen Zweig verwenden möchten . So etwas. Sie können auch den Quellzweig auswählen , aus dem Sie diesen Zweig erstellen möchten. In diesem Fall haben wir nur einen Zweig und dieser ist standardmäßig der Hauptzweig. Ich lasse es so wie es ist und klicke auf Create Branch. Dies hat die Filiale für uns geschaffen. Sie können auch eine bestimmte Liste von Zweigen sehen. Wenn ich zum Beispiel auf Aktivieren klicke, wird dies in der gesamten Liste der Zweige des zweiten Akts aufgeführt. Mit anderen Worten, dies sind die Zweige, in denen in den letzten drei Monaten mindestens ein Commit vorgenommen wurde. Sie werden den Standardzweig jedoch nicht sehen. Sie können den Zweig sehen , der gerade erstellt wird. Dieser Schwanzzweig ist das Gegenteil von zwei Ästen. Wenn es Branches gibt, in denen du in den letzten drei Monaten keine Commits gemacht hast, wirst du hier eine Liste von ihnen sehen. Wenn Sie der Eigentümer des Repositorys sind, möchten Sie vielleicht mit Mitarbeitern in Kontakt treten , die Entwickler sind, die an diesen Zweigen arbeiten , und bei ihnen nachfragen , ob sie diese Zweige weiterhin behalten möchten. oder nicht. Sie werden eine bessere Vorstellung davon bekommen , wenn wir in diesem Kurs voranschreiten. Und die Zweige in diesem Abschnitt würden so aufgelistet , dass der Zweig mit dem ältesten Commit zuerst aufgeführt wird. Während hier im aktiven Abschnitt alle diese Zweige so aufgelistet werden, dass die Zweige mit dem letzten Commit zuerst aufgeführt werden. Wenn du auf alle Zweige klickst, zeigt dieser Fuß nur den Standardbranch an, gefolgt von allen anderen Branches, sortiert nach den Zweigen mit dem letzten Commit zuerst. Sie können einen Branch auch löschen und wiederherstellen. Wenn du einen Branch löschst, aktualisiere die Seite, dann ist es zu spät, ihn wiederherzustellen. So können wir einen neuen Branch erstellen. Kehren wir zum Projektarchiv zurück. Hier können wir die Filiale auswählen , zu der wir wechseln wollten. Wechseln Sie zum Feature-Branch. Das ist, als hätten wir diesen Befehl oder Checkout-Befehl ausgeführt, der den Branch-Namen erwähnt. Und wenn Sie es bemerken, haben wir jetzt zwei Zweige, die hier gezeigt werden. Wir können entweder eine neue Datei in diesem Zweig hinzufügen oder eine der vorhandenen Dateien bearbeiten. Versuchen wir es hinzuzufügen. Lesen Sie Me dot MD Datei. Ich klicke auf dieses Symbol , um eine Nachricht zu bearbeiten. Ich möchte nach unten scrollen. Ich bin mit der Standardnachricht zufrieden, wenn Sie möchten, können Sie sie ändern. Ich lasse diese Option unverändert. Und klicken Sie auf Änderungen übernehmen. Dies hat dazu geführt, wie sich die neue Niederlassung ändert. Wir sind derzeit in der Hauptniederlassung. Und wenn Sie auf Read Me dot md file klicken und den Inhalt überprüfen, Sie feststellen, dass die Änderungen, die im Zweig der neuen Funktionen eingeführt wurden, nicht enthalten sind. Wenn Sie jedoch erwartungsgemäß zum Feature-Branch wechseln , werden Sie die Änderungen sehen, die wir gerade eingeführt haben, und Feature-Branch. Wir sehen uns als Nächstes. 66. 0901 Ein öffentliches Repo zu klonen und andere Optionen zu erkunden: Zuvor hatten wir 1996 ein GitHub-Konto mit dem Namen Centre Corp erstellt . Und wir haben auch ein paar Repositorys erstellt. Einer ist öffentlich, der andere ist ein privates Repository. Oder ein öffentliches Repository sollte für jedermann auf der Welt verfügbar sein , um es anzusehen , herunterzuladen, zu fliegen usw. Nehmen wir an, ich habe einen Typen mit dem Namen Luke gefunden und wollte, dass er zu meinem öffentlichen Archiv beiträgt. Stellen Sie sich jetzt vor, ich bin im Computer von Luke. Was Sie zuerst tun müssen, ist im Grunde ein GitHub-Konto zu haben. Zu diesem Zweck habe ich tatsächlich ein neues Gmail-Konto mit dem Namen Look Centre Corp auf der roten gmail.com und dem entsprechenden GitHub-Konto erstellt mit dem Namen Look Centre Corp auf der roten gmail.com und dem entsprechenden . Das ist also Lukes Bericht und jetzt bereitet er sich darauf vor, zum öffentlichen Repository von Cylinder Cop 1996 beizutragen . Dies ist die URL dieses Repositorys. Und ich kann das Projekt und seinen Inhalt ansehen, da es sich um ein öffentliches Repository handelt. Wenn das ein privates Repository ist, kann ich es nicht sehen. Tatsächlich sollte jeder mit diesem Link in der Lage sein, das Projekt und seinen Inhalt zu sehen das Projekt und seinen Inhalt da es sich um ein öffentliches Repository handelt. Das erste , was diese Schleife tun muss , um zu diesem Projekt beizutragen, ist eine lokale Kopie dieses Repositorys auf seinem lokalen Computer zu haben . Worüber ich spreche, ist Git Clone. Und wie der Name schon sagt, würde es im Wesentlichen das Center-Repository oder das Projekt in Ihre lokale Registrierung klonen . Also klickst du auf diese Schaltfläche mit der Aufschrift Code. Und wir haben mehrere Möglichkeiten , das Projekt zu klonen. Wir können es schaffen, CLI aufstehen. Get up CLI ist ein von GitHub angebotenes Tool. Es ist ein Open-Source-Tool und ermöglicht es Ihnen im Wesentlichen , über die Befehlszeile Ihres Computers mit GitHub zu interagieren . Dieses Tool soll ursprünglich zwar Zeit sparen, ist aber als solches kein obligatorisches Tool. Die andere Option ist die Verwendung von SSH, was ein langwieriges Verfahren ist, da Sie dafür öffentliche und private Schlüssel erstellen und dann den öffentlichen Schlüssel im Repository speichern müssen usw. Über SSH zu sprechen sollte ein Thema eines anderen Kurses sein. Wenn Sie SSH verwenden, können Sie diese Option verwenden. Wenn nicht, haben wir eine bessere Option. Tatsächlich wird diese Option sogar von GitHub empfohlen, das das HTTPS-Protokoll verwenden soll. Dies ist aus zwei guten Gründen die beste Option unter all diesen. Nummer eins: Normalerweise hören Firewalls nicht als HTTPS-Verkehr auf. Wir haben also dort einen Vorteil. Zweitens hilft es auch dem Credential Helper von Ihrem Betriebssystem, die Passwörter zwischenspeichern oder speichern zu können , was bei den anderen beiden Optionen nicht der Fall ist. Das ist am einfachsten, und wir können blind damit umgehen und müssen uns keine Sorgen um SSH machen oder CLI aufrufen. Wir haben auch die Möglichkeit, das Projekt herunterzuladen. Nun, wenn Sie das Projekt herunterladen, werden die historischen Daten nicht heruntergeladen oder der Versionsverlauf wird nur die Dateien im Projekt herunterladen. Wir können dies auch mit GitHub Desktop öffnen. Wenn Sie den GitHub Desktop installiert haben, können Sie ihn öffnen und dann den Ordner auswählen , in den Sie dieses Projekt klonen möchten. Da wir dieses Tool derzeit nicht verwenden, können wir dies ignorieren. Was wir also tun werden , ist einfach diesen HTTPS-Link zu kopieren. Dies ist der genaue Link, wie Sie hier sehen , der Link zum Projektarchiv. Das ist github.com Slash-Benutzername dieses Repositorys, der Besitzer des Repositorys, Schrägstrich den Namen des Repository selbst, und dann dot get extension. Das ist im Wesentlichen was ist das? Du bist buchstäblich nur kopiert. Sobald wir diesen Link in unseren lokalen Computer kopiert haben, befinde ich mich im Def-Verzeichnis. Lass es mich nochmal kopieren. Du kannst dir nicht vorstellen, dass das Lukes Computer ist. Ich verwende den Befehl git clone. Und dann fügen Sie diese URL ein. Also hier heißt es in diesen Ordner klonen. Im Wesentlichen hat es einen Ordner mit diesem Namen erstellt, was der genaue Name des Depositorys ist. Und der Inhalt würde genau den Inhalt ausmachen , den wir im GitHub-Repository gesehen haben . Und wenn Sie feststellen, dass es tatsächlich alle Objekte komprimiert hat . Im Grunde genommen, um es einfach zu machen, alle Dateien über das Internet auf Ihren lokalen Computer zu übertragen . Und dann hat es endlich alle Objekte extrahiert. Insgesamt wurden neun Objekte empfangen. Schauen wir uns den Inhalt in diesem Verzeichnis an. Also hier ist meine öffentliche Kappe. Lass es mich ein bisschen vergrößern. Wie Sie sehen können, haben wir sowohl dxdy als auch Read Me dot TXT-Datei herausgegeben . Innerhalb des Dot-Git-Ordners. Du wirst sehen, was wir normalerweise sehen. Möglicherweise haben Sie einige Dinge beobachtet , die Ihnen zu diesem Zeitpunkt seltsam erscheinen könnten. Wir werden in den kommenden Vorlesungen darüber sprechen. Zum Beispiel haben wir sogenannte Remotes, die nicht verfügbar waren, als wir das Repository lokal erstellten. Wir werden in den kommenden Vorlesungen darüber sprechen. Dies ist so, als ob Sie ein lokales Depository erstellt haben, außer dass wir dieses Mal tatsächlich ein vorhandenes Repository von GitHub geklont haben. Wenn Sie das Projekt herunterladen würden, werden Sie den dot git-Ordner nicht sehen. Sie würden nur diese beiden Projektdateien sehen. Dies ist der Grund, warum es als verteiltes Versionskontrollsystem bezeichnet wird . Sie haben eine Kopie des gesamten Repositorys zusammen mit seinem Versionsverlauf auf Ihrem lokalen Computer. Und Sie haben auch eine Kopie davon im zentralen Repository, das heißt get up. Und jeder in der Organisation oder in Ihrem Unternehmen hätte eine Kopie des gesamten Repositorys. Wenn einer ausfällt, haben Sie andere Systeme von denen Sie sie wiederherstellen können. Das ist verteiltes Versionskontrollsystem für Sie. Kehren wir zu Git Bash zurück. Wenn ich jetzt den Befehl git branch ausführe, müssen wir zuerst in dieses Verzeichnis gehen. Meine öffentliche GAP, Git Branch. Sie werden nur den Hauptzweig sehen, obwohl wir im zentralen Repository GitHub einen Feature-Branch erstellt haben , sehen wir hier nur den Hauptzweig. Warum ist das so? Nun, Sie werden in den kommenden Vorlesungen eine Antwort darauf finden. 67. 0902 Klonen eines privaten Repository und Hinzufügen von Projektmitarbeitern auf GitHub: Okay, mal sehen, wie wir ein privates Repository klonen können. Derzeit habe ich mich als Absender angemeldet Wer ist der Besitzer dieser Repositorys? Eines ist das öffentliche Repository und das andere ist das private Repository. Wir haben bereits gesehen, wie wir ein öffentliches Repository klonen können. Jeder auf der Welt kann es tatsächlich sehen und auf das System klonen. Aber wenn es um privates Repository geht, kann nicht jeder tatsächlich darauf zugreifen oder es klonen es sei denn, der Absender spricht ihn als Mitarbeiter seines Projekts an. Um das zu demonstrieren, habe ich mich sowohl als Zylinder als auch als Luke angemeldet , der zum privaten Repository von cylinder beitragen würde . Um zwischen diesen beiden Konten zu unterscheiden. Der mit dem schwarzen Team gehört Sunder und der mit dem weißen Team gehört Luke. Jetzt müssen Sie davon ausgehen , dass sich diese beiden Personen tatsächlich von ihrem eigenen Computer aus angemeldet haben . Und natürlich nicht aus demselben System, wie wir es hier tun. Lassen Sie mich den Link des privaten Repositorys kopieren und versuchen, von Lukes Konto aus darauf zuzugreifen. Und wir erhalten einen Fehler , der besagt, dass 404 lautet. Dies ist nicht die Webseite, nach der Sie suchen. liegt daran, dass under keine Berechtigung erteilt hat , auf dieses Projekt zuzugreifen. Absender muss also in dieses Repository gehen, zu Einstellungen gehen und dann Luke als Mitwirkenden hinzufügen. Lassen Sie mich das Passwort ganz schnell eingeben. Sie sehen diese Option mit der Aufschrift „Personen hinzufügen“. Ich werde suchen nach. Sieht unter Karpfen aus. Da Luke einen Inhalt hat, wird Github ihn sehen können. Lassen Sie mich sie auswählen und klicken Sie auf Looks hinzufügen auf der Corp to this repository. Sobald wir das getan haben, erhält Loop tatsächlich eine E-Mail, um die Einladung von sun zu akzeptieren , der Mitarbeiter des privaten Repositorys des Absenders zu sein . Also lass mich auf diesen Link klicken. Klicken Sie auf Akzeptierte Mutation. Wenn Sie jetzt zum Dashboard von Luke gehen, können Sie sehen, dass das private Repository gefüllt wird. Lass mich darauf klicken. Ich kann jetzt weitermachen und dieses Projekt planen. Aber es ist nicht sehr einfach wie bei öffentlichen Repositorys, wir müssen es tatsächlich authentifizieren. Lassen Sie mich das für Sie demonstrieren. Das sieht also Computer aus. Nehmen wir an, ich befinde mich im F-Laufwerk. Und lassen Sie uns den Befehl git clone ausführen und die URL einfügen und sehen, was passieren wird. Nun, gut öffnet diese spezielle Aufforderung. Und es gibt mehrere Möglichkeiten, uns zu authentifizieren. Aber ich würde gerne diese Option wählen, die besagt, dass Sie sich mit Code anmelden. Wenn Sie sich für Mit Ihrem Browser anmelden entscheiden, werden Sie nur zu einer Webseite weitergeleitet Sie aufgefordert werden, sich bei Ihrem GitHub-Konto anzumelden . Auf diese Weise werden Sie authentifiziert und der Klonvorgang wird fortgesetzt. Aber versuchen wir, diesen Weg zu wählen. Wenn ich auf Mit Code anmelden klicke, siehst du einen Code , den wir zur Authentifizierung verwenden müssen. Lassen Sie mich zuerst ein Browserfenster öffnen. Ich gehe zu github.com Slash-Login-Slash-Gerät. Es wird uns zu dieser Seite führen. Lassen Sie mich diesen Code kopieren, Kontrolle C und Kontrolle V. Und klicken Sie auf Weiter. Klicken Sie auf Autorisieren. Fordert uns auf, das Passwort von Lukes Konto einzugeben. Lass uns das ganz schnell machen. Das ist alles. Unser Klonprozess wurde fortgesetzt. Und wir können jetzt mit dem Zugriff auf die Bank-App beginnen. Gruppiert Listen mit der Option Silbentrennung, zeigt aber auch die versteckten Ordner an. Ab diesem Zeitpunkt würde alles so bleiben wie beim öffentlichen Repository. Aber so klont man ein privates Repository. Wir sehen uns als Nächstes. 68. 0903 Verstehen von Tracking und Default: Lass uns über das Verfolgen von Filialen sprechen. Stellen Sie sich vor, dies ist der aktuelle Stand unseres Projekts in GitHub. Und jetzt nehmen wir an , ich habe den Befehl git clone ausgeführt , um das Projekt auf meinen lokalen Computer zu klonen . Nun, das wird auf meinem lokalen Computer in keiner bestimmten Reihenfolge passieren . Zunächst würden alle Objekte heruntergeladen und dann erstellt get sogenannte Tracking-Zweige. Was ist der Tracking-Zweig? Verfolgung von Zweigen, eine lokale Niederlassung , die eine Remote-Filiale darstellt. Und es würde immer auf genau dasselbe Commit hinweisen. Die Remote-Zweige zeigen darauf, dass sie nur die Remote-Zweige repräsentieren. Nur zur Erinnerung, ein Branch ist einfach ein Zeiger auf ein bestimmtes Commit. Jetzt werden diese Tracking-Zweige nicht automatisch aktualisiert. Sie werden immer dann aktualisiert, wenn wir bestimmte Befehle wie git-fetch und git pull ausführen , über die wir in den kommenden Vorlesungen sprechen werden. Und dann, standardmäßig mit dem Klonvorgang, checkt git zum Standardbranch aus , der der Hauptzweig ist. Und so würde automatisch ein lokaler Min-Zweig erstellt. Wir können tatsächlich den Standardzweig in unserem GitHub konfigurieren , in kommenden Vorlesungen explodieren wird. Wenn Sie sich in unserer vorherigen Vorlesung erinnern, als wir den Befehl git branch ausgeführt haben, wurde nur der Hauptzweig aufgelistet, nicht jedoch der Feature-Branch. Nun, das ist der Grund dafür. Wenn Sie auch den Feature-Branch sehen möchten, müssen wir zu diesem Branch auschecken, damit ein lokaler Feature-Branch von good erstellt wird und ihn sehen kann. Nehmen wir nun an, ich habe ein lokales Commit im Hauptzweig wie in der Zelle gemacht , der Tracking-Zweig würde so bleiben, wie er ist, denn darauf zeigt sogar der Remote-Hauptzweig . Der lokale Hauptzweig würde jedoch aktualisiert, um auf den neuesten Commit in unserem lokalen Computer hinzuweisen. Du wirst die Bedeutung der Verfolgung von Zweigen verstehen , wenn wir Befehle wie git-fetch, git, pull, git push usw. untersuchen . Eine andere Sache, die Sie vielleicht bemerkt haben , ist , dass alle diese Tracking-Zweige als Ursprungs-Slash-Haupt- oder Ursprungs-Feature benannt sind Nun, was ist Herkunft hier? Es ist im Wesentlichen das früheste von get erstellte , das das Remote-Repository darstellt. Grundsätzlich stellt Winter immer dann, wenn wir Befehle ausführen , die URL des Remote-Repositorys bereit. Es ist wirklich schwer, sich die URL zu merken. Und deshalb haben wir diese LES geschaffen. Anstatt die URL zu verwenden, könnten wir also einfach diesen Namen verwenden. Stattdessen. Wir können diesen Namen ändern, wenn wir möchten, oder wir können ihn so lassen, wie er ist. Wir werden auf jeden Fall in den kommenden Vorlesungen mehr darüber sprechen . Wir sehen uns als Nächstes. 69. 0904 Erkundung von Tracking Konfiguration Default Verstehen des branches: Okay, schauen wir uns zuerst die Liste der Tracking-Zweige an . Und der Befehl dafür ist git. Filiale. Bindestrich r steht für Remote. Hier sehen Sie sowohl den Hauptzweig als auch den neuen Feature-Branch. Und dies sind die Tracking-Zweige, die in den Remote-Zweigen dargestellt werden . Auf GitHub. Man kann sagen, dass diese Zweige verfolgen , weil sie mit dem Ursprungs-Slash und dann dem Namen des Zweigs beginnen . Sie können dies auch im Git-Repository finden. Lass mich zu dem Projekt gehen. Und innerhalb des Punkt-Git-Ordners sollten Sie in der Lage sein, diese Datei mit dem Namen packte Bindestriche zu finden . Mach das auf. Und Sie können sehen, dass wir diese beiden Zweige haben. Und der Punkt in spezifische Kommentare. Schauen wir uns an, worauf sie zeigen. Lass mich dafür aufstehen. Ich bin derzeit in der Hauptzweige. Und hier seht ihr den hashCode des letzten Commits. Es ist E 0, Triple Six ist sieben. Und wir sind in der Hauptzweige. Und wenn Sie es bemerken, zeigt die Tracking-Zweigleitung auf genau denselben Kometen. Lassen Sie uns auch den neuen Feature-Zweig überprüfen. Es sollte auf dieses Commit verweisen , das mit 855 D, D2 beginnt. Gehen wir zurück und wechseln zum Feature-Branch oder zum neuen Feature-Branch. Und tatsächlich deutet es auf dieses Commit mit dem HashCode 855, double D to C hin. Selbst wenn Sie ein lokales Commit machen würden, würde dies immer noch so bleiben, wie es ist. Dies würde nur aktualisiert wenn wir tatsächlich bestimmte Befehle wie git, fetch, git pull usw. ausführen . Wir werden sie in den kommenden Vorlesungen untersuchen. Git branch würde die Liste der lokalen Zweige auflisten. Und was auch immer der Standardbranch ist und GitHub würde nicht automatisch überprüft wenn wir das Projekt klonen, der Standardbranch ist zufällig der Haupt-Branch. Der Kopf zeigt hier immer auf den Standardzweig , der der Hauptzweig ist. Gehen wir zum Aufstehen und schauen an, wo wir den Standardbranch konfigurieren können. Wenn du zu den Einstellungen gehst. Unter Ästen. Hier sehen Sie, dass die Standardzweige, der Hauptzweig. Wenn Sie möchten, können Sie zu einer anderen Filiale wechseln. Zum Beispiel kann ich Feature-Branch auswählen und auf Update klicken. Es ist jedoch keine empfohlene Vorgehensweise. Ich überspringe es. Aber du kannst es machen, wenn du willst. Im Git-Repository. Wenn Sie in refs remote origin gehen und einen Blick darauf werfen, was sich in der Header-Datei befindet, sollte es auf den Standardzweig verweisen. Und das sehen wir hier. Um nun einen lokalen Branch für den neuen Feature-Branch zu erstellen, ging ich zu diesem Branch auschecken. Lass uns einen Git Checkout machen. Neue Funktion. Wenn Sie jetzt git branch machen, werden alle lokalen Zweige aufgelistet. Und es enthält jetzt auch den neuen Feature-Zweig. Wir können jetzt mit der Arbeit an diesem Feature-Zweig beginnen. erhalten Sie mehr Klarheit darüber, worüber wir gerade gesprochen haben Im Verlauf dieses Kapitels erhalten Sie mehr Klarheit darüber, worüber wir gerade gesprochen haben. Wir sehen uns als Nächstes. 70. 0905 Herkunft verstehen remote Bearbeiten, Löschen von Fernbedienungen: Lass uns über die Herkunft sprechen. Origin ist so etwas wie ein Alias auf deinem System für ein bestimmtes Remote-Repository. Lassen Sie mich erklären, was ich meine. Es gibt bestimmte Befehle und Sie erhalten, wo Sie den Remote-Repository-URI angeben müssen. Wie im Fall von Git Push. Wir werden in den kommenden Vorlesungen mehr über den Befehl git push sprechen . Aber im Wesentlichen ermöglicht uns dieser Befehl, dass wir unsere lokalen Commits auf das Remote-Repository übertragen können . Nun, bei solchen Befehlen müssen wir eingeben, wohin wir unsere Commits pushen möchten , indem wir den URI des Remote-Repositorys angeben. Wie wäre es, wenn wir dieser ERA einen Namen geben würden, sodass jedes Mal, wenn wir einen solchen Befehl ausführen müssen, anstatt die gesamte ERA anzugeben, jedes Mal, wenn wir einen solchen Befehl ausführen müssen, anstatt die gesamte ERA anzugeben, stattdessen nur diesen Namen eingeben müssen. Das wird uns eine Menge Komfort geben. Und das ist im Wesentlichen der Ursprung. Origin ist ein bisschen wie ein verkürzter Name für die Remote-Repo-Studie, aus der das Projekt ursprünglich geklont wurde. Anstatt den URI einzugeben, könnten wir also einfach den Ursprung sagen. Und es ist Asda. Wir haben den Remote-Repository-URI eingegeben. Wir können diesen Namen in etwas anderes umbenennen. Wir können auch zusätzliche Fernbedienungen hinzufügen. Wenn ich sage, dass remote einfach ein Name ist , der ein bestimmtes Remote-Repository darstellt, wie können wir diese Remotes sogar löschen. Lassen Sie mich Ihnen zeigen, was ich meine. Wenn Sie in den dot git-Ordner gehen, öffnen Sie in Ihrem Projekt die Konfigurationsdatei. Sie stellen fest, dass wir eine Fernbedienung mit dem Namen Herkunft haben, auf ein Remote-Repository im URL-Feld verweist. Genau das ist der Modus. Also jedes Mal, wenn wir den Befehl ausführen müssen, wo müsste der CR eingegeben werden? Wir können stattdessen einfach den Ursprung des Namens eingeben. Wir können das auch umbenennen, aber natürlich sollten wir es nicht direkt in dieser Datei tun. Führen Sie stattdessen den Befehl aus. Lass uns das machen. In der Git Bash. Lassen Sie uns zunächst eine neue Fernbedienung erstellen. Und ja, wir können mehrere Fernbedienungen haben und es gibt Szenarien, in denen wir möglicherweise mehrere Fernbedienungen benötigen. Wir werden in den kommenden Vorlesungen darüber sprechen. Aber jetzt wollen wir sehen, wie wir eine Fernbedienung erstellen, umbenennen und sogar eine Fernbedienung löschen können . Der Befehl dafür ist git remote. Fügen Sie den Namen der Fernbedienung, den Namen, den Sie möchten, zu diesem Remote-Repository hinzu. Nennen wir es Temp, Report, was auch immer. Und dann geben Sie die URI des Remote-Repositorys an. Dies ist nur eine Dummy-URL , die es nicht gibt. Und wenn ich die Eingabetaste drücke und wir zur Konfigurationsdatei zurückkehren, sehen Sie, dass eine neue Fernbedienung mit dem Namen temporärer Pol erstellt wurde, deren URL die URL ist , die wir gerade in der befehlen. Lassen Sie mich versuchen, diese Fernbedienung umzubenennen. Git remote, benenne sie in Ripple um. Der Name der Fernbedienung, die umbenannt werden soll. Und dann geben Sie den Namen an, den wir ihm geben möchten. Neue Zeit, Repo, sagen wir mal. Und das wird den Namen in diesen neuen Namen ändern. Lassen Sie uns abschließend sehen, wie wir eine Fernbedienung entfernen können. Git. Remote-Entfernung ist die Option. Dann geben Sie die Fernbedienung an, die Sie entfernen möchten. Und das war's. Dies hat die Fernbedienung entfernt. Als wir den Befehl clone ausgeführt hatten um ein bestimmtes Remote-Repository zu klonen, hat Git im Wesentlichen eine Fernbedienung für uns erstellt. Der Name dieser Fernbedienung ist origin, deren URL die URL ist, die wir zum Klonen des Projekts verwendet haben. werden Sie mehr über Fernbedienungen erfahren diesem Kurs werden Sie mehr über Fernbedienungen erfahren. Wir sehen uns als Nächstes. 71. 1001 Verstehe Git Fetch und es ist usecases: Lass uns über Git-Fetch sprechen. Stellen Sie sich vor, dies ist der aktuelle Stand unseres Projekts sowohl im Remote- als auch im lokalen Depository. Halten Sie jetzt das Video an, nehmen Sie sich eine Minute und versuchen Sie, dieses Diagramm zu verstehen. Ihr erneuert das alle. Nun, wir haben nur ein paar Kommentare im Hauptzweig sowohl im lokalen als auch im Remote-Repository. Und dann haben wir Single Commit im Feature-Branch sowohl im lokalen als auch im Remote-Repository, mit Ausnahme des lokalen Depositorys haben wir auch zusätzliche Tracking-Zweige , die die Zweige in der Ferne darstellen Endlager. Und derzeit zeigen sie auf genau dieselben Kometen , auf die die entsprechenden Remote-Repository-Zweige zeigen. Lass uns über Git-Fetch sprechen. Stellen Sie sich vor, dass im Feature-Branch des Remote-Repositorys ein paar zusätzliche Kommentare abgegeben werden. Was ist, wenn ich die Objekte , die diesen Kometen entsprechen, gleichzeitig herunterladen möchte. Ich möchte all diese Änderungen nicht in meinem Arbeitsverzeichnis sehen . Jetzt tauchen Sie vielleicht eine Frage auf , warum wir diese Objekte herunterladen möchten? Diese Änderungen sollen aber nicht in einem Arbeitsverzeichnis angezeigt werden. Nun, es gibt mehrere Anwendungsfälle , in denen es nützlich sein könnte. Nehmen wir zum Beispiel an, dass ich mein lokales Repository mit dem Remote-Repository vergleichen möchte mein lokales Repository mit dem Remote-Repository um zu überprüfen, wie viele Kommentare das Remote-Repository vor meinem lokalen Repository liegt meinem lokalen Repository ein bestimmter Zweig oder umgekehrt. Ich würde gerne überprüfen, wie viele Kommentare mein lokales Repository vor dem Remote-Repository in einem bestimmten Zweig hat? Oder was ist, wenn ich den genauen Status des Remote-Repositorys wie in meiner lokalen Registrierung erhalten möchte, um mit der Arbeit daran zu beginnen. Zur gleichen Zeit. Ich möchte nicht, dass es irgendwelche Auswirkungen auf die Arbeit hat, die ich bereits vor Ort geleistet habe. Oder es könnte der Fall sein, dass ich mir nur ansehen wollte , ob es zusätzliche Zweige oder Tags gibt, Referenzen, die im Remote-Repository vorhanden sind , aber nicht im lokalen Depository vorhanden sind. Nun, Git-Fetch ist die Antwort darauf. Wenn Sie den Befehl git fetch lokal ausführen , werden alle zusätzlichen Objekte heruntergeladen , die noch nicht in Ihrem lokalen Repository vorhanden sind. Und aktualisiere auch diese Tracking-Zweige, um auf diese neuen Commits oder die neuen Objekte zu verweisen diese neuen Commits oder , die gerade mit git-fetch heruntergeladen wurden. In diesem Beispiel gehen wir nur davon aus, dass wir zusätzliche Kommentare und Feature-Branch haben. Daher wird nur der Tracking-Zweig des Feature-Branches aktualisiert , sodass er auf genau denselben Commit auf den die Remote-Zweige zeigen. Wenn jedoch in anderen Zweigen zusätzliche Kommentare abgegeben werden , entsprechenden Tracking-Zweige werden auch die entsprechenden Tracking-Zweige auf Ihrem lokalen Computer aktualisiert. Nun die Tatsache, dass die lokalen Branches, wie der Main- und der Feature-Branch immer noch auf die alten Commits verweisen. Du gehst in diesen Raum, du wirst nicht all die neu eingeführten Änderungen haben . All dies mag für Sie sehr verwirrend klingen, aber in den nächsten Vorlesungen werden Sie sich vollkommen darüber im Klaren sein, warum wir Git-Fetch brauchen , und Sie werden seine Bedeutung verstehen. Ich kann nicht alles unter ein einziges Video passen. Wir sehen uns als Nächstes. 72. 1002 Git Fetch in Aktion Part1 (Änderungen des Befehls überprüfen des Status mit Befehlen): Okay, lass uns sehen, wie Git Fetch funktioniert. Ich habe mich derzeit als Eigentümer des Repositorys angemeldet. Und nur zu Ihrer Information, derzeit sind sowohl das lokale als auch das Remote-Repository genau gleich. keinem der Orte wurden zusätzliche Kommentare abgegeben. Lassen Sie mich jetzt zum öffentlichen Repository gehen und ein neues Commit machen. Wir könnten es tatsächlich im Hauptzweig machen, oder lass es uns im Feature-Branch machen. Ich füge einfach eine neue Datei hinzu. Ich würde es gerne als vielleicht Apple dot dx, dy nennen. Es spielt keine Rolle, ob Sie einen Ordner hinzufügen und nur den Namen des Ordners angeben möchten . Vielleicht. Senden Sie zum Beispiel einen neuen Anbieter-Slash. Dies würde einen Ordner mit dem Namen My Folder erstellen , in dem sich diese Datei mit dem Namen apple dot TXT befindet. Ich möchte die Datei nur kommentieren. Klicken Sie auf Bestätigen. Wir haben gerade einen Kommentar erstellt. Lassen Sie mich nun fortfahren und auch einen Zweig erstellen. Lassen Sie mich zunächst zur Hauptniederlassung wechseln. Weil das von dort ist. Ich möchte einen neuen Branch erstellen. Dieser Typ gibt den Namen des Zweigs ein, den ich gerne machen würde , vielleicht Feature zwei. Und dann haben wir hier eine Option, um eine Verzweigungsfunktion zu erstellen , klicken wir darauf. Und dies sollte eine Funktion zum Verzweigen erstellen. Lassen Sie mich zurück zum Zweig der neuen Funktionen wechseln und auf die Kommentarliste klicken. Hier ist der Commit , den wir gerade gemacht haben, dessen Hash mit E8, AF, was auch immer beginnt. Gehen wir jetzt zur lokalen Registrierung. Nun müssen Sie sich vorstellen, dass dies einer der Computer des Angestellten ist, vielleicht der von Mr. Luke, was auch immer. Bevor ich jetzt git fetch mache, lass mich den Befehl git log ausführen. Und beachte, dass ich gerade im neuen Feature-Branch bin. Hier. Wie Sie sehen können, verweist der neue Feature-Branch , der lokale Zweig, auf diesen speziellen Commit. Und selbst der Tracking-Zweig weist auf dieses Commit hin. Jetzt, nachdem ich git fetch gemacht habe, sollte es all die zusätzlichen Objekte herunterladen , die im Remote-Repository vorhanden sind, und auch diesen Tracking-Zweig aktualisieren , um auf dieses Commit-Objekt zu verweisen. Mal sehen, ob das passiert. Aber lassen Sie mich vorher noch einen Befehl los, um die Details der Original-Fernbedienung zu überprüfen . Git, remote, Herkunft zeigen. Dadurch werden die Informationen über die Original-Fernbedienung angezeigt. Lassen Sie mich Ihnen zeigen, was hier gezeigt wird. Wir haben das Fetchone, das aus der Konfigurationsdatei abgeholt wird, pusht etwas, über das wir noch nicht gesprochen haben. Aber wenn wir den Befehl push verwenden, ist dies eine URL, die verwendet werden sollte, um unsere lokalen Änderungen zu pushen. Kopfzweige, die auf den Hauptzweig zeigen , der einen Standardzweig hat, wie wir bereits besprochen haben. Hier ist die Liste der Zweige. Dies sind die Zweige, die im Remote-Repository verfügbar sind . Wenn Sie bemerken, verzweigen Sie sich Twitter für den neuen Branch , der im GitHub erstellt wurde. Es heißt, dass der nächste Abruf im Remote-Slash-Ursprung gespeichert wird. Dies bedeutet, dass Git beim Abrufen einen Tracking-Zweig für die Funktion zum Zweig erstellt , der im Remote-GitHub-Repository vorhanden ist . Der Hauptzweig und der neue Feature-Branch wurden jedoch bereits verfolgt. Hier ist die Liste der lokalen Zweige für git pull konfiguriert sind. Wir werden ziemlich bald über guten Pull sprechen. Dies sind die Zweige für Git Push. Wir haben diese Filiale nicht hier, weil wir noch keine Schulden eingeholt haben und wir nicht in diese Filiale eingecheckt haben. Schauen wir uns jetzt an, was passieren würde , wenn ich git fetch mache. Im Idealfall muss ich den Namen der Fernbedienung angeben , von der ich die Objekte abrufen möchte. Aber wenn ich nichts spezifiziere, würde es standardmäßig die Original-Fernbedienung verwenden, die wir bereits haben. Wenn Sie Objekte abrufen möchten, die einem bestimmten Zweig auf einer bestimmten Fernbedienung entsprechen . Dann lautet die Syntax dafür, dass Sie in diesem Fall den Remote-Ursprung angeben . Und dann geben Sie einfach den Namen des Zweigs an, zum Beispiel neue Funktion oder was auch immer. Wenn Sie Objekte für die gesamte Fernbedienung und alle Zweige herunterladen möchten , verwenden Sie einfach die Option. Alles. Derzeit haben wir nur einen abgelegenen Dorfursprung. Also kann ich diesen Befehl einfach so ausführen, wie er ist ohne etwas angeben zu müssen. Also wurden all diese zusätzlichen Objekte heruntergeladen und lokal entpackt. Und wenn Sie bemerken, haben wir diese neue Filiale, die eine Funktion zur Zweigstelle ist, für die bei der Nachverfolgung der Filiale erstellt wird. Und dann ist das eine wichtige Zeile. Der neue Feature-Zweig. Zuvor wurde auf dieses spezielle Commit hingewiesen. Aber jetzt zeigt der neue Feature-Tracking-Zweig oder der lokale Tracking-Zweig oder der lokale Tracking-Zweig auf diesen neuen Commit. Dies ist genau der Commit, wir vor einem Moment im Remote-Repository vorgenommen haben . Also hier ist es. Es ist E8 a F E to E. Und das ist genau das Gleiche. Lassen Sie mich nun den Befehl remote show origin erneut ausführen und sehen, was er im Vergleich zu dem, was er zuvor gezeigt hat, zu zeigen hat. Nun, wenn Sie beobachten, dass die Funktion zum Verzweigen verfolgt wird , dieser Zweig in dieser Liste immer noch nicht verfügbar ist. liegt daran, dass wir noch nicht in dieser Filiale ausgecheckt haben. Wenn ich Switch-Funktion zwei erhalte, könnten Sie auch Git-Checkout-Funktion sagen. Wir würden zu dieser Filiale wechseln. Und jetzt, wenn Sie diesen Befehl ausführen, würden Sie diesen Zweig auch in dieser Liste sehen. Lassen Sie mich zurück zum neuen Feature-Zweig wechseln. Immer wenn ich zu diesem Branch wechsle, sehen Sie diese Nachricht, die besagt, dass Ihre Zweige hinter der ursprünglichen neuen Funktion stehen, die den Tracking-Zweig um einen Commit darstellt, was bedeutet, dass das Remote-Repository ein Commit ist vor unserer lokalen Depotfiliale. Es heißt auch , dass wir tatsächlich eine Schnellvorlaufzusammenführung durchführen können , über die wir in den kommenden Vorlesungen sprechen werden. Und es schlägt uns auch vor , dass wir git pull verwenden können , um Ihre lokale Niederlassung zu aktualisieren. Sobald wir den lokalen Zweig mit einer guten Umfrage oder mit der Zusammenführungsoperation aktualisiert haben, werden Sie sehen, dass all diese neuen Änderungen im Arbeitsverzeichnis verfügbar sind. Länder, da die lokalen Niederlassungen immer noch auf alle Commits verweisen, ist Ihr Arbeitsverzeichnis derzeit überhaupt nicht betroffen. Wenn ich jetzt git log, siehst du nur, dass unser lokaler neuer Feature-Branch auf diesen alten Commit verweist. Wenn Sie sich erinnern, haben wir zuvor auch den Tracking-Zweig gesehen, der auf diesen Commit verweist. Aber nach dem Abrufen zeigen Tracking-Zweige jetzt auf das neue Commit-Objekt , das mit git-fetch heruntergeladen wurde. Ich lasse, wir sehen uns als Nächstes. 73. 1003 Git Fetch in Aktion Part2 (Erforschen refs FETCH: Okay, ich habe erwähnt, dass Git-Fetch die Objekte herunterlädt und sogar die Tracking-Zweige aktualisiert. Lassen Sie uns sagen, wenn ich damit tatsächlich Recht habe, lassen Sie mich zu GitHub gehen und den HashCode des letzten Commits kopieren den HashCode des letzten Commits indem Sie auf dieses Symbol klicken. Und ich bin gerade im neuen Feature-Branch und auf GitHub. Lassen Sie mich zu Git Bash gehen und versuchen, dieses Objekt hübsch zu drucken, bekomme den Bindestrich P. Und dann füge ich HashCode ein, den ich gerade kopiert habe. Wir können also den Inhalt des Commit-Objekts sehen, was bedeutet, dass git-fetch dieses Objekt tatsächlich heruntergeladen hat. Wenn Sie durch diesen übergeordneten Baum dieses Kometenobjekts navigieren , sollten Sie auch in der Lage sein, die Blob-Objekte und den entsprechenden Inhalt zu finden . Lassen Sie uns nun sehen, ob knackende Zweige aktualisiert werden. Ich habe erwähnt, dass die Tracking-Zweige tatsächlich in der Backdrops-Datei erhalten bleiben. Lass es uns öffnen. Hier. Wenn Sie feststellen, zeigt der neue Feature-Branch immer noch auf den alten Commit. Nun irre ich mich, wenn ich sage, dass die Tracking-Zweige aktualisiert werden würden? Die Antwort lautet nein. Lassen Sie uns sehen, was sich in diesem speziellen Verzeichnis befindet. Remote-Ursprung und neue Feature-Refs, Remote-Ursprung. Und lassen Sie mich die Datei mit dem Namen neue Funktion öffnen. Und hier siehst du den HashCode des letzten Commits. Warum ist dieser Hash-Code hier verfügbar , aber nicht in der refs-Datei verfügbar , wird normalerweise dazu neigen, Referenzen in der Verzeichnisstruktur zu speichern. Es wird nicht unbedingt immer in einer gepackten Datei gespeichert. Nutzen Sie diese gepackte Datei aus Gründen der Effizienz. Es garantiert jedoch nicht, dass er nicht einmal vorhersagen kann, wo die Referenzen gespeichert werden. Es könnte sich in der gepackten Datei befinden, oder es könnte auch in Form einer Datenstruktur vorliegen. Wenn es die Unterschiede in einer gepackten Datei speichert, muss es nicht die Verzeichnisstruktur erstellen , nur um die Referenz zu speichern. Es ist alles intern aufzustehen. Und dies ist eines der Beispiele dafür warum wir uns nicht zu viele Sorgen darüber machen sollten , wie gut die Dinge für uns sind. Wir müssen nur die Befehle ausführen und vertrauen und loslegen. Möglicherweise ist Ihnen auch diese Datei fetch head aufgefallen , die beim Abrufen erstellt wird . Lassen Sie uns den Inhalt davon sehen. Nun ist es wieder so, dass Sie sich nicht allzu viele Sorgen machen sollten . Aber wenn Sie bemerken, dass wir drei Zeilen haben, jeweils einem einzelnen Zweig entsprechen, mit Ausnahme des Zweigs, von dem aus wir den Befehl git-fetch gezogen haben. Alle Zweige pro sind als nicht viel gekennzeichnet. Aber lassen Sie uns nicht versuchen, alles zu lernen, da Sie sich möglicherweise selbst verwirren und möglicherweise nicht in der Lage sind, die wirklichen Konzepte zu verstehen , die notwendig sind. Aber diese Datei wird normalerweise von Gibbs verwendet. Wenn wir bestimmte Befehle ausführen, wie zum Beispiel git pull, die wir in den kommenden Vorlesungen sprechen werden. Zum Beispiel. Wenn Sie git log machen, können Sie den oder zwei Tracking-Zweige nicht sehen , auf die die Tracking-Zweige verweisen. Aber wenn Sie git log sagen und dann zum Beispiel den Unterstrich holen. Dann wird auch das Kometenobjekt aufgelistet , auf das die Verfolgungszweige zeigen. Ähnlich haben wir also bestimmte Befehle, die intern die fetch head-Datei verwenden würden . Wir sehen uns als Nächstes. 74. 1004 Umschalten auf Remote Repo State: Jetzt mit git-fetch, da wir all diese Objekte heruntergeladen haben, können wir tatsächlich das bestimmte Commit auschecken und werden das trennen, was geblieben ist. Auf diese Weise. Wir können den gleichen Status des Remote-Repositorys haben , ohne unsere bestehende Arbeit beeinträchtigen zu müssen. Lass mich dir zeigen, was ich meine. Lass mich zurück zu GitHub gehen und zum neuen Feature-Branch wechseln und den Hash-Code aus dem neuesten Commit holen. Eigentlich würden die ersten paar Zeichen genügen. In Git Bash. Ich sage „Git Checkout“. Da ist der HashCode. Das sollte unser Projekt dazu bringen, diesen Zustand zu lösen. Und im Grunde unser Projekt nicht genau den gleichen Status wie beim Remote-Repository. Wenn Sie bemerken, haben wir diese Datei, Apple Dot TXT-Datei, die wir brauchen. Wenn Sie diese Nachricht lesen, können Sie sehen, dass Sie im Bundesstaat getrennt sind. Sie können sich umschauen, experimentelle Änderungen vornehmen und diese festlegen. Und du kannst all diese Kommentare verwerfen, sobald du zu einem anderen Branch zurückwechselst. Also kann ich weitermachen und einige Kommentare abgeben. Experimentiert die Anwendung oder was auch immer Vesikel mit meinen Veränderungen. Und wenn ich fertig bin, kann ich einfach zu einem Branch zurückkehren , damit all diese Kommentare verloren gehen. Falls ich diese Kommentare behalten möchte, kann ich diesen Befehl verwenden, um den Bindestrich Z zu erhalten. Und dann gebe ich einen Namen für den neuen Zweig an. Dieser Befehl würde also diesen Zweig erstellen und all diese Kommentare im Kopf haben , die nicht auf diesen bestimmten Commit verweisen, nicht auf einen bestimmten Branch. Und deshalb ist es ein abgetrennter Kopfzustand. Lassen Sie mich zurück zum neuen Feature-Zweig wechseln. Neue Funktion. Und wir verlassen den Zustand des abgetrennten Kopfes. Sie würden natürlich keine Apple Dot TXT-Datei mehr CD. Vielleicht kannst du das jetzt als Auftrag annehmen. Gehen Sie zu detach set state, machen Sie einige Kommentare, bevor Sie zu einem Branch zurückkehren. Stellen Sie sicher, dass diese Änderungen vorgenommen werden, die Kommentare werden in einem anderen Zweig beibehalten. Ich wünsche dir viel Glück dabei. Wir sehen uns als Nächstes. 75. 1005 Zusammenführung der Änderungen mit FETCH: Nehmen wir an, dass ich alle Änderungen des Remote-Repositorys in meinem Arbeitsverzeichnis haben möchte. Vielleicht, weil ich gerne an ihnen arbeiten würde, oder vielleicht möchte ich einfach alle Remote-Updates haben und dann möchte ich weiter an meinen eigenen Sachen arbeiten. Nun eine Frage an dich. Was kann ich jetzt tun, damit ich all diese Änderungen in meinem Arbeitsverzeichnis habe. Mit Git-Fetch. Wir haben bereits alle Objekte heruntergeladen. müssen wir nicht noch einmal machen. Was können wir sonst noch tun? Nun, wir können eine Zusammenführung durchführen. Wir haben den Tracking-Zweig für eine neue Funktion, die auf den Remote-Commit verweist. Und wir haben auch den lokalen Zweig für neue Funktionen, der auf das alte Commit verweist. Wenn wir diese beiden Zweige zusammenführen, sollten wir idealerweise alle Änderungen in unserem Arbeitsverzeichnis haben , nicht wahr? Lassen Sie uns zunächst den Befehl git status ausführen. Es heißt, dass Ihre Zweige mit einem Commit hinter der ursprünglichen neuen Funktion stehen und schnell vorspulen können , hat uns einen Vorschlag gegeben , dass wir tatsächlich eine Schnellvorlaufzusammenführung durchführen können . Das bedeutet auch , dass es auch die Möglichkeit gibt , dass wir eine Drei-Wege-Zusammenführung durchführen müssen. Und wir könnten genauso gut Konflikte bekommen, mit denen wir uns auseinandersetzen müssen. Wir haben bereits gesehen, wie wir mit Konflikten umgehen , wenn Sie versuchen, ein paar Zweige zusammenzuführen. Gleiches gilt auch hier. Jetzt können Sie versuchen zu raten, welchen Befehl ich hier eingeben soll, um all diese neuen Änderungen in unserem Arbeitsverzeichnis zu haben . Nun, es ist ein Standard-Befehl zum Zusammenführen von git. Wir müssen zuerst zu einem Branch pushen , in den wir zusammenführen möchten In diesem Fall möchten wir Änderungen von einem anderen Branch mit dem lokalen Zweig für neue Features zusammenführen . Und genau da bin ich. Lassen Sie mich den Befehl git merge eingeben. Und ich werde den Tracking-Zweig angeben, der die neue Funktion „Origin Slash“ ist. Im Wesentlichen führen wir in diesem Fall nur eine schnelle Vorwärtszusammenführung durch, wobei unser neuer Feature-Branch , der ein lokaler Branch ist, jetzt auf genau den gleichen Commit verweisen würde , den Remote-Tracking-Zweige zeigen auf. Aber nehmen wir an, dass Sie auch in Ihrem lokalen Repository ein Commit vorgenommen haben . Nun, dann müssen Sie in diesem Fall eine Drei-Wege-Zusammenführung durchführen. Und das könnte zu einem zusätzlichen Merge-Commit führen , es sei denn, Sie rebasen und führen dann eine schnelle Vorwärts wir die Eingabetaste. Hier ist eine Zusammenfassung dessen, was gerade passiert ist. Unser lokaler Zweig für neue Funktionen weist nicht auf dieses neue Commit hin. Derselbe Commit, auf den der Tracking-Zweig verwies. Was gerade passiert ist, ist ein Schnellvorlauf. Und das ist eine neue Datei, die wir in unserem Arbeitsverzeichnis sehen werden. Hier ist es. Ich möchte auch schnell erwähnen , dass der alternative Befehl dafür git merge, fetch underscore head ist. Das wird den gleichen Job machen. Und dies ist einer der Befehle , bei denen good die Datei fetch add verwenden könnte. Wir hatten vorhin darüber gesprochen. Führen Sie den Befehl aus. Es heißt schon aktuell, weil wir die Änderungen bereits zusammengeführt hatten. Hoffe es macht Sinn. Wir sehen uns als Nächstes. 76. 1006 Verwenden von Visusal Studio zum Abfassen und Zusammenführen: Okay, lassen Sie uns sehen, wie wir Fetch durchführen können , und im Grunde genommen schreiben was wir bisher in diesem Kapitel in Visual Studio Code gelernt haben . zunächst sicher, dass Sie das Projekt geöffnet haben . Wenn Sie Ihr Projekt hier nicht sehen, gehen Sie zum Menü Datei und klicken Sie auf Ordner öffnen. Wählen Sie Ihr Projekt. Und du solltest startklar sein. Lassen Sie uns zum Quellcodeverwaltungsbereich wechseln , um einen Git-Fetch durchzuführen. Klicken Sie auf dieses Icon. Und dann siehst du eine Menge Optionen. Gehen Sie zum Abschnitt Pull, Push, und dann sehen Sie die Option zum Abrufen der Änderungen. Wenn Sie zum ersten Mal darauf klicken, werden Sie möglicherweise gefragt, ob Visual Studio Code dies jedes Mal automatisch tun soll Sie können tatsächlich Ja dazu sagen, weil git-fetch wird als sicherer Betrieb angesehen. Und da es keine Auswirkungen auf Ihr Arbeitsverzeichnis haben wird , können Sie es sicher ausführen ohne sich um irgendetwas kümmern zu müssen. Und wenn Sie das getan haben, sehen Sie hier einen Status. In meinem Fall sehe ich einen und dann den Abwärtspfeil 0 und dann Kleidung. Ich bin mir nicht sicher, ob du das sehen kannst. Ein Abwärtspfeil würde jedoch bedeuten , dass wir zusätzliche Commits im Remote-Repository haben, die in ein lokales Depot zusammengeführt werden können. 0 oder pyro bedeutet , dass wir kein zusätzliches Commitment oder lokales Depository haben , das wir benötigen, um unseren Push in das Remote-Repository hochzuladen. Wir werden in den kommenden Vorlesungen darüber sprechen, wie wir unsere Änderungen an das Remote-Repository übertragen können . Wenn Sie das haben, lassen Sie uns sagen, dass Sie sich entschieden haben, viel zu spielen. Wir werden dafür dieses Drittanbieter-Plugin verwenden. Und hier können Sie sehen, dass der ursprüngliche neue Feature-Branch auf dieses Commit verweist und unser lokaler neuer Feature-Branch auf dieses spezielle Commit verweist. Ratet mal was? Ich muss diese beiden Zweige zusammenführen, um alle Remote-Änderungen in meinem Arbeitsverzeichnis zu haben . In Visual Studio Code muss ich also mit der rechten Maustaste auf den Zweig , den ich zusammenführen möchte. Und dann siehst du diese Option. Verschmelzen Sie mit der aktuellen Filiale, unseren aktuellen Zweigen und dem Zweig neuer Funktionen, wie Sie hier sehen können. Also lass uns darauf klicken. Übrigens, um Dinge zu erklären, die das Projekt wieder so gemacht haben , wie es vor dem Zusammenführen war. Also rechtsklicken Sie darauf. Magenta-aktueller Zweig. Wir haben bereits über diese Aufforderung gesprochen. Es ist genau dieselbe Aufforderung. Nichts anderes. Wir möchten jedoch keinen neuen Kommentar erstellen. Und jetzt, wenn Sie zum Arbeitsbaum gehen, sehen Sie diese Datei, was wir erwarten. 77. 1007 Aktualisieren lokaler Referenzen mit Git Fetch: Nehmen wir an, ich möchte einen Branch im Remote-Repository löschen . Was wären nun die Auswirkungen? Lass uns einen Blick darauf werfen. Bevor Sie den Zweig löschen, müssen Sie zunächst sicherstellen , dass all diese Änderungen in einem anderen Zweig zusammengeführt werden. Sie müssen auch mit allen Personen diskutieren , die aktiv an einem Beitrag zu dieser Branche beteiligt sind . Bevor du es löschst. Lassen Sie uns weitermachen und einen der Zweige löschen. Und ich lösche die Funktion zum Verzweigen, indem ich auf dieses Symbol klicke. Sie können auch einen Remote-Zweig von Ihrem lokalen Computer löschen , was in kommenden Vorlesungen explodieren wird. Nehmen wir an, das ist einer der Entwickler Computer sieht vielleicht hier aus, wenn ich den Befehl git remote show origin ausführe, würden Sie feststellen, dass Git diese Funktion als veraltet verzweigt hat . Und es hat uns auch angezeigt, diesen Befehl git remote prone zu verwenden , um diesen Zweig zu entfernen und das lokale System zu fördern. Alternativ können Sie auch den Befehl git fetch broom ausführen. Mit diesem Befehl stellt Git eine Verbindung zum Remote-Repository her. In diesem Fall würde es standardmäßig die Original-Fernbedienung verwenden. Und dann werden alle Unterschiede in Ihrer lokalen Registrierung gelöscht , die im Remote-Repository nicht mehr verwendet werden . Beachten Sie nun, dass dieser Befehl nur die Tracking-Zweige löscht, aber nicht Ihre lokalen Zweige. Ihre lokale Niederlassung würde immer noch intakt bleiben. Führen wir also diesen Befehl aus. Das hat also den Tracking-Zweig gelöscht. Wenn Sie dasselbe von Visual Studio Code aus tun möchten, klicken Sie einfach auf dieses Symbol. Gehen Sie zum Abschnitt ziehen, drücken. Und dann finden Sie diese Option mit der Aufschrift „Pflaume holen“. Das würde den gleichen Job machen wie mit diesem Befehl. Jetzt, da Sie eine lokale Pizza zum Verzweigen noch intakt haben. Und Sie könnten genauso gut Ihre eigenen Änderungen oder Commits in der Funktion haben , um zu verzweigen. Nun, du kannst all diese Commits in das Remote-Repository pushen . Und auf diese Weise würde dieser Zweig neu erstellt werden. Oder Sie können diese Kommentare auch zu einem Teil eines anderen Zweigs machen . Wir werden in den kommenden Vorlesungen über Git Push sprechen. Aber versuchen wir, diesen Befehl erneut auszuführen. Und es würde keine Funktion mehr sehen , um unter Remote-Zweigstellen zu verzweigen. Lass mich zurück zu GitHub gehen und diesen Branch wiederherstellen. Noch einmal. Führen Sie jetzt den Befehl aus. Dann heißt es, dass beim nächsten Abruf ein neuer Tracking-Zweig erstellt wird, ein neuer Tracking-Zweig erstellt wird dem das Feature verzweigt werden soll. Lass uns das ganz schnell machen. Und Sie können sehen , dass die Funktion zum Verzweigen jetzt verfolgt wird wo sie sich im Wesentlichen im gleichen Zustand wie zu Beginn dieses Videos befindet. Wir sehen uns als Nächstes. 78. 1101 Git Pull verstehen: Lassen Sie uns über Git Pull sprechen. Jetzt sag es mit mir. Git Pull entspricht git-fetch plus git merge oder rebased, je nachdem, welche Option wir wählen. Das ist im Wesentlichen das, was gutes Pull ist. Vielleicht ist dies das kürzeste Video des gesamten Kurses. Es ist jedoch möglicherweise nicht so einfach. Wir werden in den kommenden Vorlesungen ausführlicher über Good Pull sprechen . Wir sehen uns als Nächstes. 79. 1102 Git in Aktion ziehen und beobachten, was es tut: Okay, sagen wir, git pull in Aktion. Ich bin derzeit ein neuer Feature-Branch. Lass es mich zuerst im Befehl git pull ausprobieren. Und es heißt schon aktuell. Das bedeutet, dass es keine zusätzlichen Kommentare und Remote-Repositorien gibt, die noch nicht in unserem lokalen Repository vorhanden sind. Gehen Sie also zuerst zurück zum Remote-Repository und machen Sie ein neues Commit im Feature-Branch oder dem neuen Feature-Branch. Ich werde tatsächlich eine der Dateien bearbeiten. Es spielt keine Rolle , ob Sie eine neue Datei hinzufügen oder eine vorhandene Datei bearbeiten. Es geht darum, ein Commit zu machen. Also lass mich weitermachen und auf dieses Symbol klicken , um diese Datei zu bearbeiten. Ich bin mir nicht sicher, ob du das sehen kannst. Lass mich ein bisschen hineinzoomen. Lassen Sie mich einfach eine Textzeile hinzufügen, etwas in dieser Art. Es spielt keine Rolle, was Sie hinzufügen. Klicken Sie auf Änderungen übernehmen. Wenn Sie die Nachricht erhalten möchten, können Sie sie ändern und auf Commit klicken. Wir haben jetzt also zusätzliches Commit- und Remote-Repository, aber das ist in unserem lokalen Computer nicht verfügbar. Bevor ich den Befehl git pull noch einmal ausführe, lass mich git log machen und sehen, was es anzeigen muss. Wie Sie sehen können, verweisen sowohl das neue Feature als auch das neue Original-Feature, der Tracking-Zweig, auf genau denselben Commit. Lassen Sie mich den Bildschirm leeren und den Befehl git pull ausführen. Wie Sie anfangs sehen können, hat es den Git-Fetch-Vorgang ausgeführt und die neuen Objekte entpackt. Das sind also die Objekte, die aus dem Remote-Repository heruntergeladen wurden . Es gibt insgesamt drei Objekte, denen auch Commit-Objekte, drei Objekte, Blob-Objekte usw. gehören . Und dann ging es weiter und führte in diesem Fall eine schnelle Vorwärtszusammenführung durch. Da die schnelle Vorwärtszusammenführung in diesem Fall funktioniert, haben wir keine Commits in einem lokalen Branch. Und so hat Git eine schnelle Vorwärtszusammenführung für uns durchgeführt. Wenn ich jetzt git log, können Sie sehen, dass der lokale Zweig für neue Funktionen sowie der Tracking-Zweig diesen neuen Commit verweisen , der genau der Commit ist, der gerade einen Moment gemacht wurde vor. Es ist f phi double d, was auch immer. Und es ist derselbe HashCode, den du hier siehst. Zuvor mit git-fetch wurde unsere lokale Niederlassung nicht aktualisiert. Aber mit git pull haben wir nicht nur alle Objekte und Referenzen abgerufen, sondern auch den aktuell überprüften Punktzweig aktualisiert. Eine Sache, die ich erwähnen sollte , ist , dass der ganze gute Pull-Befehl die Objekte und Referenzen herunterlädt die Objekte und Referenzen zu mehreren Zweigen oder sogar Remotes gehören. Es wird viel auf dem aktuell ausgecheckten Zweig leisten . Wenn wir also git pull gemacht haben, entspricht dies git pull origin, da dies nur der Modus ist , der derzeit konfiguriert ist , und es ist der Standard. Wenn Sie möchten, können Sie aber auch die Fernbedienung angeben , von der Sie Objekte abrufen möchten. Führen Sie dann die Zusammenführung den aktuell überprüften Punktzweig durch , der in diesem Fall ein neuer Feature-Branch ist. Wir sehen uns als Nächstes. 80. 1103 Git Pull mit 3way Fusion verstehen: Lassen Sie uns nun sehen, was passieren würde, wenn wir Commits sowohl im Remote- als auch im lokalen Depository vorgenommen hätten. Dies soll ein Szenario simulieren, in dem Sie möglicherweise Commits in Ihrem lokalen Repository vorgenommen haben und nur wenige Kommentare im Remote-Repository auch von anderen Entwicklern stammen könnten . Um dieses Verhalten zu simulieren, versuchen wir zunächst ein Commit in unserem lokalen Repository durchzuführen. Wenn ich git pull starte, siehst du, dass unser Repository bereits auf dem neuesten Stand ist. Lass mich schnell, ich habe eine der Dateien hier gemacht. Bearbeiten wir zum Beispiel diese Datei. Die Datei wurde gespeichert, bleibt die Datei. Sie können das alles tatsächlich von Visual Studio Code aus tun, aber es ist nur meine persönliche Präferenz es von Git Bash aus zu tun. Ich fühle mich eher wie ein Programmierer, wenn ich es von Git Bash aus mache , als Visual Studio Code zu verwenden. Also füge Apple Dot TXT hinzu. Gute Commit-Nachricht. Und wir haben uns verpflichtet. Gehen wir zu unserem Remote-Repository und lassen Sie uns einige Änderungen und die Datei input.txt vornehmen. Vielleicht möchte ich noch eine weitere Textzeile hinzufügen. Und begehen Sie diese Änderungen. Kannst du jetzt das Verhalten erwarten als wir versucht haben, git pull zu machen? Stellen Sie sich nun vor, wir führen Git-Fetch durch und führen dann Git Merge durch. Was Sie erwarten, ist genau das, was passieren würde, wenn Sie den Befehl git pull ausführen. Eigentlich müssen wir den Modus nicht angeben. Wie Sie sehen, haben wir uns dazu veranlasst, die Nachricht auszuwählen. Kannst du erraten, worum es hier geht? Nun, das ist die Nachricht, die wir gebeten werden, uns für das neue Merge-Commit-Objekt zu entscheiden , das es erstellen wird. Dies hat im Wesentlichen eine Dreiwege-Zusammenführung durchgeführt. Und get wird jetzt auch das Merge-Commit erstellen. Nehmen wir an, ich bin mit dieser Nachricht zufrieden. Ich werde das einfach schließen. Und der Befehl würde weiter ausgeführt werden. Dieses Mal. Wenn ich git log, können Sie sehen, dass der lokale Zweig auf das neue Merge-Commit verweist. Aber der Tracking-Zweig zeigt erwartungsgemäß immer noch auf den Commit , auf den der entsprechende Remote-Branch verweist. Dies ist der Commit , den wir gerade aus dem Remote-Repository heruntergeladen haben. Was ist, wenn ich dieses zusätzliche Merge-Commit nicht von Git erstellt haben möchte , ist Rebase die Antwort. Und darüber werden wir in unserem nächsten Video sprechen . Wir sehen uns als Nächstes. 81. 1104 GIt ziehen mit Rebase und es ist Auswirkungen: Okay, lass uns sehen, wie wir Rebase mit Git Pull verwenden können. Wenn ich den Befehl git pull ausführe, kannst du sehen, dass es bereits auf dem neuesten Stand ist. Es müssen keine zusätzlichen Objekte aus dem Remote-Repository heruntergeladen werden . Aber lassen Sie mich versuchen, im Remote-Repository ein Commit zu machen. Und 1 Sekunde, ich bearbeite einfach diese Datei und mache ein Commit. So wie. Lassen Sie mich auch in unserem lokalen Depot eine Verpflichtung eingehen. Ich werde diese Datei mit dem VI-Editor bearbeiten. Sie können Notepad oder Visual Studio Code verwenden . Es liegt an dir. Stage diese Datei, git commit. Lassen Sie uns nun versuchen, die Rebase-Option git pull zu machen und zu sehen, was passieren wird. Da Sie die Zusammenführung durchführen, holen Sie sich ein Wort. Versuchen Sie nun, ein Rebase durchzuführen. Mit diesem Befehl werden alle Objekte heruntergeladen und festgeschrieben. Im Wesentlichen würde sich unsere lokale Niederlassung in demselben Zustand wie dieser Zweig im Remote-Repository befinden. Und dann wendet get alle lokalen Limit-Commits nacheinander erneut an. Danach. Ich zeige dir, was ich meine. Dies hat also die Objekte heruntergeladen und auch das Rebasing durchgeführt. Aber wenn Sie den Befehl git log jetzt ausführen, Sie feststellen, dass all diese Kommentare werden Sie feststellen, dass all diese Kommentare bis zu diesem Zeitpunkt im Wesentlichen dem Handel entsprechen, den wir im Remote-Repository haben. Darüber hinaus hat get die lokal gemachten Kommentare erneut angewendet. Dies ist genauso, als hätten Sie das Projekt aus dem Remote-Repository geklont . Und dann hast du deine lokalen Commits nacheinander gemacht. Dies kann besser in Visual Studio Code mit Git-Plug-In gesehen werden. Also hier sind wir. Wie Sie sehen können, gehören diese Kommentare unten zum Remote-Repository. Sie können es erkennen, indem Sie sich den Autobereich ansehen. Alle diese Kommentare wurden von Centre Corp. abgegeben. Und darüber hinaus wurden unsere lokalen Commits zusätzlich zu den Remote-Commits neu erstellt abgegeben. Und darüber hinaus wurden unsere lokalen Commits zusätzlich zu den Remote-Commits neu . Und deshalb waren sie hinter ihnen her. Aber wenn Sie es bemerken, haben wir nicht das Merge-Commit , das wir zuvor hatten. Aber das ist der Zweck von Rebase, das im Wesentlichen darin besteht, diese Merge-Commits nicht zu haben. Rebase schreibt im Wesentlichen deine Commits und selbst hashCode wäre nicht derselbe. Wenn Sie sich zum Beispiel den letzten Commit ansehen, den Sie für ein lokales Depository erstellt haben, ist der aktuelle HashCode phi, um was auch immer zu sein. Wenn Sie sich genau diesen Commit vor dem Rebasing ansehen würden , wäre der HashCode anders gewesen. Dies ist der Grund, warum all das Rebased unseren Commit-Verlauf linearer erscheinen lässt. Es sollte nicht rebasen, wenn Sie alle Ihre Änderungen bereits im Remote-Repository veröffentlicht haben . Wir werden in den kommenden Vorlesungen über Git Push sprechen und darüber, wie wir deine lokalen Commits in das Remote-Repository pushen können deine lokalen Commits in das Remote-Repository . Und dann haben Sie eine bessere Klarheit darüber, wovon ich spreche . Wir sehen uns als Nächstes. 82. 1105 Umgang mit Konflikten mit der Git Pull Rebase: Lassen Sie uns sehen, was passieren würde, wenn es während der Durchführung zu Konflikten kommen würde. Lassen Sie mich dafür diese Datei noch einmal bearbeiten. Ich füge einfach noch eine weitere Codezeile hinzu. Und begehen Sie die Änderungen. Wir haben Änderungen an einer Info-Punkt-TXT-Datei vorgenommen. Lassen Sie mich dieselbe Datei auch in meinem lokalen Repository oder auf meinem lokalen Computer lesen . Lassen Sie mich eine Textzeile hinzufügen, so speichern Sie die Datei, die Datei bereit und machen Sie einen Commit. Neue Bearbeitung, Infodatei, was auch immer. Lass mich jetzt versuchen, Git Pull zu machen und wir sollten einen Konflikt bekommen. Ich möchte die Rebase-Option verwenden , weil ich das Merge-Commit nicht sehen wollte. Aber es liegt an dir. Und wie Sie sehen können, ging unser Projektarchiv in den Rebase-Zustand über. Wenn wir diese Option nicht anbieten, wäre dies eine Verschmelzung von Zustand a. Die Art und Weise, wie wir die Konflikte auf die eine oder andere Weise lösen müssen. Wir haben bereits in unseren früheren Kapiteln gesehen, wie wir Konflikte bei gets off, merge und rebase lösen können in unseren früheren Kapiteln gesehen, wie wir Konflikte bei gets off, merge und rebase lösen . Gleiches gilt auch hier. Sie können also entweder entscheiden , die Konflikte zu lösen oder Sie können diesen Befehl verwenden , um den Commit zu überspringen , der einen Konflikt verursacht. Ich werde genau das tun. Aber wenn Sie die Konflikte bearbeiten und lösen möchten, wissen Sie bereits, wie das geht. Rebase war erfolgreich. Und wenn ich git log und den Commit , den wir gerade in unserem lokalen Depot gemacht haben, nicht sehe . Das liegt daran, dass wir die Optionen skip bereitgestellt hatten, um den Commit zu überspringen, der zu Konfliktenden führt. Wir werden nicht sehen, dass das zur Sprache kommt. Aber wenn Sie bemerken, dass die Tracking-Zweige auf das neueste Commit im Remote-Repository verweisen , hoffe ich, dass es Sinn macht. Wir sehen uns als Nächstes. 83. 1106 Verwenden von Stashing und Hard Reset: Lass uns über die Bedeutung des Versteckens sprechen. Nehmen wir an, wir haben ein neues Komitee und Remote-Repository. Dafür. Lassen Sie mich die Eingabepunkt-TXT-Datei bearbeiten und eine Textzeile hinzufügen. So wie. Übernehmen Sie die Änderungen. Nehmen wir an, in meiner lokalen Registrierung bearbeite ich dieselbe Datei und füge eine Textzeile hinzu, speichere die Datei und schließe sie. Wenn ich jetzt zu Git Bash gehe und den Befehl git pull ausführen würde, beachte, dass ich diese Änderungen nicht inszeniert oder festgeschrieben habe. Ich möchte sie nicht festlegen weil ich immer noch daran arbeite. Gleichzeitig möchte ich alle Änderungen aus dem Remote-Repository abrufen , um mein Arbeitsverzeichnis zu aktualisieren. Wenn ich diesen Befehl ausführe, werden Sie sehen, dass Fetch erfolgreich durchgeführt wurde, aber die Zusammenführung nicht stattgefunden hat. Es besagt, dass Ihre lokalen Änderungen an den folgenden Dateien durch Zusammenführen außer Kraft gesetzt werden. In for R dxdy, bitte schreiben Sie Ihre Änderungen fest, bevor Sie zusammenführen, und daher hat es den Mod-Vorgang abgebrochen. Lassen Sie sich im Wesentlichen verwirren, was mit diesen nicht festgeschriebenen Änderungen zu tun ist. Eine Lösung dafür ist, und dies wird nicht empfohlen. Der Befehl, den ich gerade ausführen werde, kann tatsächlich die gesamte Arbeit löschen, die Sie bisher auf Ihrem lokalen Computer geleistet haben. Und dazu gehören auch die Änderungen, die wir gerade in for art file eingeführt haben. Offensichtlich ist dies kein empfohlener Ansatz. Aber lass mich dir den Befehl git reset zeigen. Wir haben diesen Befehl bereits in der Vergangenheit verwendet. Und dann werden Sie die Option schwer anbieten. Und Sie würden die Fernbedienung angeben. Mal sehen, was das bewirken wird. Wenn ich git log tippe, wirst du alle Kommentare sehen, die wir lokal gemacht haben oder die jetzt endgültig verschwunden sind. Und genau das ist dieser Befehl sehr gefährlich. Es diente jedoch dazu, die Änderungen aus dem Remote-Repository abrufen zu können. Wenn Sie hierher gehen, sehen Sie, dass wir nur diese beiden Dateien haben. Lassen Sie uns git pull machen , um alle Änderungen aus dem Remote-Repository abzurufen. Und jetzt ist unser Arbeitsverzeichnis auf dem neuesten Stand. Im Grunde unser lokales Depot sowie Remote-Repository, oder genau im gleichen Zustand. Dies ist jedoch offensichtlich nicht der empfohlene Ansatz. Versuchen wir also, dasselbe Szenario noch einmal nachzubilden. Und lassen Sie mich Ihnen erklären, wie wir damit umgehen müssen. Ich möchte diese Änderungen nicht festlegen. Aber gleichzeitig möchte ich die Updates aus dem Remote-Repository erhalten . Lass mich zurück zu GitHub gehen und diese Datei noch einmal bearbeiten. Was auch immer. Lass uns jetzt versuchen, Git Pull zu machen. Und natürlich werden Sie wieder sehen, wie viel abgebrochen wird. So wie. Was ist jetzt die Lösung? Die Lösung ist der Befehl git stash. Im Grunde speichert dieser Befehl unsere lokalen Änderungen vorübergehend irgendwo und wir können sie abrufen, wann immer wir wollen. Vorerst, da unsere lokalen Änderungen Probleme verursachen. Um die Änderungen aus dem Remote-Repository abzurufen, lassen Sie mich sie speichern. Wie Sie sehen können, gespeichert, einen Baum entlang zu gehen und Datum zu indizieren, Arbeitsfortschritt an der neuen Funktion. Es zeigt auf die Datei input.txt. Wenn Sie jetzt in einer Vollpunkt-TXT-Datei öffnen, werden Sie die Änderungen, die ich gerade eingeführt habe, nicht sehen . Jetzt können wir weitermachen und git rebase machen. Kehren Sie zum Arbeitsverzeichnis zurück. Sie sollten alle Remote-Änderungen sehen. Jetzt können wir alle Änderungen, an denen ich zuvor gearbeitet habe, mit dem Befehl git stash, pop zurückbringen Änderungen, an denen ich zuvor gearbeitet habe . Jetzt können wir natürlich den Komplex zurückgehen und die Datei input.txt öffnen. Sie werden sehen, dass dies die Änderungen sind, die von Upstream kommen. Upstream wie im Remote-Repository. Wir können entscheiden , welche Änderungen wir weiter bearbeiten möchten, um diese Datei zu bearbeiten, wie Zelle, die Datei schließen, die Datei bleiben. Git-Status. Wenn ich mich jetzt entscheide, meine Änderungen zu übernehmen, kann ich das tun. Aber in der Lage, die Änderungen aus dem Remote-Repository abzurufen , ohne unsere vorhandenen Änderungen übernehmen zu müssen . 84. 1201 Alles einrichten für die Beigabe von Mitarbeitern Hinzufügen von Anmeldeinformationen und die Erstellung von c: Okay, lassen Sie uns sehen, wie wir unsere lokalen Änderungen oder die lokalen Commits das Remote-Repository übertragen können, damit alle anderen im Team diese Änderungen tatsächlich herunterladen und alle verwenden können, über sie zu laufen. Um die Dinge besser zu erklären, sollten wir die Dinge jetzt bereinigen und alles von Grund auf neu tun , als ob gerade jemand dem Team beigetreten wäre und bereit zu unserem Projektarchiv beizutragen. Zunächst möchte ich mich als Eigentümer des Repositorys anmelden. Ich habe mich als Sunda eingeloggt. Das ist ein Saunders GitHub-Konto. Und hier ist der Besitzer dieses öffentlichen Repositorys. Ich gehe zu den Einstellungen und füge dann Herrn Luke als Mitarbeiter hinzu. Ich erwarte einen Beitrag von Herrn Luke zu diesem Projektarchiv. Wie Sie sehen können, haben wir gerade Herrn Luke als Mitarbeiter hinzugefügt . Ich habe auch alle Zweige gelöscht , die wir zuvor erstellt hatten, außer dass ich den Hauptzweig unverändert gelassen habe. Wir haben derzeit also eine Filiale. Alle Zweige wurden gerade gelöscht. Nur damit wir alles klar und deutlich verstehen. Gehen wir jetzt zu Lukes Konto. Man merkt, dass dies Lukes Bericht ist , weil es das weiße Thema hat. Hier ist die E-Mail , die unter erhalten wurde , um die Einladung anzunehmen , an diesem Projekt mitzuarbeiten. Ich werde genau das tun. Das nächste, was diese Schleife tun muss, ist den HTTPS-Link zu kopieren und das Projekt zu klonen. Zu diesem Zweck wurde tatsächlich ein neues Verzeichnis mit dem Namen get erstellt . Und hier werden wir mit den Dingen experimentieren. Lass mich Git Bash hier starten. Und klonen wir das Projekt git clone. Und dann füge ich die URL ein. Dadurch wird das Projektarchiv geklont. Eine weitere Sache, die wir sicherstellen müssen , betrifft die Anmeldeinformationen. Geben wir den Befehl git config list ein , damit wir alle Konfigurationen sehen können. Und wie Sie sehen können, ist der Benutzername mein Name und die E-Mail ist etwas anderes, nicht Lukes. Dies ist jetzt nicht zwingend erforderlich , um diese Anmeldeinformationen zu aktualisieren. Aber was sind die Referenzen , die Sie hier angeben was sich auch in konkreten Objekten widerspiegeln würde. Wenn Sie also lokale Commits vornehmen, werden diese Anmeldeinformationen aufgezeichnet und dieselben Anmeldeinformationen werden auch im Remote-Repository angezeigt. Nachdem Sie alle diese Commits an das Remote-Repository übertragen haben, es sinnvoller, Lukes Anmeldeinformationen hier zu haben , da er derjenige ist, der zum Projektarchiv beiträgt. Lassen Sie uns also weitermachen und diese Anmeldeinformationen ändern. Benutzer.name. Ich gebe den gleichen Benutzernamen wie den GitHub-Konto von Luke an. Das heißt auch, die E-Mail in Lukes E-Mail zu ändern. So wie. Wenn Sie jetzt die Anmeldeinformationen überprüfen, können Sie sehen, dass diejenigen, die aktualisiert wurden. Nehmen wir nun an, dass Luke die Aufgabe hatte , an Feature Eins zu arbeiten. Ratet mal, was er tun wird? Nun, er würde einen weiteren Zweig erstellen und alle Änderungen in Bezug auf Feature eins beitragen. Lass uns das ganz schnell machen. Ich werde das von Visual Studio-Code aus machen. Wenn du möchtest. Du kannst es auch von Git Bash aus machen. Ich werde den Ordner mit VS-Code öffnen. Und vielleicht füge ich einfach eine zusätzliche Datei hinzu. Aber vorher müssen wir eine Filiale erstellen. Wie Sie sehen können, befinden wir uns derzeit in der Hauptniederlassung. Lassen Sie mich darauf klicken und Feature eins eingeben. Wir haben diese Filiale noch nicht. Wir haben diesen Branch nicht einmal im Remote-Repository. Lassen Sie mich diese Option wählen , um diesen Zweig für uns zu erstellen. Visual Studio Code hat diesen Zweig erstellt und auch zu diesem Zweig gewechselt. Lassen Sie mich jetzt eine Datei hinzufügen. Nennen wir es Produkt Dot TXT. Zeile eins, Feature eins, so etwas. Ich verwende den gleichen Text wie die Commit-Nachricht. Lassen Sie uns die Nachricht eingeben und diese Änderungen in einem lokalen Feature-Ein-Branch übernehmen. Lassen Sie uns vielleicht auch noch eine Kommentarzeile machen, um sie zu mögen , wenn wir sie kopieren und als Botschaft für diesen Kometen haben. Schauen wir uns die Grafik an. Wie Sie sehen können, haben wir hier den Hauptzweig und den Feature-Branch , der ein paar Kommentare vor dem Hauptzweig liegt. Nehmen wir an, Luke hat alles getan , was er für Feature One tun muss. Er hat all diese Änderungen lokal getestet. Und jetzt ist er bereit, all diese Commits zum Remote-Repository beizutragen oder zu pushen. Wie er das machen wird, werden wir als Nächstes besprechen. 85. 1202 Erstellen eines remote und Ändern mit Git Bash und VSCode Pushing an alle Branche: Derzeit haben wir einen Zweig , der lokal erstellt wurde, und wir haben sogar eine Reihe von Kommentaren darin abgegeben. Lassen Sie uns nun sehen, wie wir all diese Commits in das Remote-Repository übertragen können . Aber bevor du etwas tust, ist das sehr wichtig. Sie müssen sicherstellen, dass Sie alle Änderungen aus dem Repository ziehen und neu erstellen, unabhängig von der Marke , zu der Sie Ihren Feature-Eins-Zweig zusammenführen möchten . Sie möchten alle Änderungen dieses Zweigs ziehen und Ihren Feature-Eins-Zweig in diesen Zweig neu aufbauen. Das wird also einen linearen Commit-Verlauf haben. Und wenn Sie auf Konflikte stoßen, Bitte lösen Sie diese, damit Sie keine Konflikte haben, wenn Sie tatsächlich alle Ihre Änderungen pushen oder alle Ihre Änderungen in das Remote-Repository hochladen. Wie das geht, haben wir bereits in unserem vorherigen Kapitel gesehen . In unserem Fall wurden der Hauptzweig und das Feature in der Branche jedoch nicht veröffentlicht. Es macht für mich keinen Sinn, wirklich zu rebasen. Sehen wir uns nun an, wie wir unsere Änderungen an das Remote-Repository übertragen können . Schauen wir uns zunächst an, wie wir das von Git Bash aus machen können. Lass mich den Bildschirm räumen. Gehen wir also zuerst in dieses Verzeichnis. Und ich bin derzeit in Feature One Branch, wie Sie hier sehen können. Aber es ist nicht wirklich wichtig für den Befehl, den wir ausführen werden. Ich werde git push sagen und das sagen, dass das aktuelle Branch-Feature One keinen Upstream-Zweig hat. Mit anderen Worten, es heißt , dass wir keinen Zweig im Remote-Repository haben , um den aktuellen Zweig zu pushen und die Remote als Upstream festzulegen. Verwenden Sie diesen speziellen Befehl. Also lass es mich kopieren und hier einfügen. Dieser Befehl würde also im Wesentlichen einen Branch im Remote-Repository erstellen und alle Commits, die wir in diesem Zweig haben, pushen. Origin ist die Fernbedienung, die wir verwenden. Wenn Sie eine andere Fernbedienung verwenden möchten, können Sie den Namen hier angeben. Und diese Option ermöglicht es uns tatsächlich, den Branch im Remote-Repository zu erstellen. Mit diesem Befehl werden auch der Track-Hauptzweig und das gesamte lokale Depository für Feature-Eins-Zweig erstellt der Track-Hauptzweig und das gesamte lokale Depository für , der den Feature-Eins-Zweig im Remote-Repository darstellt . Versuchen wir, diesen Befehl auszuführen. Git hat im Wesentlichen alle Objekte komprimiert und das Remote-Repository hochgeladen. Und das ist der URI , mit dem alle unsere Commits gepusht wurden. Darüber hinaus hat es für uns eine Tracking-Filiale eingerichtet. Und es schlägt uns auch vor, einen sogenannten Pull Request zu erstellen. Gehen Sie zu dieser URL. Wir werden in den kommenden Vorlesungen über Pull Requests sprechen . Aber jetzt gehen wir zum GitHub-Repository und schauen ob sich die Dinge dort widerspiegeln. Lassen Sie mich diese Seite aktualisieren. Und jetzt siehst du zwei Zweige. Und wir können sogar auf einen Zweig wie diesen umsteigen. Und Sie sehen hier nach Kometen, zwei von ihnen gehören zum Hauptzweig. Und dann gibt es ein paar Kommentare in Feature One Branch. Lassen Sie uns schnell einen weiteren Kommentar abgeben und sehen, wie wir unsere Änderungen mithilfe von Visual Studio-Code vorantreiben können. Lassen Sie mich einfach eine weitere Code - oder Textzeile hinzufügen . So wie. Ich verwende den gleichen Text wie die Commit-Nachricht. Lassen Sie mich diese Datei speichern und unsere Änderungen übernehmen. Also haben wir nur noch ein Commit gemacht. Dieses Mal werde ich Visual Studio Code verwenden , um unsere Änderungen voranzutreiben. Sie sehen diese Option, drücken Sie. Da wir nur eine Fernbedienung haben, ist die Herkunft des Namens. Standardmäßig wurde dies auf die einzige Fernbedienung verschoben, die verfügbar ist. Wenn Sie mehrere Fernbedienungen konfiguriert hätten, hätten Sie die Option die Fernbedienung auszuwählen, bei der Sie all diese Änderungen in 1 Sekunde übertragen möchten . Gehen wir zurück zum Aufstehen. Und wenn ich die Seite aktualisiere, wirst du auch dieses neue Commit sehen. Es kann Fälle geben , in denen Sie Änderungen, die zu mehreren Zweigen gehören, pushen möchten . In diesem Fall können Sie die Option verwenden, um alle Änderungen zu übertragen , die zu mehreren Zweigen gehören. Es wird jedoch nicht empfohlen. Es ist immer eine gute Idee, jeweils einen Zweig zu bearbeiten. Ich sollte auch erwähnen, dass Sie beim ersten Versuch, Änderungen vorzunehmen, möglicherweise tatsächlich aufgefordert werden sich bei Ihrem GitHub-Konto anzumelden. In meinem Fall habe ich dieses Braun nicht bekommen, weil ich mich schon einmal angemeldet habe. Lass mich dir zeigen, was ich meine. Lassen Sie mich den Credential Manager unter Windows öffnen , indem Sie im Startmenü suchen. Und wenn ich zu Windows-Anmeldeinformationen gehe, siehst du eine für GitHub. Und hier wurden die Anmeldeinformationen von Lukes Konto gespeichert. Das liegt daran, dass ich mich bereits angemeldet habe und Windows all diese Anmeldeinformationen speichern kann , sodass ich diese Anmeldeinformationen nicht eingeben muss. Jedes Mal habe ich versucht, mit dem Remote-Repository zu interagieren . Falls Sie beim Ausführen des Befehls eine 403 sehen, versuchen Sie, diese Anmeldeinformationen zu entfernen und versuchen Sie dann erneut, den Befehl auszuführen. Also, Sie werden aufgefordert, sich erneut anzumelden, melden Sie sich an und schon können Sie loslegen . Lass es mich tatsächlich entfernen. Und lassen Sie mich versuchen, die Änderungen voranzutreiben. Und wie Sie sehen können, habe ich diese Aufforderung zur Authentifizierung erhalten. Lass mich zu Lukes GitHub-Konto, github.com, gehen, Login-Slash-Gerät. Lassen Sie mich diesen Code hier eingeben. Steuerung C und Kontrolle V, weiter. Und Arthritis. Lassen Sie uns den Bus betreten. Das Lebensmittelgerät wurde authentifiziert. Und natürlich, da wir nichts zu pushen haben, sollten Sie diese Nachricht beachten , dass alles auf dem neuesten Stand ist. Aber wenn du hierher zurückkehrst, wirst du diesen Eintrag noch einmal sehen . Wir sehen uns als Nächstes. 86. 1203 Verstehen von Pull-Request zur Erhöhung einer Request: Okay, bisher haben wir einen lokalen Feature-Eins-Zweig erstellt und dann eine Reihe von Commits darin gemacht. Und wir haben all diese Änderungen sogar in das Remote-Repository übertragen . Und hier sind all diese Änderungen im Remote-Repository vom GitHub-Konto. Da es sich um ein öffentliches Repository handelt, kann natürlich jeder all diese Änderungen sehen. Jetzt kann loop nicht einfach versuchen, all diese Änderungen auf dem Hauptzweig zu emergen. Es gibt bestimmte Praktiken, die befolgt werden müssen. Und diese Praktiken sind vorhanden, um sicherzustellen, dass das, was in den Mainstream der Evolution, dem Hauptzweig, gelangt , sauberer Code ist. Was wir also als Nächstes tun müssen, bevor wir dieses Feature, das man ändert, tatsächlich in den Hauptzweig zusammenführen, ist tatsächlich einen Pull Request auszulösen. Was ist ein Pull Request? Sie können sich einen Pull Request als eine Überprüfungsanfrage vorstellen. Im Wesentlichen bitten Sie jemanden, anderen Worten, jemanden in Ihrem Team, andere Mitarbeiter oder den Repository-Besitzer, alle Ihre Änderungen zu überprüfen , bevor sie in die Mainstream der Evolution, der Hauptzweig. Und Sie fragen sich vielleicht, warum dies als Pull Request bezeichnet wird. Dieses Wort könnte Sinn machen, wenn wir in diesem Kurs voranschreiten. Aber im Moment können Sie sich das vorstellen wenn Sie eine Anfrage stellen, um alle Änderungen an Feature One in den Hauptzweig zu übertragen. Mal sehen, wie wir einen Pull Request stellen können . Ich bin derzeit in Lukes GitHub-Konto. Ich möchte zu diesem Abschnitt gehen, Pull Requests. Derzeit haben wir kein Produktquiz. Erstellen wir eine, indem wir auf diese Schaltfläche klicken. Neue Pull-Anfrage. Hier werden wir alle Änderungen auffüllen , die wir in Feature One Branch vorgenommen haben. Wie werden wir das machen, indem wir unseren Feature-1-Branch mit einem der anderen Zweige vergleichen . In diesem Fall werden wir Feature 1-Zweig mit dem Hauptzweig vergleichen . Der Unterschied zwischen den beiden sind also die Änderungen, die wir in der Funktion auf Branch eingeführt haben. Hier wähle ich die Hauptniederlassung als eine der Filialen. Und der andere Zweig würde einen Zweig enthalten. Sie werden also eine Liste der eingeführten Änderungen sagen und einen Zweig enthalten , da dies die Änderungen sind , die im Hauptzweig nicht vorhanden waren. Und wenn Sie an all diesen Änderungen mehrere Dateien beteiligt hätten , würden Sie all diese Änderungen auch hier sehen. Aber da unser ganzes Genie in einer einzigen Akte steckt , sehen Sie das hier. Und es heißt, dass eine geänderte Datei angezeigt wird. Aber wie auch immer, hier ist die ganze Liste der Commits, alle Dateien, die tatsächlich mit all diesen Kommentaren geändert wurden . Lass uns weitermachen und einen Pull Request erstellen. Wir können eine kurze Zusammenfassung darüber schreiben worum es bei diesem Pull Request geht. Wir stellen Feature Eins vor, etwas in dieser Art. Wenn du möchtest, kannst du auch einen Kommentar hinterlassen. Und lass uns auf Pull Request erstellen klicken. Jetzt bekommen wir tatsächlich diese Option, die Pull-Requests zusammenführt. Und wenn ich auf eine dieser Optionen klicke, führt dies tatsächlich dazu, dass alle Änderungen an Feature One mit dem Hauptzweig zusammengeführt werden. Dies ist jedoch keine gute Vorgehensweise. Idealerweise möchten wir, dass jemand Änderungen überprüft oder ändert bevor wir sie in den Mainstream der Evolution integrieren. Zu diesem Zeitpunkt ist Luke in der Lage, all diese Änderungen tatsächlich zusammenzuführen. Es gibt eine Möglichkeit, dies einzuschränken und wir werden als Nächstes darüber sprechen. 87. 1204 Schutz vor geschützten Zweigen zu verstehen: Lassen Sie uns sehen, wie wir Luke daran hindern können, den Code zusammenzuführen , es sei denn, es gibt mindestens eine Überprüfung durch eine andere Person. Lassen Sie mich dafür zu einem GitHub-Konto in der Dämmerung gehen. Ich gehe zum Einstellungsbereich dieses Repositorys. Ich habe zwei Filialen. Und hier füge ich eigentlich sogenannte Branch-Schutzregeln hinzu. Wenn ich mindestens eine Verzweigungsvorhersageregel für einen bestimmten Branch hinzufüge , wird dieser Branch als geschützter Branch bezeichnet. Alle Zweige , in denen wir keine Regeln zur Branch-Vorhersage haben , oder nicht geschützte Branches. Beachten Sie einfach diese Terminologien. Sie werden sich in einer Weile als nützlich erweisen. Lassen Sie mich auf diese Schaltfläche mit der Aufschrift Produktionsregeln für Zweige hinzufügen“ klicken. Hier können wir das Verzweigungsmuster angeben. In diesem Fall sage ich einfach main. Auf alle Zweige , die mit diesem Muster übereinstimmen , würden alle diese Produktionsregeln angewendet. Natürlich würden nur die Regeln, die wir hier aktiviert haben, auf die Zweige angewendet , die mit diesem Muster übereinstimmen. Jetzt werden wir in den kommenden Vorlesungen über einige dieser Regeln sprechen . Aber im Moment möchte ich eine Einschränkung festlegen, dass eine Überprüfung von Atlas One durchgeführt werden sollte bevor Änderungen in den Hauptzweig zusammengeführt werden. Also werde ich diese Option aktivieren, die besagt, dass vor dem Zusammenführen ein Pull Request erforderlich ist. Und die Beschreibung besagt, dass , wenn wir diese Option aktivieren Hall-Commits an einen nicht geschützten Branch vorgenommen werden müssen, wenn wir diese Option aktivieren. In diesem Fall zielen wir also auf die Hauptniederlassung ab. Ich werde diese Zweigschutzregel auf den Hauptzweig anwenden . Wenn Sie dies aktivieren, kann niemand direkt im Hauptzweig ein Commit ausführen. Was sie tun müssen, ist, dass sie zuerst alle Änderungen in einem nicht geschützten Zweig festschreiben müssen . beispielsweise einen Branch bereit, der nicht geschützt ist, und lösen Sie dann einen Pull Request um all diese Änderungen mit dem Haupt-Branch zusammenzuführen. Das sagt diese Option aus. Wenn das verwirrend klingt, würde ich Sie bitten, einfach zurückzugehen und dieses Video noch einmal anzusehen , bis Sie es verstanden haben. Und dann haben wir diese Option , die besagt, dass Genehmigungen erforderlich sind. Und hier können wir die Anzahl der Zulassungen wählen. Wir benötigen die Anzahl der Code-Review-Genehmigungen, die wir benötigen, bevor wir diese Änderungen unter dem Hauptzweig zusammenführen können . Lassen wir es bei der Standardeinstellung. Und lass uns auf Erstellen klicken. Wir werden in den kommenden Vorlesungen noch einmal darüber sprechen wie die anderen Branchenvorhersagen gelten , wie die anderen Branchenvorhersagen gelten . Lassen Sie mich schnell das Passwort eingeben. Und wir haben eine Verzweigungsvorhersage-Regel für den Hauptzweig erstellt. Kehren wir jetzt zu Lukes GitHub-Konto zurück. Wenn ich die Seite dieses Mal neu lade, könnte Luke diese Änderungen nicht mehr zusammenführen. Und schauen Sie jetzt, dass eine Überprüfung erforderlich ist. Standardmäßig kann jetzt jeder Mitarbeiter im Team oder der Repository-Besitzer die Änderungen anzeigen. Wenn du dieses Verhalten ändern willst, müssen wir tatsächlich eine dieser Unternehmensmitgliedschaften von GitHub übernehmen dieser Unternehmensmitgliedschaften von , damit wir die Feinkörnigkeit kontrollieren können. Im Moment. Darüber haben wir keine Kontrolle. 88. 1205 Überprüfen und Genehmigen der Änderungen Arbeiten an review und Veröffentlichung neuer Änderungen: Gehen wir also zu einer Sekunde, um die von Herrn Luke vorgenommenen Änderungen zu überprüfen. Dies kann auch ein Bericht eines anderen Mitarbeiters in diesem Projektarchiv sein. Sie können es auch überprüfen. Und was sie tun müssen, um alle von Luke vorgenommenen Änderungen zu überprüfen , ist, dass sie in den Abschnitt Pull Request gehen. Klick es an. Und dann wird es in der Lage sein, diese Option zu sehen, fügen Sie Ihre Bewertung hinzu. Und hier können sie tatsächlich alle Änderungen überprüfen. Wenn sie mit diesen nicht zufrieden sind, können sie tatsächlich einen Kommentar hinterlassen und sagen: Bitte aktualisiere eine andere Zeile, etwas in dieser Art. Und anstatt die Option pro zu wählen, werde ich Request Changes festlegen, was bedeutet, dass ich mit dem eingeführten Code nicht wirklich zufrieden bin . Ich möchte versuchen, diese Updates basierend auf meinem Kommentar zu veröffentlichen. Dann möchte ich noch einmal überprüfen. Klicken wir also auf Bewertung absenden. Auf Lukes Konto. Er wird sagen, dass sich das ändert oder darum gebeten wird. Er wird die Bewertung sehen können. So wie. Hier ist der Kommentar von cylinder. Bitte aktualisiere eine weitere Zeile. Was Luke also tun wird, wird tatsächlich alle Änderungen einbringen, die auf dem Kommentar des Rezensenten basieren. Etwas in dieser Art. Lassen Sie uns diese Änderung begehen. Wir können all diese Änderungen vorantreiben. Alternativ können wir auch auf diese Schaltfläche klicken, die besagt, dass sich die Synchronisierung ändert. Das wird also unsere Änderungen vorantreiben. Und wenn es irgendwelche Änderungen gibt, die nach oben gezogen werden müssen, müssen Sie auch getan werden. Kehren wir zu GitHub zurück. Und diese Änderungen hätten gegenwärtige und zukünftige Branchen sein sollen. Und wie Sie sehen können, können wir diesen neuen Commit sehen. Jetzt müssen wir keine weitere Umfrage-Anfrage stellen. Die vorhandene Pool-Anfrage würde automatisch aufgefüllt werden. Kehren wir ganz schnell zum Absenderkonto zurück. Und Nelson Lord kann ein Update sehen , das besagt, dass ein neuer Commit vorgenommen wurde. Normalerweise sieht es gut aus, eine E-Mail-Erinnerung oder so etwas zu senden . Oder es gibt ein Tool, das automatisch eine E-Mail-Erinnerung an alle Prüfer sendet . Der Absender würde also alle Änderungen anzeigen und alle Änderungen überprüfen und davon ausgehen, dass er mit den Änderungen sehr zufrieden ist, sie schützen und etwas in dieser Art sagen wird und dies tun wird genehmigen Sie die Änderungen wie cell. Gehen wir zurück zu Lukes Konto. Schauen Sie jetzt in die Bar vom März. Wir werden als Nächstes darüber sprechen. 89. 1206 Erforsche der merging Understading von Squashing befiehlt, remote von lo zu löschen: Nachdem die Überprüfung abgeschlossen ist und die Änderungen von einem der Gutachter genehmigt wurden, ist Luke bereit, all diese Änderungen von Feature 1 mit dem Hauptzweig zusammenzuführen . Wenn Sie die Organisationslizenz von GitHub erwerben, erhalten Sie eine genauere Kontrolle. letzten beiden können die Pull Requests im Moment tatsächlich zusammenführen , wobei die kostenlose Version der Mitarbeiter Ihres Projekts in der Lage wäre, die Pull Requests zusammenzuführen, einschließlich der Person, die den Pull erhöht Anfragen. In diesem Fall versucht Luke tatsächlich, seinen eigenen Pull-Request zusammenzuführen. In Projekten in Echtzeit. Dies wäre einer der Teamleiter oder Person, die befugt ist, diese Aufgabe zu erledigen. Schauen wir uns alle Optionen an, die wir hier haben. Wir können ein Merge-Commit erstellen. Und wie der Name schon sagt, wird dies im Wesentlichen ein neues Merge-Commit im Hauptzweig erzeugen . Und es deutet auf ein paar übergeordnete Commits hin. Ein Elternteil wäre der letzte Commit aus dem Hauptzweig, der andere übergeordnete KM, es wäre der letzte Commit aus dem Feature-Branch. Wir haben bereits über Merge-Commits gesprochen. Ich muss es nicht noch einmal wiederholen. Und ganz zu schweigen davon , dass die Commit-Historie beibehalten wird, was bedeutet, dass Sie genauso gut alle Spaghetti-Kometen-Historien haben könnten . Wenn Sie keinen Spaghetti-Commit-Verlauf haben möchten und kein zusätzliches Merge-Commit erstellen möchten. Dann können Sie mit der dritten Option wählen, nämlich Rabatte und Zusammenführung. Daher werden alle vier Commits aus diesem Branch , der ein Feature-Branch ist, neu basiert und dann zum Basis-Branch hinzugefügt , sodass der Commit-Verlauf im Haupt-Zweig linearer aussieht. Wir haben auch eine dritte Option , nämlich Squash und Merge. Und wie die Beschreibung besagt, werden die vier Commits aus diesem Branch im Basis-Branch zu einem Commit zusammengefasst. Dies ist so gut, wie Sie im Hauptzweig ein neues Commit mit allen kombinierten Änderungen von Feature One Branch vornehmen. Dies ist möglicherweise die ideale Lösung wenn Sie viele Commits haben. Und es ist sinnvoll, sie miteinander zu kombinieren. In unserem Fall haben wir kaum Änderungen an jedem unserer Commits vorgenommen , nur eine einzige Textzeile geändert. Vielleicht ist diese Option ideal für uns. Wenn Sie mehrere Commits haben, bei denen Sie geringfügige Änderungen vorgenommen haben, und wenn Sie der Meinung sind, dass diese als ein einziges Commit kombiniert werden können , können wir diese Option verwenden. bin mir nicht sicher, ob du dich erinnern kannst, aber als wir über interaktives Rebasing sprachen, hatten wir die Möglichkeit, einige der Commits zu zerquetschen. Grundsätzlich kannst du beim interaktiven Rebasing alle Commits auflisten, die du quetschen möchtest, oder sie miteinander kombinieren. Nehmen wir an, Sie haben zehn Commits in Ihrem Feature-Branch. Sie können vier von ihnen oder drei von ihnen oder was auch immer für Sie Sinn macht, mit interaktivem Rebase zerquetschen was auch immer für Sie Sinn macht, . Wenn Sie sich nicht erinnern können, würde ich Ihnen empfehlen, sich die Interaktion mit der besten Vorlesung zu denselben noch einmal anzusehen . Lassen Sie uns vorerst mit dieser Option rebasen und zusammenführen. In den meisten Fällen wäre es entweder Merge Commit oder Rebus and Merge, abhängig von Ihren Anforderungen. Ich sollte auch erwähnen, dass wir alle potenziellen Konflikte gelöst hatten, da wir den Feature-Branch bereits auf den neuesten Commit off Main Branch umgestellt Feature-Branch bereits auf den neuesten Commit off hatten, bevor wir den Pull Request erheben hatten, bevor wir den bevor die Pull Requests tatsächlich ausgelöst werden. Und das ist der Grund, warum Sie zu diesem Zeitpunkt keine Konflikte sehen. Aber es kann seltene Fälle denen jemand anderes in Ihrem Team Änderungen in Ihrem Hauptbranch eingeführt hat , während Ihr Pull Request noch aktiv ist, was tatsächlich zu Konflikten führen kann. Wie Sie mit diesen Konflikten umgehen werden wir später besprechen. Lassen Sie uns vorerst Rebus und Merge machen. Und als Aufgabe können Sie diese beiden Optionen auch ausprobieren . Ziemlich unkompliziert. Klicken wir auf Rabatte und fusionieren. Bestätigen wir das. Die Pull-Anfrage wurde also erfolgreich zusammengeführt und geschlossen. Und wir sind bereit, diesen speziellen Zweig zu löschen. Wir können es von GitHub löschen, oder wir können dasselbe auch von unserem lokalen Computer aus tun. Lass mich dir zeigen, was ich meine. Lass mich Git Bash hier öffnen. Ich bin gerade im Projekt. Lassen Sie mich jetzt weitermachen und den Remote-Branch löschen. Und der Befehl dafür ist git, push origin, Name der Fernbedienung. Und dann verwenden Sie einen Doppelpunkt gefolgt vom Namen des Zweigs, den Sie auf dem Remote-Server löschen möchten. Feature eins, in unserem Fall drücke ich die Eingabetaste. Und dies sollte die Funktion auf dem Zweig im Remote-Repository löschen . Gehen wir zurück. Und wie Sie sehen können, haben wir jetzt nur noch den Hauptzweig. Und hier ist die Liste der Commits darin, die jetzt auch alle Kommentare enthält , die in Feature One gemacht wurden. Wenn ich git branch mache, wirst du immer noch den lokalen Zweig sehen. Lass mich den Namen richtig sagen. Wir haben immer noch die lokale Niederlassung. Lass uns weitermachen und es auch löschen. Git-Zweig, Bindestrich D, Merkmal eins. Okay, zu einer anderen Filiale zu wechseln. Und lassen Sie uns den Befehl erneut ausführen. Und die Filiale wurde gelöscht. Da die Remote-Funktion in Zweigen gelöscht wurde, auch der entsprechende Tracking-Zweig ist auch der entsprechende Tracking-Zweig nicht mehr verfügbar. Wir sehen uns als Nächstes. 90. 1207 Was Git Pull tut: Jedes Mal, wenn Sie versuchen, Ihre lokalen Änderungen an das Remote-Repository zu übertragen, versucht Git tatsächlich, unsere lokalen Änderungen mit demselben Zweig im Remote-Repository zusammenzuführen . Dies wird jedoch nur dann geschehen, wenn es zu einer schnellen Vorlaufzusammenführung führt , sonst wird es unsere Änderungen nicht vorantreiben und dann Weg finden, sie zu umgehen, um sie zu erledigen. Ich weiß, das klingt verwirrend und deshalb habe ich dieses Video gewidmet, um genau darüber zu sprechen. Und um die Dinge besser zu erklären. Ich werde eigentlich alles von Grund auf neu machen. Lassen Sie mich zum Absenderkonto gehen und ein brandneues Depot erstellen. Geben wir ihm einen zufälligen Namen. Es ist nicht wirklich wichtig. Wir werden es sowieso vorübergehend behalten. Und fügen wir auch eine dieser Dateien hinzu, damit wir einmal einen Commit im Hauptzweig haben einen Commit im Hauptzweig , nachdem wir dieses Projektarchiv erstellt haben. Lassen Sie mich auch Feature hinzufügen, dass ein Zweig erstellt wird. Und dann machen wir ein Commit und zeigen auch einen Zweig, vielleicht indem wir die Readme-Datei bearbeiten. Linie eins, Merkmal eins. Nennen wir es Linie zu. Es ist nicht wirklich wichtig. Machen wir das Commit. Gehen wir zu Einstellungen und fügen Mr. Luke als einen der Mitarbeiter hinzu. Okay, jetzt gehen wir zu Lukes Konto. Luke hat also gerade eine Einladung erhalten , zu diesem Projekt beizutragen. Wird sich diese Einladung ansehen und die Einladung annehmen. Und dann klont er das Projekt auf seinen lokalen Computer, um Beiträge zu leisten. In einem der Ordner. Ich werde Git Bash öffnen. Und lass uns dieses Projekt git klonen. Gehen wir in den Ordner. Und wenn ich git branch mache, sehen Sie nur, dass wir eine entfernte Rachman-Niederlassung von Maine sowie Feature eins haben , aber wir haben nicht die lokale Abzweigfunktion eins. Um es zu bekommen, wechseln wir zu einem Zweig oder zur Kasse, um einen Zweig zu zeigen. Also wird jetzt diese lokale Niederlassung erstellt. Und derzeit sind wir in Feature-Eins-Zweigstelle. Lassen Sie uns den Rest der Sachen aus Visual Studio-Code machen . Öffnen wir dieses Projekt also mit VS Code. Nehmen wir an, ich möchte einen Kommentar in der neuen Feature-Eins-Verzweigung abgeben . Daher befinden wir uns derzeit in einer Feature-Eins-Branche. Lass mich vielleicht diesmal eine Datei hinzufügen, lass es uns einen Punkt dx, dy nennen. Ich gehe zur Quellcodeverwaltung, gebe dem Commit eine Nachricht und übernehme unsere Änderungen. Stellen Sie sich nun vor, dass jemand anderes im Team, der ebenfalls am selben Branch arbeitet, einige Änderungen am Remote-Repository auf demselben Branch vorgenommen hat, um dieses Verhalten zu simulieren. Kehren wir zum Konto des Absenders zurück und machen tatsächlich ein Commit in Feature One Branch, als ob jemand die Änderungen an diesen Zweig weitergegeben hätte. Lassen Sie mich diesen Begriff eine weitere Datei hinzufügen, vielleicht TXT mit zwei Punkten. Und lassen Sie uns unsere Änderungen übernehmen. Jetzt sind im Grunde beide lokale Funktionen auf dem Zweig und der entsprechende Remote-Branch oder nicht divergiert. Mal sehen, was passieren würde, wenn ich versuchen würde, unsere lokalen Änderungen in das Remote-Repository zu übertragen. Git push, wir können die Fernbedienung spezifizieren und einen Zweig haben. Aber wenn Sie nur diesen Befehl verwenden, ist es ohnehin das Standardverhalten. Lassen Sie uns also unsere Änderungen vorantreiben und sehen, was passieren wird. Wie Sie sehen können, haben wir einen Fehler, der besagt, dass einige Refs nicht dieses Repository und Updates für abgelehnt wurden weil die Remote-Inhalte funktionieren, die Sie lokal nicht haben. Wie ich bereits sagte, wenn wir unser lokales Changes Kit pushen wird es tatsächlich versuchen, lokale Änderungen mit demselben Zweig im Remote-Repository zusammenzuführen lokale Änderungen mit demselben Zweig . In diesem Fall führt dies nicht zu einer schnellen Vorwärtszusammenführung, und das ist es, was unsere Änderungen nicht vorangetrieben hat. Was wir hier jetzt tun können, ist dass wir den Befehl git pull verwenden können. Und standardmäßig wird es auch versuchen, diese beiden Zweige in unserer lokalen Registrierung zusammenzuführen . Lassen Sie mich also versuchen, die Änderungen vorzunehmen. Wir könnten dasselbe auch mit Visual Studio-Code tun . Wenn du möchtest. Zum Beispiel kann ich sagen git pull von dort oder von hier. Versuchen wir jetzt, das Diagramm anzusehen. Und wie Sie sehen können, hat Git versucht, Merge Feature One Branch mit unserem lokalen Lehrer One Branch durchzuführen Merge Feature One Branch . Das ist also im Wesentlichen der Merge-Commit. Wenn Sie jetzt versuchen, eine Push-Operation durchzuführen , sollte dies erfolgreich sein. Und dann sollten wir in der Lage sein, dieses Merge-Commit auch im Remote-Repository zu sehen . Aber wenn Sie dieses Merge-Commit loswerden möchten, wissen Sie bereits, was zu tun ist. Rebase ist die Antwort. Lassen Sie uns also versuchen, unseren aktuellen Branch neu zu basen , der zusätzlich zu der jüngsten Änderung des Remote-Repositorys der Feature One Branch ist . Im Wesentlichen versuche ich, einen lokalen Feature-Eins-Zweig mit dem Remote-Tracking-Zweig zu rebasen , der im Wesentlichen den Remote-Feature-Eins-Zweig darstellt . Das ist also der Commit, den die Tracking-Zweige zeigen. Ich klicke mit der rechten Maustaste darauf. Und dann werde ich diese Option wählen Rebase, aktuellen Zweig in diesem Ausschuss. Und lasst uns im Rahmen der Wiedergeburt rebasen, wie wir bereits in einer unserer vorherigen Vorlesungen besprochen haben. Es wird auch alle Merge-Commits loswerden. Weil wir im Wesentlichen den gesamten Commit-Verlauf neu schreiben . Und diese Art löst das Problem nicht viele Commits zu haben. Jetzt haben wir also einen linearen Commit-Verlauf. Wir sind bereit, unsere Änderungen voranzutreiben. Dieses Mal. Dies führt zu einer schnellen Vorlaufzusammenführung sowohl des lokalen Features auf dem Zweig als auch des Zweigs der Remote-Funktion eins. Und so sollten wir keine Probleme haben oder was auch immer. Aber im Allgemeinen sollten Sie beim Rebase-Vorgang vorsichtig sein. Und es gibt bestimmte Best Practices zu befolgen, die wir in den kommenden Vorlesungen diskutieren werden. Es ist kein Problem, viel Commit zu haben. Sie können Ihren Merge-Kommentar auch pushen, wenn Sie möchten. Und tatsächlich ist es eine der beliebtesten Optionen, da Rebase tatsächlich die Dinge durcheinander bringen könnte. Worüber wir in den kommenden Vorlesungen sprechen werden . Aber im Moment sind wir bereit, unsere Änderungen voranzutreiben. Und es ist erfolgreich, zum Remote-Repository zu wechseln. Wechseln Sie jetzt zu Feature One Branch. Sollte all diese Kommentare sehen, einschließlich des lokalen Commits , das wir zuvor gemacht hatten. Wir sehen uns als Nächstes. 91. 1208 Konflikte auf GitHub lösen auf dem richtigen Weg Zwinge Änderungen vorzunehmen und seine Folgen: Lassen Sie uns sehen, wie wir mit Konflikten umgehen können , wenn wir versuchen, das erste Merkmal mit dem Mainstream der Evolution, dem Hauptzweig, zusammenzuführen Merkmal mit dem Mainstream der . Derzeit bin ich in Feature One Branch und wie Sie sehen können, haben wir all diese vier Commits aus unseren vorherigen Vorlesungen. Was ich jetzt tun werde, ist, einen Pull-Request für alle Änderungen zu einen Pull-Request für stellen, die wir in vitro eingeführt haben, einen Branch hat Pull Request ausgelöst. Jetzt kann ich wirklich dieser Operationen durchführen. Ich kann auch Reparaturen durchführen und vieles mehr, da in der Hauptbranche keine neuen Kommentare abgegeben wurden und es keine Möglichkeit gibt, dass dies zu Konflikten führen kann. Aber was ist, wenn nach dem Auslösen des Pull-Requests jemand neue Änderungen im Hauptzweig einführt, was zu Konflikten ohne Feature-Eins-Änderungen führen kann . Um dieses Verhalten zu simulieren. Lass mich zurück zum Hauptzweig gehen und diese Datei bearbeiten. Wenn Sie sich erinnern, haben wir in einem der Kommentare in vitro und branch die ReadMe-Datei aktualisiert. Wenn ich diese Datei also noch einmal im Hauptzweig aktualisiere, sollte dies zu einem Konflikt führen. Lassen Sie mich also auf diese Datei klicken und einen solchen Text hinzufügen einen solchen Text und die Änderungen übernehmen. Kehren wir nun zum Pull Request zurück und schauen, ob wir jetzt Freebase ausführen können. Und jetzt sehen Sie eine Warnung , die besagt, dass die Branche komplex ist und diese gelöst werden müssen. Wir können hier Konflikte lösen, aber das ist kein empfohlener Ansatz. es kurz zu machen, das wird die Dinge ein wenig komplizieren. Wenn Sie sich die Geschichte von Chametz ansehen, wird Sie das im Grunde verwirren. Es gibt einen besseren Weg, damit umzugehen. Und das werde ich Ihnen jetzt in unserer lokalen Maschine zeigen , wie er , dass dies wie ein Computer aussieht. Zunächst werden wir alle Änderungen in der Hauptzweige einbringen . Also lass mich zum Hauptzweig wechseln und einen neuen Commit aufrufen. Versuchen wir nun, unseren Feature-Ein-Branch zusätzlich zu diesem neuen Commit zu rebasen . Dies ist ein Standardverfahren, das wir in einer unserer vorherigen Vorlesungen befolgt hatten . Worauf stützen Sie jemanden , um wieder zu Feature eins zu wechseln? Klicken Sie mit der rechten Maustaste auf dieses Commit und wählen Sie diese Option, die besagt, dass der aktuelle Zweig in diesem Ausschuss Das sollte zu Konflikten führen. Und wie erwartet haben wir Konflikte. Das heißt, verwerfen Sie es. Lassen Sie uns also diese Konflikte lösen. Vielleicht möchte ich dieses Mal beide Änderungen akzeptieren. Speichern Sie die Datei, lassen Sie mich sie angeben und klicken Sie auf Commit. Dies wird im Wesentlichen einen neuen Commit mit allen Ergebniskonflikten erzeugen . Geben wir eine Nachricht ein. Ich würde es gerne so lassen wie es ist. Sobald Sie es geschlossen haben. Dies sollte einen Zweig zusätzlich zu diesem neuen Commit rebasen. So wie. Also jetzt alle Commits , die auf Branch oder oben auf diesem Commit gesehen werden. Lassen Sie uns nun versuchen, all diese Änderungen in das Remote-Repository zu übertragen und zu sehen, was passieren wird. Lass mich den Bildschirm räumen. Wir könnten dasselbe auch von Visual Studio Code aus tun. Lassen Sie mich den Befehl git push eingeben und sehen, was passieren wird. 1 Sekunde haben wir dieses Hetero-Sprichwort bekommen , einige Verweise auf das Remote-Repository nicht pushen. Das liegt daran, dass bei rebase Enter-Commit-Verlauf neu geschrieben wurde und nicht mit dem Commit-Verlauf übereinstimmt, den wir im Remote-Repository haben. Nun sei gut, dass unser lokales Feature One Branch und das entsprechende Feature einen Zweig im Remote-Repository haben, oder beide divergierten. Und so können wir unsere Änderungen nicht vorantreiben. Wie übertragen wir unsere Änderungen jetzt in das Remote-Repository? Nun, wir können die Option Force nutzen. Also diesmal mit Git Push und wann die Option Force bereitgestellt werden soll. Was wird das jetzt bewirken? Das force-Flag bewirkt, dass der Remote-Repository-Zweig mit Ihrem lokalen Branch übereinstimmt . Und es werden alle Änderungen der Originalautoren gelöscht , die möglicherweise seit Ihrem letzten Aufzählungszeichen eingetreten sind. Das bedeutet auch, dass, wenn mehrere Personen in derselben Branche arbeiten und wenn jemand seine Änderungen in derselben Branche eingebracht hätte , die gesamte Arbeit verloren gehen würde, was manchmal nicht wünschenswert. Es gibt also Fälle, in denen Sie die Option force nicht verwenden sollten. Wir werden in den kommenden Vorlesungen über all das und über Best Practices sprechen . Aber im Moment wird das die Arbeit für uns erledigen. Und wenn Sie zum Remote-Repository zurückkehren, stellen Sie fest, dass wir jetzt Rebase und Merge oder sogar andere zwei Optionen durchführen können . Werfen wir einen kurzen Blick auf den Commit-Verlauf. Um zu einem Zweig zu gelangen. Schau dir die Liste der Commits an. Wir haben also all diese Kommentare zu Feature One Branch gemacht über den Kommentaren des Hauptzweigs gestapelt sind. Wir können jetzt Rabatte durchführen und zusammenführen. Wir können auch den Komplex und GitHub auflösen, aber es wird seltsame Dinge tun wie Robeson, den Hauptzweig, auf dem sich ein Zweig befindet , um Dinge zu erledigen. Und das könnte zu großer Verwirrung führen. Dies ist jedoch häufig die übliche Praxis , um den Konflikt zu lösen. Jetzt macht es keinen Sinn, die Filiale in der Nähe zu haben . Also kann ich es löschen. Hoffe es macht Sinn. Wir sehen uns als Nächstes. 92. 1209 Strategie teilen und Conqr: Lassen Sie uns sehen, wie wir mit den negativen Folgen des Einsatzes von Zwangsoptionen umgehen können . Wenn Sie den Befehl push verwenden. Ich habe erwähnt, dass bei Verwendung der Option force der Commit-Verlauf auf dem Remote-Server gewaltsam mit Ihrem eigenen lokalen Verlauf überschrieben wird . jetzt ein paar Konsequenzen. Nummer eins, wir haben möglicherweise mehrere Entwickler, die in derselben Branche arbeiten und wir könnten riskieren, alle Commits zu verlieren, die sie nach Ihrer letzten Umfrage gemacht haben. Und zweitens, am wichtigsten, wenn Sie Rebus ausführen und dann Ihre Änderungen erzwingen, kann dies tatsächlich zu einem Chaos führen weil alle anderen im Team das Projekt heruntergeladen haben könnten und vielleicht in diese Filiale ausgecheckt haben. Wenn Sie den Push rebasen und pausieren, lesen Ihre Änderungen im Wesentlichen nicht nur den Commit-Verlauf, sondern auch deren Hash-Codes. Und alle Teammitglieder, die das Projekt und Chet Dot in diesen Zweig heruntergeladen haben könnten das Projekt und Chet Dot in diesen Zweig heruntergeladen , haben möglicherweise eine andere gemeinsame Historie die im Remote-Repository. Das wird eine Menge Chaos verursachen. Um dies zu verhindern, haben wir eine Strategie namens divide and conquer. Lassen Sie mich erklären, was ich meine. Nehmen wir an, dies ist der Hauptzweig und dies ist der Feature-Branch im Remote-Repository. Nehmen wir nun an, dass einige Entwickler bereit sind, zu dieser Branche beizutragen. Anstatt dass beide zu diesem Zweig beitragen. Wir werden jetzt ein paar Unterzweige haben von denen jede einzelnen Entwickler gehören würde. Beides pro Dollar würde zu ihren eigenen Veränderungen in ihren eigenen Unterzweigen beitragen . Und da sie auf ihrem eigenen Zweig laufen, haben Änderungen, die in einem Zweig vorgenommen werden , keine Auswirkungen auf den anderen Zweig. Beispielsweise möchte einer der Entwickler möglicherweise alle diese Änderungen rebasen und das Commit in seinem eigenen Branch erzwingen rebasen und das Commit in seinem eigenen Branch erzwingen. Und es wird keinerlei Auswirkungen auf die andere Branche des Entwicklers haben. Und sobald einer der Entwickler mit allem fertig ist, was er tun muss, kann er alle Änderungen auf dem Feature-1-Branch zusammenführen . Und dann würde der andere Dollarwert ihren Zweig auf den ersten Zweig umstellen und dann schließlich auch ihre Änderungen zusammenführen. Und wenn es Änderungen gibt, die einer der Dollar-Plus möglicherweise verpasst hat, können sie einen weiteren Zweig gründen und all diese Änderungen mit sich bringen. Und dann führen Sie diese Änderungen natürlich in Feature One Branch zusammen. Dies wird als Strategie zum Teilen und Herrschen bezeichnet. Und dies könnte die Nebenwirkungen verhindern, die auftreten können, wenn Sie Ihre Änderungen erzwingen. Es kann jedoch Fälle geben, in denen dieser Ansatz möglicherweise nicht durchführbar ist. In diesem Fall haben wir eine Alternative zu, und darüber werden wir als nächstes sprechen. Aber vielleicht kannst du das als Auftrag annehmen. Versuchen Sie, aus dem Feature-Eins-Zweig einige Unterzweige zu erstellen , und versuchen Sie, dem Ansatz „Teilen und Herrschen“ zu folgen 93. 1210 Konflikte lösen, indem du main zu feature zusammenfügst: Okay, lassen Sie uns sehen, wie wir mit Konflikten umgehen können, indem die Zweige zusammenführen, ohne die Force-Option verwenden zu müssen, oder indem wir dem Ansatz „Teilen und Herrschen“ folgen. Lassen Sie uns dazu zunächst versuchen, einen weiteren Konflikt zu schaffen. Da wir Feature One Branch bereits gelöscht haben, lassen Sie uns einen neuen Branch erstellen , um neue Konflikte einzuführen. Nennen wir es neue Funktion. Was auch immer. Ich werde diesen Zweig erstellen. Und lassen Sie mich eine dieser Dateien bearbeiten. Nehmen wir an, ich möchte eine Punkt-TXT-Datei bearbeiten. Und ich füge einfach den Namen des Zweigs wie Zelle hinzu. Übernehmen Sie die Änderungen. Lassen Sie mich zurück zur Hauptniederlassung wechseln. Und versuchen wir noch einmal, dieselbe Datei zu bearbeiten, damit wir Konflikte haben. Sagen wir einfach main und übernehmen die Änderungen. Gehen wir nun zu Pull Requests und versuchen, einen neuen Pull Request zu stellen. Wir vergleichen also den Hauptzweig mit dem neuen Feature-Branch. Und hier sind die Änderungen. Lassen Sie mich weitermachen und den Pull Request erstellen. Wie Sie sehen, erhalten wir eine Meldung, die besagt, dass dieser Zweig einen Komplex hat , der gelöst werden muss. Und wir haben auch die Möglichkeit , Konflikte zu lösen. Wie gut das es uns ermöglichen würde, die Konflikte zu lösen, ist, indem den Haupt-Zweig tatsächlich mit dem Feature-Branch zusammenführen. Das mag Sie vielleicht überraschen, aber es funktioniert tatsächlich. Lass mich dir zeigen, was ich meine. Lassen Sie mich auf Konflikte lösen klicken. Das ist, als befänden wir uns in einem Zusammenführungszustand , in dem Konflikte gelöst werden müssen. Und wir können die Konflikte genauso lösen , wie wir sie in unserem lokalen Computer aufgelöst haben, als wir versuchen, Zweige zusammenzuführen. In diesem Fall versucht GitHub also im Wesentlichen, den Hauptzweig mit dem neuen Feature-Branch zusammenzuführen . Und das würde im Wesentlichen alle Änderungen des Hauptzweigs oder alle Kommentare des Hauptzweigs auf den Feature-Branch bringen Hauptzweigs oder alle Kommentare des . Behalte gerne beide Änderungen bei. Und ich klicke auf den Button mit der Aufschrift Mark. Als Ergebnis. Wir kommen bei der Zusammenführung. Dadurch wird ein Merge-Commit erstellt, und das wird auf ein paar übergeordnete Commits hinweisen. Der letzte Kommentar des Hauptzweigs und der letzte Commit aus dem neuen Feature-Branch. Ziemlich ähnlich zu dem, was wir in unserem lokalen Computer getan haben , als wir versuchen, die Konflikte zu lösen. Während Marge. Hier sehen Sie, dass wir gerade main mit dem neuen Feature-Branch zusammengeführt haben . Und das hat das Problem gelöst. Um zum Projektarchiv zurückzukehren, würden Commits im Hauptzweig so bleiben. Lass es mich dir zeigen. Wenn Sie jedoch zum neuen Feature-Branch gehen, enthält er alle Commits in den erstellten Kommentaren und dem neuen Feature-Branch sowie dem Merge-Commit. Wenn du da reingehst, wirst du sehen, dass es ein paar Eltern hat. Ein Elternteil ist das letzte Commit des Haupt-Branches, und das andere ist der neue Kommentar, den wir gerade im Feature-Branch abgegeben haben . Dieser Merge-Commit-Snapshot hätte also Änderungen in diesen beiden Zweigen eingeführt. Und deshalb können wir alle Commits sehen , die zu beiden Branches gehören. Ich bin mir nicht sicher, ob dich das wirklich verwirrt, aber das ist eigentlich ziemlich einfach. Wenn du das nicht verstehst, dann ist das völlig in Ordnung. Wir haben bereits einige Möglichkeiten zur Lösung der Konflikte besprochen . In den letzten Vorlesungen. Sie können diesen Ansatz wählen oder Sie können auch diesem Ansatz folgen. Sie können dasselbe auch in Ihrem lokalen Depot tun. Schauen Sie sich einfach das Projekt an und versuchen Sie, Hauptzweig auf Ihrem Feature-Ein-Branch zusammenzuführen. Lösen Sie die Konflikte, sodass Sie einen ähnlichen Commit-Verlauf auf Ihrem lokalen Computer haben. Und dann pushen Sie all diese Commits mit dem Standard-Push-Befehl in das Remote-Repository. Kehren wir zur Pull-Anfrage zurück. Jetzt haben wir die Konflikte nicht mehr . Dieser Zweig hat keine Konflikte mit dem Basis-Branch. Und wir sind bereit , eine Zusammenführung durchzuführen. Sie können jedoch kein Rebase durchführen. Sie können das Rebasing nicht durchführen, da Rebase, wie Sie bereits wissen, den Commit-Verlauf neu schreiben und sogar die Merge-Commits entfernen wird den Commit-Verlauf neu schreiben und . In diesem Fall macht es keinen Sinn, das zu tun. Das klingt verwirrend. Denken Sie dann daran, dass es kein Rebase durchführen kann. In diesem Fall. Wenn Sie versuchen, eine Rebase durchzuführen, heißt es, dass dieser Zweig aufgrund von Komplexität nicht neu basiert werden kann. Die Botschaft ist eigentlich nicht sehr klar, aber ich hoffe, Sie haben den Punkt verstanden. Aber wir können die Änderungen zusammenführen und sie zusammenführen. Wir können jetzt den neuen Feature-Branch loswerden. Und das ist der alternative Weg, um den Komplex zu lösen . Wir sehen uns als Nächstes. 94. 1301 Was ist Forking und warum Forking: Lassen Sie uns über for king in GitHub und seine Bedeutung sprechen. Stellen Sie sich vor, wir haben ein Open-Source-Projekt mit dem Namen App öffnen im GitHub-Repository. Und sagen Sie, dass dies im Besitz von Mr. Sunda ist. Wenn ich jetzt sage, dass dies das Open-Source-Projekt ist, können Sie Hunderte oder sogar Tausende von Entwicklern auf der ganzen Welt erwarten , die bereit sind, zu diesem Projekt beizutragen. Stellen Sie sich nun vor, wie viel Arbeit geleistet werden muss, um die Mitarbeiter zu verwalten. Wenn Zylinder, was Hunderte oder Tausende von Mitarbeitern zu verwalten , wird es zu einem eigenen Job. Jedes Mal, wenn jemand etwas beitragen möchte, sei es ein kleiner Beitrag oder ein großer Beitrag, muss er immer noch als Mitarbeiter hinzugefügt werden. Zweitens, wenn Kleinigkeiten die kostenlose Version von GitHub verwenden, dann haben wir im Wesentlichen alle Mitarbeiter das Privileg, haben wir im Wesentlichen alle Mitarbeiter das Privileg ihren Code auf dem Hauptzweig zusammenzuführen. Stellen Sie sich jetzt einen Anfängerdollar vor, der gerade erst mit dem Programmieren anfängt. Liefern Sie etwas Code und Modul dieser Änderungen auf dem Hauptzweig, ohne angemessene Tests durchzuführen. Offensichtlich wird das eine Menge Chaos verursachen. Wir brauchen also eine Lösung für dieses Problem. Nun, die Lösung ist Forking. Was genau ist Forking? Stellen Sie sich vor, Herr Luke möchte zu diesem Projekt beitragen und er wurde nicht als Mitarbeiter an diesem Projekt hinzugefügt. Was Luke also tun wird, ist mit nur einem Klick auf eine Schaltfläche, um dieses Repository auf seinem eigenen GitHub-Konto zu folken . Du kannst dir vorstellen, als Klon zu arbeiten. Aber anstatt es auf dem lokalen Computer zu klonen, wird es auf der GitHub-Salve auf Lukes Konto passieren . In diesem Fall Luke und benenne dieses Projekt um, was auch immer der Name seiner Wahl ist, oder er kann auch den gleichen Namen behalten. Es ist nicht wirklich wichtig. Als standardmäßige Namenskonvention. Standard-Projektarchiv wird als Ursprung und das ursprüngliche Projektarchiv als Upstream bezeichnet. Sie können sie natürlich mit einem beliebigen Namen nennen. Aber das sind die typischen Namenskonventionen wir als Entwickler befolgen. Wann immer ich Ursprung sage, beziehe ich mich auf das geforkte Repository. Immer wenn ich Upstream sage, beziehe ich mich auf das ursprüngliche Repository , von dem wir vier haben. Jetzt schauen Sie, wir erstellen ein gegabeltes Clone-Office-Repository, sogar auf seinem lokalen Computer. Er wird dann alle Änderungen einführen, die er einführen muss, und all diese Änderungen werden in das gegabelte Projektarchiv übertragen . In der Zwischenzeit, wenn es neue Updates für das ursprüngliche Depot gibt , schauen und ziehen Sie all diese Änderungen tatsächlich sein lokales Depot und übertragen Sie all diese Änderungen oder neuen Commits an sein gegabelt Repository. Auf diese Weise bleibt das Standard-Repository auf dem neuesten Stand, aber die neu eingeführten Änderungen in den ursprünglichen Depositorys, nachdem Luca mit den Änderungen fertig ist , die er einführen möchte. Und natürlich wird nach ausreichenden Tests ein Pull-Request ausgelöst und einige dort gebeten, all diese Änderungen zu akzeptieren und diese Änderungen im Hauptzweig des ursprünglichen Repositorys zusammenzuführen diese Änderungen im Hauptzweig . Dieses Schiff dort muss also keinen Schreibzugriff haben, um einen Beitrag zu leisten. Dieser Ansatz, durch Forking des Repositorys zu einem Projekt beizutragen , ist nicht nur gut für den Eigentümer des Repositorys, sondern auch für den Dollar plus eins, um zum Projekt beizutragen. Hier sind einige der Vorteile, die Entwickler bei der Verwendung von Forking haben. Anstatt direkt zum ursprünglichen Repository beizutragen . Gehen ermöglicht es jedem , zu einem Projekt beizutragen , ohne den richtigen Zugang zu haben. Da sie einfach einen Fork eines Projekts erstellen können, führen Sie alle Änderungen ein , testen Sie sie und stellen Sie dann einen Pull Request aus. Sie können frei mit Änderungen experimentieren , ohne das ursprüngliche Projekt zu beeinträchtigen. In einigen Fällen kann es mehrere Personen geben, die gemeinsam zu einem bestimmten Projekt beitragen möchten. In diesem Fall ist es immer besser, das ursprüngliche Depository zu forken, alle Änderungen zu löschen und Integrationstests durchzuführen. Und sobald sie fertig sind, können sie einen Pull-Request die ursprüngliche Einzahlung an den Eigentümer bitten, alle Änderungen vorzunehmen und diese Änderungen im alle Änderungen vorzunehmen und diese Änderungen Haupt-Branch zusammenzuführen. Gehen ermöglicht es Ihnen, ein anderes Projekt als Ausgangspunkt für Ihre eigene Idee zu verwenden . Viele kommerzielle Software oder Anwendungen wurden ursprünglich mit einem Open-Source-Projekt initiiert . Sie arbeiten einfach an allen bestehenden Open-Source-Projekten und führen darüber hinaus Änderungen ein und verkaufen sie mit der kommerziellen Lizenz an ihre Kunden. Und schließlich müssen Sie nicht auf den richtigen Zugriff warten. Stellen Sie sich vor, Sie schreiben eine E-Mail an den hinteren Besitzer, in der Sie nach der rechten Achse gefragt werden, und warten dann ewig auf eine Antwort. Nun, mit Forking können Sie direkt zum Projekt beitragen und Pull-Requests rennen, ohne den richtigen Zugriff auf das ursprüngliche Depot haben zu müssen. Wir werden all diese Untätigkeit und mehr in den kommenden Vorlesungen sehen . Wir sehen uns als Nächstes. 95. 1302 Ein öffentliches Repository vorbereiten und in unserer lokalen Maschine klonieren: Okay, lass uns sehen, wie wir ein Repository forken können , um Beiträge zu leisten. Stellen Sie sich nun vor, dies ist Lukes Computer und er ist bereit, zu einem der online verfügbaren Open-Source-Projekte beizutragen . Also lass mich zu Lukes GitHub-Konto gehen. Und hier ist es. Und nehmen Sie an, dass dies das Projekt ist , zu dem Luke bereit ist, einen Beitrag zu leisten. Dieses Projekt gehört eigentlich Mr. Cylinder und Look, hat nicht den richtigen Zugriff auf dieses Projekt oder er wurde nicht als einer der Mitarbeiter für dieses Projekt hinzugefügt . Da Loop nicht direkt zu diesem Projekt beitragen kann, wird dieses Mal nicht direkt zu diesem Projekt beitragen kann, wird tatsächlich eine Abzweigung dieses Projekts erstellt. Hier sehen Sie eine Option mit der Aufschrift ****, Sie können den Klick hier hinzufügen. Ich klicke auf das Drop-Down-Menü. Und Sie sehen eine Option mit der Aufschrift Create a New Fork. Hey, die Art und Weise, wie du zu dieser Seite geführt wirst , auf der du aufgefordert wirst, deinem Repository einen Namen zu geben. Sie können den gleichen Namen wie beim ursprünglichen Depot behalten , oder Sie können es in einen anderen Namen umbenennen. Zum Beispiel spielt vielleicht das Aussehen, App oder was auch immer keine Rolle. Optional können Sie auch eine Beschreibung angeben und auf diese Schaltfläche mit der Aufschrift Create Fork klicken. Also haben wir im Wesentlichen einen Klon des ursprünglichen Projekts auf Lukes GitHub-Konto erstellt . Und Luke kann jetzt alles tun, was er sonst in seinem eigenen öffentlichen Repository tun würde. Und die Tatsache, dass dies tatsächlich ein Klon oder eine geforkte Version eines anderen Repositorys ist. Sie werden sehen, dass der gesamte Commit-Verlauf Zweige ist. Alles ist wie es ist, außer einem gegabelten Repository. Dieses Symbol zeigt an, dass es sich um ein gegabeltes Repository handelt. Und auch dieser Text , der besagt, dass er von der Polizei 1996 gegabelt wurde, hat meine öffentliche Kappe zerschlagen, die das ursprüngliche Depot ist. Solute, kann jetzt anfangen, zu diesem Projekt beizutragen. Er kann sogar weitere Mitarbeiter hinzufügen. Wenn Luke ein Team von Entwicklern hat, die möglicherweise zu diesem Projekt beitragen möchten. Sie können Regeln zum Schutz von Mitarbeitern oder Zweigstellen hinzufügen. Alles was man mit einem öffentlichen Repository machen kann. Sie können dasselbe sogar mit dem gegabelten Repository tun. Außer natürlich werden Sie einen Unterschied zum hier hinterlegten Original sehen . Diese Referenz wird sich zu einem späteren Zeitpunkt als nützlich erweisen und wir werden in den kommenden Vorlesungen darüber sprechen. Vorerst. Lassen Sie uns versuchen, dieses Projekt zu klonen. Kopieren wir die HTTPS-URL. Im Inneren sieht der Computer einfach aus, um sein eigenes Repository zu klonen. Git klont die URL und fügt sie ein. Lass mich in das Verzeichnis cd gehen. Und lassen Sie mich den Befehl eintippen git remote hyphen v steht für verbose. Wie Sie sehen können, hat es bereits ein Remote mit dem Namen origin hinzugefügt , und es zeigt auf das geforkte Repository. Wenn ich Herkunft sage, beziehe ich mich eigentlich auf das geforkte Repository. Und auf der anderen Seite wäre es auch erforderlich, eine weitere Fernbedienung hinzuzufügen, die Upstream-Remote ist. Und das deutet darauf hin, dass das ursprüngliche Repository ab dem nächsten fortgesetzt wird. 96. 1303 Beitrag zu den notwendigen Änderungen: Was sind nun die Änderungen, die Luke zu diesem Projekt beitragen möchte? Bringt all diese Änderungen lokal ein, testet sie und überträgt dann all diese Änderungen in sein eigenes gegabeltes Repository, um das Verhalten zu simulieren, das viele Commits verursacht hat. Und natürlich werden wir als gute Praxis eine neue Niederlassung einrichten. Und hier werden wir unsere Commits machen. Das habe ich während des gesamten Kurses gepredigt . Wir würden niemals den Handel auf dem Hauptzweig statisch betreiben wollen , sondern wir werden eine neue Filiale gründen und einen hohlen Beitrag leisten. Öffnen wir das also ganz schnell mit Visual Studio-Code und erstellen einen neuen Zweig. Nennen wir es Feature Zehn. Vielleicht. Erstellen Sie einen neuen Zweig. Und ich füge einfach ein paar Dateien hinzu. Ein Punkt TXT, zum Beispiel, gehe zu Source Control, erstellt einen Punkt TXT. Übernehmen Sie die Änderungen. Und lassen Sie mich noch einen verpflichten. Vielleicht zwei Punkte dx, dy, was auch immer. Ich wollte nur sichergehen, dass wir ein paar Kommentare sehen. Und dieser Feature-Zweig hat das Wort, unsere Änderungen einzuführen. Wir haben einen Zweig vorgestellt und einige Kommentare dazu abgegeben. Sie können es in diesem Diagramm hier sehen, wie Sie sehen können, das Feature One verzweigt, ein paar Kommentare voraus. Der Hauptzweig. Was ist, wenn wir, während ich noch an dieser Funktion arbeite, eine Menge neuer Updates für das vorgelagerte Repository oder das ursprüngliche Repository haben . Wie werden wir all diese Updates in unserem lokalen Computer sowie im gegabelten Repository erhalten? Darüber werden wir als Nächstes sprechen. 97. 1304 Synchronisierung des gegabelten Repo mit original und Aktualisierung der lokalen: Okay, lassen Sie uns sehen, wie wir unser lokales Depot und das geforkte Repository synchron mit dem ursprünglichen Depository halten können unser lokales Depot das geforkte Repository synchron . Um das Verhalten zu simulieren, bei dem wir heute einige neue Updates in der ursprünglichen Einzahlung haben. Lassen Sie mich tatsächlich zum Absenderkonto gehen. Wer ist der Besitzer dieses Repositorys. Und lassen Sie mich im Hauptzweig ein Commit machen, vielleicht indem ich einfach eine Datei hinzufüge. Geben wir ihm einen zufälligen Namen. Etwas in dieser Art. Apple Punkt TXT. Entschuldigung für die lustigen Namen. Ich wollte die Dinge einfach halten. Erstellen wir diese Datei. Wir haben also einige neue Änderungen im ursprünglichen Zweig vorgenommen. Jetzt gibt es mehrere Möglichkeiten, unser gegabeltes Repository mit dem ursprünglichen Repository synchron zu halten unser gegabeltes Repository . Die, über die ich jetzt sprechen werde , ist der einfachste Ansatz von allen. Gehen wir jetzt zu Lukes GitHub-Konto. Lass uns die Seite aktualisieren. Das ist also das gegabelte Repository. Hier sehen Sie eine Nachricht , die besagt, dass dieser Zweig ein Commit hinter dem Cop Main ist, dem ursprünglichen Depot. Und hier sehen Sie auch eine Option zum Versenken der Gabel. Wenn du darauf klickst. Sie sehen die Option , die Filiale zu aktualisieren und beachten Sie, dass wir uns derzeit in der Hauptniederlassung befinden. Daher wird im Wesentlichen der Hauptzweig des gegabelten Repositorys mit dem Hauptzweig des ursprünglichen Depositorys verglichen. Und so sagt uns GitHub , dass wir tatsächlich einen Commit hinter dem Hauptzweig des ursprünglichen Depositorys stehen . Wenn Sie auf Sync Fork klicken, sehen Sie die Option zum Aktualisieren des Branches. Klicken Sie darauf. Das würde also unsere Änderungen abrufen und zusammenführen. Und wie Sie sehen können, haben wir die neue Akte hier. Jetzt, wenn es geholt und zusammengeführt wurde, ist es wie eine Pooloperation. Und das wird zu einer schnellen Vorlaufzusammenführung führen. Und es gibt keine Möglichkeit , dass wir hier zu Konflikten kommen , weil wir bewährte Praktiken befolgen, unsere Beiträge nicht im Hauptzweig zu leisten. Wir haben einen Feature-Branch erstellt und dort bringen wir alle Änderungen ein, die den Hauptzweig nicht berührt haben. Wenn wir also an beide Repositorys denken, werden wir auf keinen Fall Konflikte sehen , falls Sie gute Praktiken nicht befolgen und Kommentare in Ihrem Hauptzweig abgeben Sie könnten genauso gut Konflikte sehen und dann müssen Sie sich mit diesen Konflikten auseinandersetzen. Sobald Sie es im Remote-Repository haben, müssen Sie diese Änderungen nur noch in Ihrem lokalen Repository vornehmen. Lass uns das ganz schnell machen. Und wie Sie sehen können, haben wir die Updates aus dem Standard-Repository erhalten. 98. 1305 Synchronisierung des gegabelten Repo mit Original aus lokalem Repo: Schauen wir uns einen anderen Weg an, um gegabelte Repository und das lokale Depot auf dem neuesten Stand des ursprünglichen Depositorys zu halten lokale Depot auf dem neuesten Stand des ursprünglichen Depositorys . Lassen Sie uns dazu schnell eine weitere Bemerkung machen. In der ursprünglichen Ablage, die sich am Busfenster befindet. Nur um das Verhalten neuer Updates im Hauptzweig zu simulieren . Ich füge eine neue Datei hinzu, so etwas. Nochmals, tut mir leid für die lustigen Namen. Komm mit der neuen Akte. Dieses Mal ziehen wir all diese Änderungen tatsächlich in ein lokales Repository und übertragen sie dann in unser gegabeltes Repository. Mal sehen, wie wir das machen können. Lass es uns von Git Bash aus machen. Sie können dasselbe auch über Visual Studio-Code tun , wenn Sie möchten. Das Wichtigste zuerst: Wir müssen die Änderungen aus dem ursprünglichen Depository übernehmen. Wie werden wir das machen? Wenn ich git pull sage, würde dies tatsächlich von der Original-Fernbedienung abgerufen werden, die das gegabelte Repository ist. Aber wir wollen es eigentlich aus dem ursprünglichen Depot holen . Wie werden wir das machen? Zuallererst müssen wir diese Fernbedienung hinzufügen. Wenn ich git remote hyphen v sage, sehen Sie, dass wir Origin-Herabstufung haben und auf das geforkte Repository zeigen. Lassen Sie uns nun eine weitere remote, git, remote add hinzufügen. Und ich nenne es als Upstream. Wie ich bereits erwähnt habe. Wir werden das ursprüngliche Depot als Upstream bezeichnen. Und hier geben wir die URL des ursprünglichen Depositorys an. Also lass mich das hier kopieren. Ich kann diesen Link auch benutzen, wenn ich möchte. Dieser Befehl hat gerade das Upstream-Repository hinzugefügt. Wenn ich diesen Befehl noch einmal ausführe, sehen Sie, dass wir jetzt einige Anmerkungen haben. Lassen Sie uns nun versuchen, die Änderungen aus dem vorgelagerten Projektarchiv zu übernehmen. Git pull dann Upstream Main. Deshalb wollen wir unsere Hauptniederlassung auf dem neuesten Stand halten. Dies hat alle Änderungen mit sich gebracht. Das ist die Datei, die wir gerade erstellt haben. Das können Sie auch im Visual Studio Code sehen. Diese Änderungen sind jedoch noch nicht in unserem gegabelten Repository oder dem Original-Server verfügbar . Ratet mal, was wir als Nächstes tun müssen. Git drücken. Und das sollte diese neuen Commits in das geforkte Repository übertragen. Wenn du jetzt zu Lukes Konto gehst und die Seite neu lädst, wirst du diese Updates sehen. 99. 1306 Drücke unsere Änderungen am gegabelten Repo: Okay, nehmen wir an, dass Luke mit all den zehn Feature-Ten-Änderungen fertig ist . Und jetzt ist er bereit, all diese Änderungen dem Absender vorzuschlagen, der der Eigentümer des ursprünglichen Depositorys oder des vorgelagerten Repositorys ist. Aber bevor Luke das überhaupt in Betracht zieht, muss er sicherstellen, dass es alle Updates hat, alle neuesten Updates aus dem vorgelagerten Repository, und stellt sicher, dass sein gegabeltes Repository sowie das lokales Depot, sind auf dem neuesten Stand. Wir haben bereits in den letzten Vorlesungen gesehen, wie das gemacht werden kann . Das zweite , was diese Schleife sicherstellen muss , ist, dies tatsächlich als Feature-Branch über dem Hauptzweig zu lesen. Also lass uns das ganz schnell machen. Ich werde zu Feature Ten Branch wechseln. Ich werde mit der rechten Maustaste auf das letzte Commit aus dem Hauptzweig klicken. Und dann werde ich diese Option wählen, die besagt, dass der aktuelle Zweig darauf neu basiert. Auf diese Weise werden wir mögliche Konflikte, die auftreten könnten , aus dem Weg räumen. Wenn Sie auf Konflikte stoßen, wussten Sie bereits, wie Sie damit umgehen sollten. Sobald Sie damit fertig sind, werden Sie all diese Änderungen tatsächlich in das Remote-Repository oder in das geforkte Repository oder den Ursprung übertragen das Remote-Repository oder in das . Also lasst uns all diese Änderungen vorantreiben. Wir erhalten eine Aufforderung, die besagt, dass die Zweigfunktion Dan keine Remote-Filiale hat. Möchten Sie diese Filiale veröffentlichen? Ich sage, okay, ich möchte den Origin-Säure-Modus wählen. Das ist es, was ich veröffentlichen oder unsere Änderungen vorantreiben möchte . Es ist erfolgreich. Das ist auf Lukes Konto gegangen und hat gesehen, ob sich die Dinge widerspiegeln. Und tatsächlich sehen Sie jetzt, dass ich die Seite neu laden kann. Sie sehen jetzt diese neue Filiale. Als Nächstes werden wir sehen, wie wir einen Pull-Request stellen können , um unsere Änderungen am Hauptzylinder vorzuschlagen. Wir sehen uns als Nächstes. 100. 1307 Anheben des pull und Zusammenführen der Änderungen im upstream: Lassen Sie uns sehen, wie Luke diese Änderungen vorschlagen kann, um sich zu ergeben, indem er eine Pull-Anfrage auslöst. Es gibt mehrere Möglichkeiten, dies zu tun. Hier siehst du bereits eine Option zum Vergleichen und Auslösen des Pull Requests. Sie können entweder hier klicken oder den Feature-Branch in der Liste auswählen. Klicke dann auf das Drop-down-Menü unter „Contribute“ und du siehst dieselbe Option, um einen Pull Request zu öffnen. Alternativ kannst du auch zum Abschnitt Pull Requests gehen und einen neuen Pull Request stellen. Wie auch immer Sie vorgehen, Sie werden den Bildschirm sehen, auf dem wir die Zweige vergleichen müssen , um den Unterschied zwischen beiden zu erkennen. Hier werden wir den Hauptzweig des Upstream-Repositorys mit dem Feature-Zweig des geforkten Repositorys vergleichen Upstream-Repositorys mit dem Feature-Zweig . Das Repository hier bezieht sich auf das Upstream-Repository. Und hier haben wir den Hauptzweig ausgewählt. Das Haupt-Repository zeigt hier auf das gegabelte Repository. Und hier müssen wir den Feature-Branch auswählen. Das wird also eine Zusammenfassung aller Änderungen zeigen , die wir gerade im Feature-Branch eingeführt haben . Wir können jetzt einfach weitermachen und den Pull Request erstellen. Der Prozess ist dem Pull-Request-Prozess, über den wir zuvor gesprochen haben, ziemlich ähnlich . Sobald der Pull Request ausgelöst wurde, können sie die Änderungen tatsächlich überprüfen. Er kann entweder akzeptieren oder ablehnen oder Sie bitten, an einer Reihe von Kommentaren zu arbeiten usw. Gehen wir jetzt zum Cinders-Dashboard. Laden Sie das Haupt-Repository neu. Hier wird der Pull-Request angezeigt. Lass uns darauf klicken. Wir haben bereits über eine Vielzahl von Dingen gesprochen, die wir hier tun können. Zum Beispiel kann ich einfach Rabatte sagen und zusammenführen. Aber bevor wir eine Zweigvorhersageregel haben, sollten wir, um mindestens eine Überprüfung durchzuführen, die Änderungen schnell überprüfen und sagen, dass ich mit allen Änderungen zufrieden bin. Ich werde die Bewertung genehmigen und einreichen. Jetzt kann ich tatsächlich eine dieser Optionen wählen. Vielleicht würde ich gerne mit Merge gehen. Bestätigen Sie Zusammenführen. Und jetzt werden alle diese Feature-bezogenen Änderungen im Hauptzweig zusammengeführt. Sie sehen also all diese Dateien hier, einen Punkt TXT und zwei Punkt TXT. Und wir sind in der Hauptzweige. Während des gesamten Prozesses wurde Luke niemals als Mitarbeiter im ursprünglichen Depository oder dem vorgelagerten Repository hinzugefügt . Dennoch konnte er zu diesem Projekt beitragen. Ich hoffe es ergibt Sinn. Wir sehen uns als Nächstes. 101. 1308 Erkundung bestehender öffentlicher Projekte: In diesem Video werden wir eines der vorhandenen Projekte untersuchen, die auf GitHub verfügbar sind, und prüfen, ob wir anhand dessen, was Sie in diesem Kapitel gelernt haben, einen Sinn daraus machen können . Wenn Sie ein Projekt im Sinn haben, das Sie bereits kennen, können Sie es hier durchsuchen. Können Sie gehen, um zu erkunden, um einige der öffentlichen Projekte zu erkunden. Sie können sich auch Projekte ansehen , die auf einem bestimmten Thema basieren. Hier sehen Sie eine Liste von Themen, die in alphabetischer Reihenfolge angeordnet sind. Hier finden Sie eine Liste beliebter Themen. Lass uns auf vielleicht reagieren klicken. Lassen Sie uns hier nach dem Zufallsprinzip alle Projekte öffnen . Ein x-Punkt ist. Ich suche mir einfach etwas Zufälliges aus. Vielleicht dieses eine ikonische Framework. Das Erste, was Ihnen beim Besuch der Projektseite auffallen wird, ist die Readme-Datei. Readme-Datei enthält in der Regel Informationen über die Software, Informationen über die Software, wie Sie sie installieren können, falls Sie als Mitwirkender für dieses Projekt beginnen möchten. Was sind alle Schritte, die daran beteiligt sind? Um als Mitwirkender zu beginnen, finden Sie Projekte, die Pflanzen sind, und eine Menge solcher Informationen in der ReadMe-Datei. Das ist also wahrscheinlich der Ausgangspunkt. Wenn Sie mit einem bestimmten Projekt beginnen möchten. Sobald Sie die ReadMe-Datei durchgesehen haben, können Sie mit dem Beitrag beginnen. Aber lassen Sie uns den Abschnitt Pull Request hier untersuchen. Wie Sie sehen können, hat es derzeit etwa 33 Schauspieler schlechte Anfragen, die noch zusammengeführt werden müssen, überprüft werden. Im Grunde werden Sie ein paar Arten von Anfragen sehen . Die erste ist die, über die wir in unseren vorherigen Vorlesungen gesprochen haben. Die zweite ist etwas , über das wir noch nicht gesprochen haben. Es heißt Draft Pull Requests. Man kann sagen, dass ein bestimmter Pull Request ein Entwurf für eine Anfrage ist. Sie sich dieses Symbol ansehen und Wenn Sie sich dieses Symbol ansehen und es ausgegraut ist, handelt es sich um einen Pull-Request-Entwurf. Sie fragen sich vielleicht, was ein Entwurf für Anfragen ist. Wir werden in den kommenden Vorlesungen darüber sprechen. Aber im Grunde genommen, wenn Sie Änderungen haben, bei denen es sich nur um vorgeschlagene Änderungen handelt nur um vorgeschlagene Änderungen über die Sie die Diskussion führen oder Feedback entgegennehmen möchten, jedoch nicht wirklich zusammengeführt werden sollen. Dann können Sie einen Entwurf für Anfragen erstellen. Leiten Sie einfach diese Diskussion ein. Alle anderen können sich Ihre Codeänderungen ansehen und einige Kommentare dazu abgeben. Und auf dieser Grundlage entscheiden Sie, ob Sie damit fortfahren möchten oder nicht. Du bemerkst auch diese sogenannten Labels rechts neben jedem Titel der Pull Requests. Auch dies werden wir in den kommenden Vorlesungen ansprechen . Bezeichnungen würden es Ihnen jedoch im Wesentlichen ermöglichen die Umfrage-Anfragen zu klassifizieren. Mit anderen Worten, es würde Ihnen helfen die schlechten Anfragen zu kategorisieren. Wenn ich zum Beispiel auf dieses Label klicke, siehst du alle Pull Requests, die diesem bestimmten Label entsprechen . Als Eigentümer des Repositorys möchte ich mir eine Liste von Pull Requests ansehen , die einem bestimmten Label entsprechen. Das kann ich machen. Vielleicht sehen Sie hier eine Menge anderer Dinge , über die wir noch nicht gesprochen haben. Wir könnten sie in den kommenden Vorlesungen untersuchen. Aber ich denke, Sie haben ein Stadium erreicht, in dem Sie selbst Dinge lernen können. In der Tat ist das Ziel dieses Kurses, Sie dazu zu bringen, auf sich allein gestellt zu sein. Ich kann wirklich nicht alles lehren, was da draußen ist. Meine Aufgabe ist es, dass Sie sich mit der Technologie wohl fühlen . Und ich denke, bis jetzt haben wir dieses Stadium erreicht. Es liegt nun an Ihnen, diese Fähigkeiten zu erforschen, darüber hinaus zu gehen und etwas zu tun, um diese Fähigkeiten weiter auszubauen. Eine der besten Möglichkeiten, dies zu tun, besteht im Grunde darin , eines dieser Projekte tatsächlich beizutragen. Wenn du zum Beispiel React oder Python oder was auch immer lernst , wirf einfach einen Blick auf einige Projekte, die sich hier spezielle Thema beziehen, und fange an, Beiträge zu leisten. Jedes Projekt muss einige Anweisungen enthalten, wie Sie als Mitwirkender beginnen. Sie können das durchgehen und mit dem Beitrag beginnen. sind also alle Pull Requests, die von Leuten wie dir und mir gestellt wurden. Und Sie können sehen, dass dieses Projekt über 13.000 Mal gegabelt wurde . Zum Zeitpunkt dieser Aufnahme. Werfen wir einen Blick auf die Liste der Probleme. Derzeit gibt es also ungefähr 554 Probleme. Wenn du einen Fehler melden oder eine neue Funktion vorschlagen möchtest, kannst du das auch tun, indem du auf Neues Problem klickst. Sie können den Bericht, einen Fehler oder eine Anfrage für eine Funktion hinzufügen . Sie können die Dokumentation durchgehen und so weiter. Dieses Layout ist tatsächlich für dieses Projekt angepasst. Sie sich ansehen , wird möglicherweise ein etwas anderes Layout Je nach dem Projekt, das Sie sich ansehen , wird möglicherweise ein etwas anderes Layout angezeigt. Nehmen wir zum Beispiel an, ich habe ihre Software verwendet und einen Fehler gefunden, und dann wollte ich diesen Fehler melden. Also kann ich auf jeden Fall darauf klicken. Und sie haben ein Format entworfen, um den Fehler zu melden. Zunächst wollten sie sichergehen, dass ich die Richtlinien für Beiträge lese. Sobald ich das getan habe, kann ich auf diese Checkbox klicken, ihren Verhaltenskodex usw. Washington, welcher Bug entscheidet? Was ist das aktuelle Verhalten, was ist das erwartete Verhalten? Klare Schritte zur Reproduktion und eine Menge anderer Informationen, um letztendlich jemandem zu helfen, der diesen Fehler beheben wollte , alle Informationen zu erhalten , die er zur Behebung des Fehlers benötigt. Kehren wir zu den Problemen zurück. Sie können sich also diese Probleme ansehen. Wenn Sie glauben, eines dieser Probleme beheben zu können, wissen Sie bereits, was zu tun ist. Sie müssen nur das Projekt forken, das Projekt Ihren lokalen Computer klonen, den Fehler beheben, diese Änderungen in das geforkte Repository übertragen und dann die Pull-Requests auslösen. Wie ich bereits sagte, nimm das als Aufgabe und trage tatsächlich zu seltsamen , wertvollen Projekten auf GitHub bei. Sobald Sie Ihre Pull Requests zusammengeführt oder von den Code-Eigentümern genehmigt haben, Sie sehr zufrieden sein und Ihnen ein werden Sie sehr zufrieden sein und Ihnen ein gewisses Erfolgserlebnis vermitteln. Sobald du siehst, dass das passiert. Es kann einige Zeit dauern bis der gesamte Vorgang abgeschlossen ist. Aber das kann ich dir nur empfehlen. Und auf diese Weise setzt du alles zusammen. Was Sie bisher in diesem Kurs gelernt haben. Im Rest des Kurses werden wir über all die fehlenden Teile dieser Technologien sprechen . Aber wie ich bereits sagte, ich denke, wir haben ein Stadium erreicht, in dem Sie alleine sind und alle wichtigen Themen von Git und GitHub gelernt haben . Ich wünsche dir viel Glück, aber wir sind noch nicht fertig mit dem Kurs. Wir haben auch viele andere Themen zu besprechen. Also ja, nimm es als Aufgabe auf und trage zu wertvollen Projekten bei. Wir sehen uns als Nächstes. 102. 1401 Branching erklärt: Lassen Sie uns über die Strategie für die Verzweigung sprechen. Wir haben den Master oder den Hauptzweig. Und im Allgemeinen sollte alles, was in den Master oder den Hauptzweig fließt , produktionsbereit sein. Mit anderen Worten, Sie müssen davon ausgehen , dass Ihr Kunde Wasser in den Master oder den Hauptzweig gelangt dass Ihr Kunde Wasser in den Master oder den Hauptzweig . In der Tat könnten Sie genauso gut eine Art Automatisierung verfügen, bei der sie ständig den Code vom Master oder dem Hauptzweig auswählt, ein Artefakt erstellt und auf die Produktionsregistrierung, damit Ihre Kunden jetzt all diese neuen Updates oder Funktionen erhalten. Stellen Sie sich beispielsweise vor, Sie entwickeln ein Betriebssystem wie Windows. In dem Moment, in dem Sie etwas auf dem Master oder der Hauptniederlassung liefern , Ihren Kunden möglicherweise ein Pop-up angezeigt, das besagt, dass ein neues Service Pack zur Installation verfügbar ist. Anschließend installieren sie dieses Service Pack, um die neuesten Funktionen oder Fehlerbehebungen zu erhalten. Die Tatsache, dass es sich um produktionsfertigen Code handelt , bedeutet, dass Sie vorsichtig sein sollten , was sich innerhalb des Masters oder des Hauptzweigs befindet. Was innerhalb des Master- oder Hauptzweigs passiert, sollte unbedingt getestet werden. Qualitätsgesicherter Code, bei dem Sie wirklich keine Fehler riskieren können. Aus diesen Gründen kann er daher den Master oder den Hauptzweig nicht zur Verfügung stellen, damit Entwickler ihren Code beisteuern können. Wenn Sie das tun, erhalten Ihre Kunden jedes Mal, wenn jemand den Code im Hauptzweig für jede einzelne Funktion zusammenführt den Code im Hauptzweig für jede einzelne Funktion , auch diese Updates, die natürlich nicht so getestet wurden. Und offensichtlich ist es keine gute Praxis. Was wir also haben werden, ist, dass wir einen anderen Zweig haben werden, den Entwicklungszweig. Und dies wird der aktivste Zweig sein , zu dem alle Entwickler beitragen würden. In dem Moment, in dem wir ein GitHub-Repository erstellen, werden wir den Entwicklungszweig als Standardbranch festlegen, sodass wir immer dann, wenn jemand den Code in seinen lokalen Computer klont, jemand den Code in seinen lokalen Computer klont, die Entwicklungszweig als Standardbranch. Tatsächlich lassen wir nicht zu, dass irgendjemand zum Master oder zum Hauptzweig beiträgt. Stattdessen würden wir nur den Entwicklungszweig oder den Beitrag öffnen . Nur eine bestimmte Gruppe von Personen hat die Berechtigung auf dem Master oder dem Hauptzweig, den qualitätsgeprüften Code tatsächlich zusammenzuführen. Und selbst in der Entwicklung wird jedes Mal, wenn jemand einen Code liefert , eine Pull-Anfrage ausgelöst. Wir könnten auch hier eine Art Automatisierung haben , um die Qualität des Codes zu überprüfen. Überprüfen Sie beispielsweise, ob Sicherheitslücken bestehen , versuchen Sie, einen Scan durchzuführen, nach Programmfehlern zu suchen usw., um sicherzustellen, dass der Code immer noch einhält jedes Mal, wenn jemand zu dieser Branche beiträgt , die Qualitätsstandards der Organisation erfüllt. Stellen Sie sich nun vor, dass in der Entwicklungsbranche eine Reihe von Funktionen bereitgestellt werden. Und zu diesem Zeitpunkt wurde uns klar, dass wir diesen ganzen Fötus tatsächlich für den Endbenutzer freigeben können . Jetzt könnten wir all diese Änderungen tatsächlich mit den neuesten Funktionen im Master-Branch zusammenführen . So werden Ihre Kunden anfangen, es zu verwenden. Aber wir müssen uns noch um einen Schritt kümmern. Wir werden tatsächlich noch einen weiteren Branch haben , den Release-Zweig. Und genau das werden wir die neuesten Entwicklungen aus der Entwicklungsbranche zusammenführen . Der Release-Zweig befindet sich zwischen dem Master-Hauptzweig und dem Entwicklungszweig. Es ist wie eine Registrierung vor der Produktion bei der wir möglicherweise einige Automatisierungstests durchführen, um sicherzustellen, dass alle Funktionen wie erwartet funktionieren. Sobald der Test abgeschlossen ist, wird alles als versichert bezeichnet. Wir werden dann alle Änderungen vom Release-Zweig zum eigentlichen Master-Branch zusammenführen . Und der Code würde jetzt die offizielle Version der Software werden die offizielle Version der , die die Kunden verwenden werden. Nun, ich bin mir sicher, dass sich das alles verwirrend anhören könnte. Lassen Sie mich ein Beispiel in Echtzeit nehmen und Sie noch einmal durch dieses Diagramm führen. Also verstehe ich es besser und das werden wir als Nächstes tun. 103. 1402 Branching mit Realtime: Okay, lassen Sie uns das alles anhand eines kurzen Echtzeitbeispiels verstehen . Stellen Sie sich vor, wir haben eine Reihe von Entwicklern, die ihren Code und eine ganze Reihe von Funktionen in den Entwicklungszweig eingebracht haben. Oder es könnte sein, dass Ihr Projekt von einer Menge Leute gegabelt wurde. Und sie warfen Pull-Anfragen auf, die schließlich in den Entwicklungszweig integriert wurden. Aber letztendlich haben wir eine Reihe von Funktionen in einem Entwicklungszweig. Und zu diesem Zeitpunkt haben wir erkannt, dass wir dies tatsächlich als neue Version an den Kunden liefern können . Jetzt könnten wir einfach all diese Änderungen mit dem Release-Zweig zusammenführen . Aber davor werden wir tatsächlich einen weiteren Zweig erstellen, die Version einen Punkt oder überhaupt, mit der Annahme, dass dies die allererste Version der Software ist , die wir veröffentlichen. Die Art von Format, das wir zur Verschlechterung der Software verfolgen, ist die sogenannte semantische Versionierung. Wir werden in den kommenden Vorlesungen darüber sprechen. Aber im Moment ist das die Version. Und wir werden unsere Filiale mit dieser Versionsnummer benennen . Wissen Sie, der Zweck, diesen Zweig in nur ein bisschen zu erstellen . Sobald wir also einen Zweig namens Teil eins Punkt o Punkt o aus dem Entwicklungszweig erstellt haben. Wir werden dann all diese Änderungen im Release-Zweig zusammenführen . Und hier finden all die Tests statt und alle zusätzlichen Dinge, die Sie tun möchten, können Sie hier drüben tun, bevor Sie diese Änderungen tatsächlich in den Master-Branch zusammenführen, was produktionsfertiger Code. Irgendwann landet es also auch im Master oder im Hauptzweig. Das Gute an dieser Strategie ist, dass Sie, während Sie damit beschäftigt sind , die Software zu veröffentlichen und die Software gründlich zu testen, bevor Sie sie tatsächlich in die Produktion aufnehmen, und Rom und andere Entwickler dies können tatsächlich weiter an dieser Aufgabe zu arbeiten und die Funktionen im Entwicklungszweig zu verwässern. Stellen Sie sich nun vor, der Kunde hat einen Bug gemeldet. Vielleicht würde eine Software es dem Kunden ermöglichen einen Fehler in dem Moment zu melden, in dem er definiert wurde. Nehmen wir also an, der Kunde von Weltanschauung den Fehler gefunden, er hat ihn gemeldet. Und Sie erkennen , dass es sich tatsächlich sehr schwerwiegenden Fehler handelt, der nach Priorität behoben werden muss. Was Sie also tun müssen, ist einen Branch aus diesem Versionszweig zu erstellen . Und Sie werden den Wert um eins erhöhen. Dies wird wiederum als semantische Versionierung bezeichnet. Wir werden darüber sprechen. Aber im Wesentlichen werden Sie einen Zweig aus der vorherigen Version erstellen . Und hier wirst du den Bug beheben. Sobald Sie den Fehler behoben haben, testen Sie alle Änderungen. Und dann werden Sie all diese Änderungen sowohl im Entwicklungszweig als auch im Release-Branch und eventuell auch im Master- oder Haupt-Branch zusammenführen Entwicklungszweig als auch im Release-Branch und . Ihr Kunde wird also den Fehlerbericht behoben haben , dass ich das alles ziemlich bald auf GitHub demonstrieren werde, damit Sie eine bessere Klarheit darüber haben was genau hier passiert. Wir sehen uns als Nächstes. 104. 1403 Semantische Versionierung erklärt: Lassen Sie uns über semantische Versionierung sprechen. Semantische Versionierung ist eine Standardpraxis , die in einer bestimmten Softwareversion , einer Bibliothek oder einer API angewendet wird. Und hier ist das Format der semantischen Versionierung. Der erste Teil ist die Hauptversion. Der zweite Teil ist die Nebenversion, und der dritte Teil wird als Patch bezeichnet. Die Funktionsweise der semantischen Versionierung in K, Software. Software unterscheidet sich geringfügig von der Funktionsweise einer API. Lassen Sie uns zunächst über eine Software sprechen, etwa einen Videoeditor oder ein Betriebssystem usw. Wann immer Sie wesentliche Änderungen haben gibt es einen riesigen Teil der Funktionen. Oder vielleicht haben Sie einige der vorhandenen Funktionen gelöscht , die erheblich geändert wurden, vorhandene Funktionen, dann sollten Sie in Betracht ziehen, die Hauptversion zu erhöhen. Wenn Sie das tun, setzen Sie die Werte sowohl für Minor als auch für Patch wieder auf 0 zurück. Oder wenn Sie nur ein paar Funktionen bereitgestellt haben und diese nicht sehr wichtig sind, können Sie erwägen, die Nebenversionsnummer zu erhöhen . Und wenn Sie über dieser Version noch Fehlerbehebungen oder Hotfixes haben , können Sie erwägen, die Patch-Version zu erhöhen , wenn Sie neue Hotfixes einführen, werden Sie weiter inkrementieren die Patch-Nummer gefällt mir so. Nehmen wir nun an, dass Sie an einigen weiteren Funktionen gearbeitet haben und es sich nur um geringfügige Änderungen handelt. Sie können die Nebenversionsnummer erneut erhöhen, müssen dann aber den Wert von Patch wieder auf 0 zurücksetzen. So funktioniert die semantische Versionierung. Und wie ich bereits erwähnt habe, die Art und Weise, wie dies im Falle einer API funktioniert geringfügig von einer API, wenn Sie den Wert der Hauptversion erhöhen , dass Sie eingeführt haben signifikante Änderungen, die nicht mehr abwärtskompatibel wären. Vielleicht haben Sie beispielsweise bestimmte Funktionen entfernt oder einige der vorhandenen Funktionen erheblich geändert. Das bedeutet, dass alle Projekte, die wir in einer früheren Version Ihrer Bibliothek verwenden , in Betracht ziehen müssen , ihren Code zu ändern bevor sie die neueste Version Ihrer Bibliothek verwenden können. Das bedeutet es, wenn Sie die Hauptversion inkrementieren. Erhöhung der Nebenversion würde jedoch bedeuten, dass die neuen Features oder Funktionen hinzugefügt wurden und niemand den Code ändern muss um den Code mit Ihrer Bibliothek kompatibel zu machen. Die Patches ähneln dem Patch, über den wir zuvor gesprochen hatten. Wenn wir es erhöhen, bedeutet das, dass Sie einen Bugfix oder einen Hotfix bereitgestellt haben. So funktioniert die semantische Versionierung. Wir sehen uns als Nächstes. 105. 1404 Git Tags verstehen: Lass uns über Tags sprechen und bekommen. Etag ist einfach ein Unterschied, der auf einen bestimmten Punkt in der guten Geschichte hinweist . Mit anderen Worten, ein Angriff würde einfach auf einen bestimmten Commit hinweisen. Das klingt vielleicht wie ein Zweig. Sogar Branch zeigt auf einen bestimmten Commit, und selbst Tag zeigt auf einen bestimmten Kampf. Aber der Unterschied zwischen den beiden ist, dass der Branch jedes Mal aktualisiert wird, wenn wir einen neuen Commit in der Verzweigung vornehmen. Und branch würde auf das letzte Commit zeigen, wohingegen das Tag konstant bleiben würde. Wenn wir ein Tag erstellen, das auf ein bestimmtes Commit verweist, bleibt es für immer so, es sei denn, wir machen explizit etwas mit diesem Tag. Was ist nun der Vorteil, ein Tag zu erstellen? Warum wollen wir einen Verweis auf einen bestimmten Commit erstellen und ihn konstant halten? Lass uns einen Blick darauf werfen. Dies ist aus unserem vorherigen Beispiel, 1 Sekunde, angenommen, dass wir eine neue Software auf den Markt gebracht haben und schließlich Änderungen im Master-Branch vorgenommen haben. Zu diesem Zeitpunkt werden wir ein Tag erstellen, das ihm die Versionsnummer der Software gibt, die ihren Namen hat. Da wir davon ausgehen, dass es sich eine allererste Version oder Software handelt, werden wir sie um einen Punkt oder Punkt o verschlechtern. Und dieses Tag zeigt auf diesen speziellen Commit, den Master oder den Hauptzweig. nun davon aus, dass wir einen Hotfix bereitgestellt haben. Und wieder einmal haben wir das im Master-Branch behoben geliefert. Wir werden ein weiteres Tag erstellen ihm eine Bewegungsnummer geben. Da es sich also um einen Bugfix oder einen Hotfix handelt, haben wir die Patch-Nummer einfach um eins erhöht. Im Wesentlichen folgen wir hier der semantischen Versionierung und dieses Tag zeigt oder hat die Referenz des Commits im Master-Zweig mit diesem Fix. Aber was bringt es, all diese Tags zu haben? Ein weiterer Anwendungsfall ist, sagen wir, ich wollte ein Artefakt erstellen , das auf einer bestimmten Version basiert. Vielleicht kann ich einen Befehl ausführen, der besagt, dass ich ein Artefakt für Version one dot o dot o erstellen möchte . Ich kann den Befehl ausführen, der dieses Tag angibt. Und das Tool würde das Artefakt für mich erstellen, das dann für die Produktionsregistrierung usw. bereitgestellt werden kann . Oder vielleicht kann ich es in die Versionshinweise aufnehmen, damit Kunden es herunterladen und verwenden können. In diesem Fall können wir branch nicht verwenden, da der Zweig von Zeit zu Zeit aktualisiert wird. In dem Moment, in dem wir ein neues Commit in der Branche vornehmen, würden sich Tags in einer solchen Situation als nützlich erweisen . Als Nächstes werden wir uns das alles in Aktion ansehen, damit Sie ein vollständiges Bild davon haben , was genau passiert und wie es funktionieren wird. Wir sehen uns als Nächstes. 106. 1405 Braching in Aktion: Okay, jetzt lass uns alles in Aktion sehen und ich hoffe du bist bereit dafür. Lassen Sie uns zunächst ein neues Projektarchiv erstellen. Nennen wir es vielleicht Super-Audio. Vielleicht erstellen wir überhaupt ein Audiobearbeitungswerkzeug. Und vielleicht möchte ich auch die Readme-Datei hinzufügen. Wenn Sie möchten, können Sie tatsächlich zu den Einstellungen gehen und den Standardzweignamen von main in einen anderen Namen ändern den Standardzweignamen von , wenn Sie möchten. Vielleicht können wir das in Master ändern. Das ist nicht verpflichtend. Aber ich mache es trotzdem. Ich werde das Projektarchiv erstellen . Wie Sie sehen können, haben wir den Master Branch. Und das wird der Produktionsschlüssel sein, was bedeutet, dass alles, was innerhalb der Master-Branche fließt , in die Produktion aufgenommen wird. Als Nächstes erstellen wir die anderen beiden Zweige. Einer wird der Zweig vor der Produktion sein, und wir geben den Namen als Veröffentlichung ein. Und ein weiterer Zweig ist für die Entwicklung bestimmt. Nennen wir es entwickeln. Dieser Zweig würde den neuesten Code von allen Mitwirkenden haben den neuesten Code von , die mit uns zusammenarbeiten. Gehen wir nun zu den Einstellungen und machen den Entwicklungszweig als Standardbranch. Nur damit jemand, der das Projekt klont, den Entwicklungszweig als Standardzweig sieht , in dem er einen Beitrag leisten kann. Also werden wir diesen Zweig von Master zu Develop ändern und auf Update klicken. Wenn ich jetzt zurückgehe, werden Sie sehen, dass der Olivenzweig bereits ausgewählt ist, da dies jetzt der Standardzweig sein wird . Um das Verhalten zu simulieren, müssen nun eine Reihe von Funktionen im Entwicklungszweig vorhanden sein. Ich füge einfach ein paar Dateien hinzu. Sie müssen jedoch davon ausgehen , dass wir möglicherweise einige funktionsbezogene Änderungen vorgenommen und zu diesem Zweig beigetragen haben. Es kann vorkommen, dass jemand anderes für das Projekt Pull Requests für diesen speziellen Branch erhebt. Wer auch immer dieses Projekt beschäftigt, es wird erwartet, dass die Race Pull Anfragen auf der Dollar-Branche stellen. Sie haben keinerlei Erlaubnis oder wir erwarten nicht , dass jemand Beiträge zum Release-Branch, zum Haupt-Zweig oder zum Master-Branch leistet. Lassen Sie uns also weitermachen und ein paar Dateien erstellen. Erstellen Sie eine neue Datei, nennen wir sie Feature One Dot TXT. Um die Dinge einfach zu halten, erstellen wir noch eine weitere Datei. Erstellen Sie beispielsweise eine neue Dateifunktion , um TXT zu dot, und schreiben Sie den Code fest. Wir haben also eine Menge Commits hier. Die erste war die Readme-Datei, und die anderen beiden sind für die Funktionen. Was ist jetzt als Nächstes zu tun? Kannst du raten? Vorausgesetzt, wir wollten unsere Software oder die erste Version unserer Software für den Endbenutzer veröffentlichen unsere Software oder die erste Version unserer . Nun, wir werden zuerst einen weiteren Zweig erstellen. Und wir werden diesen Zweig mit semantischer Versionierung benennen . Da es sich um eine sehr falsche Version der Software handelt , die wir auf den Markt bringen, werden wir sie als einen Punkt oder Punkt o benennen. Also werden wir diesen Zweig aus dem Entwicklungszweig heraus erstellen . In der Zwischenzeit können andere Entwickler weiterhin zur Dollarbranche beitragen. Aber was wir als Nächstes tun werden, ist, dass wir all diese Änderungen von diesem speziellen Branch, den wir gerade erstellt haben , mit dem Release-Zweig zusammenführen müssen all diese Änderungen von diesem speziellen Branch, den wir gerade erstellt haben , mit dem Release-Zweig . Ratet mal, was wir als Nächstes tun müssen. Möglichkeit, Pull-Anfragen zu erheben. Derzeit verfügt der Release-Zweig nicht über diese Funktion, was zu Änderungen führt , wann sie hier abgerufen werden können. Ich gehe zu Pull Requests erstelle einen neuen Pull Request. Hier wähle ich den Release-Zweig aus und möchte ihn mit dem Versionszweig vergleichen , nennen wir es. Hier sind also alle Funktionen, die zu Änderungen führen. Und ich werde den Pull Request erstellen. Angenommen, wir haben alle Formalitäten der Überprüfung, des Scannens von Leiterplatten und allem erledigt , lassen Sie uns all diese Änderungen zusammenführen. Wir wollen diesen Zweig noch nicht löschen da er sich zu einem späteren Zeitpunkt als nützlich erweisen wird. Wenn Sie also zum Repository zurückkehren und zum Release-Zweig gehen, haben Sie jetzt all diese Feature-bezogenen Änderungen. Wir könnten also einige automatisierte Tests durchführen und davon ausgehen, dass alles wie erwartet funktioniert, haben wir uns jetzt entschlossen, all diese Änderungen in unserem Modul, diese Änderungen auf den Master-Branch davon ausgehen, dass alles wie erwartet funktioniert, haben wir uns jetzt entschlossen, all diese Änderungen in unserem Modul, diese Änderungen auf den Master-Branch zu übertragen dass unsere Kunden anfangen werden, unsere Software zu verwenden. Also werden wir noch einmal einen Pull Request stellen. Neue Pull-Anfrage. Hier wähle ich den Master-Branch aus. Und hier wähle ich den Release-Zweig aus. Und wir werden weitermachen und den Pull Request erstellen. Lassen Sie uns all diese Änderungen auch mit dem Master-Branch zusammenführen. Vielleicht mit drei Bits und Merge. Wir können auch Squash Commit durchführen, um alle Commits zu einem einzigen Commit zu kombinieren. Aber ich denke, wir kommen damit klar. Deshalb haben wir unsere Software jetzt offiziell für den Endbenutzer freigegeben . Wenn ich also auf Master klicke, wirst du sehen, dass die Funktion hier zu Änderungen führt. Idealerweise sollten wir genau hier ein Tag erstellen. Aber wir werden in den kommenden Vorlesungen über Tags sprechen . Wir sehen uns als Nächstes. 107. 1406 Workflow mit heißem Fix in Aktion: Okay, lass uns weitermachen. Gehen Sie nun davon aus , dass Ihr Kunde einen Fehler gemeldet hat und Sie erkennen, dass es sich tatsächlich um einen kritischen Fehler handelt , der nach Priorität behoben werden muss. Sie planen also kein Hotfix. Was ist das Erste , was wir tun müssen? Nun, wir haben bereits eine Filiale zur Hand. Die, die wir zuvor mit dem Versionsnamen erstellt hatten. Hier ist es praktisch. Wir können einen weiteren Branch aus diesem Branch erstellen , um den Fehler zu beheben. Und dann werden wir all diese Änderungen im Entwicklungszweig sowie in der Veröffentlichung und schließlich auch im Master-Branch zusammenführen all diese Änderungen im Entwicklungszweig sowie in der Veröffentlichung und . Die Kunden würden also ein Update mit dem Update erhalten. Also habe ich diesen speziellen Versionszweig ausgewählt. Lassen Sie uns nun einen weiteren Zweig erstellen, um den Fehler zu beheben und die Version zu erhalten, die wir hier angeben müssen. Da du auf Hotfix gehst, wurde der Wert der Patch-Version um eins erhöht . Diesmal wird der Name der Filiale 101 sein. Ich werde diesen Zweig erstellen. Noch einmal, um das Verhalten der Behebung eines Fehlers zu simulieren. Lassen Sie mich einfach einen Dateifehler erstellen, fixierter Punkt dxdy, was auch immer. Und ich werde diese Änderung begehen. Wir müssen diese Änderungen nun mit dem Entwicklungszweig zusammenführen. Wir können es entweder von hier aus machen. Wir können den Querschnitt ziehen und eine neue Pull-Anfrage stellen. Wählen Sie den Branch aus, den wir gerade erstellt haben, und wir werden ihn mit dem Entwicklungszweig vergleichen. Also haben wir das hier behoben. Erstellen Sie eine Produktklasse und lassen Sie uns raus. Also mach weiter und füge den Bugfix mit dem Entwicklungszweig zusammen. Und tatsächlich, wenn Sie wieder in den Entwicklungszweig gehen , sehen Sie die Fehlerbehebung. Wir werden ähnliche Schritte auch für die Veröffentlichung ausführen. Wir haben eine Pull-Anfrage gestellt. Wir werden uns hier für die Veröffentlichung entscheiden. Und der Bugfix-Branch hat die Pull-Requests gelöscht. Und das führt diese Änderungen zusammen. Jetzt, nach vielen Tests, funktionieren die menschlichen Dinge großartig. Wir werden die Änderungen vom Release-Zweig zum Master-Branch zusammenführen . Wie Sie sehen können, haben wir jetzt den Bug Fix im Release-Zweig. Lass uns ganz schnell einen Pull Request erstellen. Wir werden den Release-Zweig vergleichen. Es tut mir leid. Wir werden den Master-Branch und den Release-Branch vergleichen und den Release-Branch und all diese Änderungen im Master-Branch zusammenführen. Um zurück zu gehen und zum Master Branch zu wechseln, sollte in der Lage sein, den Bugfix zu sehen und so liefert man einen Patch. Als Nächstes werden wir darüber sprechen, wie wir Tags erstellen können. Tatsächlich hatten wir die Erstellung des Tags in der vorherigen Version unserer Software verpasst . Wir können aber auch Tags für die Commits erstellen , die bereits durchgeführt wurden. Wie wir das machen, wir werden als Nächstes über etwas sprechen . Wir sehen uns als Nächstes. 108. 1407 Tags erstellen Annotated vs Lightweight Tags Pushing Tags in Remote.: Okay, lass uns sehen, wie wir Tags erstellen können. Wir können die create -Tags auf GitHub hinzufügen, oder wir können es auch über die Befehlszeile von unserem lokalen Git aus tun . Wir werden beide Wege sehen. Lassen Sie uns zunächst untersuchen, wie wir das lokal von Git Bash aus tun können . Übrigens, um Zeit zu sparen, habe ich Herrn Luke bereits als einen der Mitarbeiter dieses Projekts hinzugefügt . Und hier ist Lukes Bericht. Das erste, was Luke tun wird , ist, dass er dieses Projekt tatsächlich auf seinem lokalen Computer klonen wird . also davon aus, dass dies Lukes Computer ist. Ich werde Git Bash hier starten. Und lassen Sie uns das Projekt schnell klonen. Git klonen. Ich füge die URI ein. Gehen wir also in das Projekt ein. Löscht den Bildschirm. Lassen Sie uns jetzt Tags erstellen. Wir können das create ein Lightweight-Tag oder ein annotiertes Tag hinzufügen . Im Grunde gibt es also zwei Arten von Tags, die wir erstellen können. Wenn es um Lightweight-Tag geht, handelt es sich nur um einen Namen oder eine Kennung und wird zu einem bestimmten Commit ernannt. Wohingegen, wenn es um annotierte Tags geht, zusätzlich zu einem Namen und einem darauf hingewiesen, um unterzubringen. Es wird auch einige Metadaten enthalten, wie den Namen des Taggers, die E-Mail-Adresse, das Datum usw. Wenn Sie alle Metadaten zusammen mit dem Tag speichern möchten, erstellen wir besser ein kommentiertes Tag und keinen leichten Tank. Und in den meisten Fällen ist es immer wichtig, ein beschriftetes Tag oder einen leichten Panzer zu erstellen . Aus offensichtlichen Gründen. Wir werden wissen, wer es geschaffen hat , wenn er es geschaffen hat. Und wir würden sogar die E-Mail-Adresse der Person kennen , die diesen Tank erstellt hat. Lassen Sie uns zunächst sehen, wie wir ein annotiertes Tag erstellen können. Im Grunde haben wir kein Tag für die erste Version unserer Anwendung erstellt . Lassen Sie uns also zuerst den Zweig beherrschen. Wenn ich verzweige, iPhone, nein. Sie sehen, dass alle diese Zweige Remote-Tracking-Zweige sind, aber wir haben keine lokale Niederlassung für den Master-Branch. Um das zu erreichen, lassen Sie uns einen Git-Checkout machen oder gut zum Master-Branch wechseln. Schauen wir uns nun die Liste der Commits an , die sich im Master-Branch befinden. Im Grunde sollten wir hier also idealerweise ein Tag erstellen , das die allererste Version unserer Anwendung darstellt . Das ist also kurz vor dem Hotfix, den wir gegeben hatten. Wie erstellen wir also ein Tag für einen der vorherigen Kommentare? Lass uns einen Blick darauf werfen. Der Befehl zum Erstellen des Tags lautet also git tag, Bindestrich ein Tag mit vier Anmerkungen. Und wir geben eine eindeutige Kennung oder einen Namen für dieses Tag an. Und in der Standardpraxis möchten wir die semantische Version unserer veröffentlichten Version angeben. Das wird also alles die allererste Version unserer Anwendung sein . Und wir würden jetzt den hashCode der Fackel spezifizieren. Wir möchten, dass dieses Tag auf zeigt. Das ist, als wären wir in der Vergangenheit zurückgegangen und hätten ein Tag erstellt. Bei diesem speziellen Commit. Ich füge diesen Hashcode ein. Darüber hinaus werden wir eine aussagekräftige Nachricht bereitstellen, in der beschrieben wird, worum es bei diesem Tag geht. Eine Beschreibung darüber schien es durcheinander gebracht zu haben. Geben wir den Befehl erneut ein. Git-Tag. Bindestrich a. Wee one.org.au den HashCode-Bruch m angegeben. Summenbeschreibung. Wenn Sie die Nachricht nicht mit der Option „Bindestrich m“ versehen, wird ein Standard-Texteditor geöffnet , in den Sie eine Nachricht eingeben können. Wenn Sie diese Option jedoch angeben, wird eine Notiz usw. geöffnet. Das sollte also ein Tag für uns erstellen. Wenn Sie den Befehl git tag ausführen, sehen Sie die gesamte Liste der verfügbaren Tags. Wenn also jemand das Projekt klonen würde, wird er auch all diese Tags sehen. Lassen Sie uns nun ein Lightweight-Tag erstellen. Und der Befehl dafür ist ziemlich einfach. Holen Sie sich ein Tag und einen Bezeichner oder einen Namen für dieses Tag. Also sage ich dieses Mal, dass wir einen Punkt, Punkt eins. Denn wenn Sie versuchen, ein Tag zu erstellen, würde es standardmäßig auf denselben Commit verweisen, auf den der Head zeigt. So hatte dies derzeit auf den letzten Commit-Off-Master-Branch hingewiesen . Und so wird dieses Tag, das ein Lightweight-Tag ist, weil wir die Option für die Silbentrennung nicht bereitgestellt haben, auch auf den Desk Commit Off Master Branch verweisen , der den Fehlerbehebungen enthält. Und wenn Sie sich erinnern, haben wir gemäß der semantischen Versionierung den Wert der Patch-Version um eins erhöht . Drücken wir die Eingabetaste. Und wir haben gerade ein weiteres Tag erstellt. Eines ist ein annotiertes Tag und das andere ist ein Lightweight-Tag, das keinerlei Metadaten enthält. Wie veröffentlichen wir nun all diese Tags im Remote-Repository? Nun, wir verwenden einfach den Standard-Push-Befehl. Aber wir müssen explizit angeben , dass wir auch Tags pushen wollen. Standardmäßig drückt der Befehl push die Tags nicht. Also werde ich es explizit wissen lassen. Wir werden also sagen, dass Git Push Origin die Fernbedienung ist, auf der wir auch all diese Steuern erhöhen wollen. Wir können angeben, welches Tag wir pushen möchten , indem wir seinen Namen, den Bezeichner, angeben . Wir können auch Tags sagen , um alle Tags an das Remote-Repository zu übertragen. Da Luke bereits die Berechtigung für dieses Projektarchiv hat, konnten wir all diese Tags auf dieses Depot übertragen. Und du kannst sie hier sehen. Wenn Sie auf diese Tags klicken, werden Sie sehen, dass wir diese beiden Panzer haben . 109. 1408 Verstehe, wie Tags gespeichert werden Freistehender Kopfzustand mit Tags: Zuvor hatten wir ein paar Tags erstellt. Einer ist ein beschrifteter Tag, der andere ist ein leichter Tank. Lassen Sie uns sehen, wie sie tatsächlich gespeichert werden. Wenn Sie zum refs-Ordner gehen, sehen Sie jetzt diesen Ordner mit den Namensschildern. Und dort werden Sie diese beiden Tags sehen. Aber sie annotieren Tag wird tatsächlich als Objekt gespeichert. Während der leichte Panzer einem Ast ähnelt, ist er kein Objekt. Also lasst uns Washington 101 eröffnen. Und es weist auf einen bestimmten Kommentar hin. Lassen Sie uns versuchen, dieses Objekt mit diesem HashCode hübsch zu drucken . Git cat-Datei. Schauen wir uns zunächst den Typ dieses Objekts an . Wie Sie sehen können, zeigt es auf das Kometenobjekt. Wenn Sie dieses Objekt ziemlich drucken möchten, werden Sie die Details zu diesem Commit sehen. Aber jetzt öffnen wir die Datei, die ein kommentiertes Tag war, und sehen, worauf sie verweist. Lassen Sie mich diesen Hashcode kopieren, zu Git Bash zurückkehren und versuchen, den Typ des Objekts zu drucken. Dieses Mal wird es vom Typ Tag sein. Und wenn Sie sich den Inhalt dieses Tag-Objekts ansehen, sehen Sie den Commit, auf den es verweist. Und dazu gibt es auch einige Metadaten. Wie der Bezeichner des Tags, wer es erstellt hat, und auch eine Beschreibung des Tags. Wir können den Status des Repositorys auch an einem bestimmten Tag anzeigen, indem wir den Befehl git checkout verwenden. Also lass mich git tag machen , um einen Blick auf die Liste der verfügbaren Tags zu werfen. Und ich verwende den Befehl git checkout den Namen des Tags an. Vielleicht möchte ich mein Projektarchiv auf dieses Datum bringen. Und wie Sie sehen können, befinden wir uns im distanzierten Kopfzustand. Wir haben bereits in einem unserer vorherigen Kapitel darüber gesprochen . Aber wenn Sie zum Arbeitsverzeichnis zurückkehren, werden Sie diesen Hotfix nicht sehen. Denn zum Zeitpunkt der Erstellung dieses Tags haben wir dieses Update nicht. Hoffe es macht Sinn. Wir sehen uns als Nächstes. 110. 1409 Veröffentlichungen und Tags auf GitHub erstellen: Okay, lass uns über Veröffentlichungen sprechen. Gemäß dem, was GitHub über Laser zu sagen hat. Hier ist was es heißt. Sie können eine Release-to-Packet-Software zusammen mit den Versionshinweisen und Links zu Binärdateien erstellen den Versionshinweisen und Links zu , die andere Benutzer verwenden können. In diesem Aufruf werden Sie einige technische Dokumentationen zu Ihrem Release bereitstellen . Sie sollten also alle Änderungen auflisten , die Teil der neuen Version sind. Die Installationsschritte, Binärdateien sind ausführbare Dateien usw. Sie würden all diese Informationen in die Versionshinweise aufnehmen , um Ihren Kunden oder Endbenutzern zu helfen , alles über die neue Version zu verstehen die sie wissen müssen. Also lasst uns weitermachen und versuchen, eine neue Version auf GitHub zu erstellen . Übrigens verwendet Ihre Organisation möglicherweise ein anderes Tool, um die Veröffentlichung zu dokumentieren. Wenn Sie kein solches Tool haben, können wir GitHub dafür verwenden. Wir können ein Tag für eine bestimmte Version zuordnen. Wir können zum Beispiel eine der vorhandenen auswählen. Oder wir können weitermachen und ein neues Tag erstellen. Und so erstellst du ein neues Tag auf GitHub. Zum Beispiel können Sie vielleicht sagen, wir haben einen Punkt 0 Punkt zwei oder was auch immer. Im Moment haben wir keine neuen Änderungen. Es macht für uns keinen Sinn, die Version unserer Software zu erweitern . Stattdessen verwenden wir nur eines der vorhandenen Tags. So wie. Wir geben ihm einen Namen. Lassen Sie V los, ein Punkt o Punkt o zum Beispiel. Hier. Ihr Fahrrad braucht einige Zeit, um alles über die Veröffentlichung zu dokumentieren. Vielleicht würden Sie also alle angesprochenen Probleme auflisten , alle neuen Funktionen, die eingeführt wurden. Wenn es veraltete Funktionen gibt, sollten Sie diese ebenfalls auflisten. Vielleicht einige Installationsschritte, herunterladbar, ausführbar, Es ist usw. Sie würden alles , was Ihr Endbenutzer sehen und verstehen soll, über die Veröffentlichung platzieren . Und wenn Sie damit fertig sind, veröffentlichen Sie die Veröffentlichung. Und so sieht es aus. Offensichtlich haben wir das nicht genug bevölkert , um wirklich etwas Bedeutendes zu sehen. Aber das ist für dich freigegeben. Die Kunden können die gesamte Beschreibung der Veröffentlichung durchgehen . Und Guitar Bass hat den Quellcode automatisch hochgeladen. Würde jemand herunterladen können , wenn er möchte. Also das war's auch schon. Wir sehen uns als Nächstes. 111. 1501 Ablehnen von verstorbenen pull für neue Commits: Okay, lassen Sie uns über diese Branch-Vorhersage-Regel sprechen , die besagt, Tail verwerfen, Genehmigungen für Pull Requests, neue Commits werden übertragen Was das bedeutet ist immer dann, wenn jemand einen Pull Request stellt und auch davon ausgeht, dass sogar die Überprüfung abgeschlossen ist, aber dieser Pull-Request, jetzt bevor diese Änderungen auf einem anderen Zweig zusammengeführt wurden, führte dazu ein Dollar pro Kilometer Team oder Änderungen in der Filiale, die wir zusammenführen wollen. Sollten wir nun zulassen, dass die Änderungen noch einmal überprüft werden, sind nicht seine Gemeinde. Diese Option bedeutet, wenn wir diese Option aktivieren, bedeutet dies, dass wir den Überprüfungsprozess erneut beauftragen möchten, indem wenn wir diese Option aktivieren, bedeutet dies, dass wir den Überprüfungsprozess erneut beauftragen möchten wir alle letzten Änderungen überprüfen, alle letzten Änderungen überprüfen bevor er mit einem anderen zusammengeführt werden kann Zweig. Deaktivieren Sie diese Option, und beachten Sie dann, dass Missbrauch erforderlich ist, um die Änderungen Wenn du verstanden hast , was ich gerade gesagt habe , ist das gut und gut. Du kannst das nächste Video überspringen. Ansonsten warte einfach. Ich werde das Gleiche demonstrieren. Im Moment ist das also deaktiviert. Lass mich zurück zum Depot gehen und schnell einen Pull-Request dafür stellen. Lassen Sie mich einen weiteren Zweig mit einem zufälligen Namen erstellen: df. Und lass uns auch einen Commit machen. Vielleicht durch Hinzufügen einer neuen Datei. Geben wir ihm einen Namen, etwas Ähnliches, und übernehmen wir die Änderungen. Lass uns eine Pull-Anfrage erheben. Wir werden den Hauptzweig mit dem Zweig vergleichen , den wir gerade erstellt haben. Pull Request erstellen. Pull Request erstellen. Das hat also die Pull Requests erstellt. Wir benötigen mindestens eine genehmigte Überprüfung bevor wir diese Änderungen zusammenführen. Jetzt kann dieselbe Person , die tatsächlich einen Pull-Request gestellt hat , seinen eigenen Code nicht überprüfen. Dafür. Ich habe Herrn Luke bereits als einen der Mitarbeiter dieses Projekts hinzugefügt. Lass es mich wissen, gehe zu Lukes Konto und akzeptiere die Änderungen schnell. Also hier ist die Pull-Anfrage von Luke's Account. Und ich werde meine Bewertung hinzufügen Ich werde diese Änderungen überprüfen und alles genehmigen. Wenn Sie nun zurückgehen, um diese Sekunden zu summieren, werden Sie sehen , dass die Änderungen genehmigt wurden und dass ich den Pull-Request zusammenführen kann . Aber in der Zwischenzeit, bevor ich die Änderungen zusammenführe, möchte ich versuchen, ein weiteres Commit in dem neuen Zweig vorzunehmen , den wir gerade erstellt haben. Ich gehe zurück zur Codebasis und zu diesem Zweig. Und lass mich eine weitere Datei mit einem anderen zufälligen Namen hinzufügen und die Änderungen übernehmen. Wenn wir zu den Pull-Requests zurückkehren, wirst du jetzt auch diese neuen Änderungen sehen. Im Moment können Sie sehen , dass keine zusätzlichen Bewertungen erforderlich sind, um die Pull-Requests zusammenzuführen. Das liegt daran, dass diese Option hier deaktiviert ist. Lassen Sie mich diese Option aktivieren. Speichern Sie die Änderungen. Lassen Sie mich schnell das Passwort eingeben. Und wenn ich jetzt noch eine Änderung vornehmen und mich für diesen Zweig engagieren sollte, lass mich das ganz schnell machen. So etwas. Bestätigen Sie die Änderungen. Wenn ich zu den Pull-Requests zurückkehre , wirst du dieses Mal sehen, dass wir noch einmal mindestens eine Überprüfung benötigen , bevor wir diese Änderungen zusammenführen können. Nun, da Sunday der Besitzer dieses Repositorys ist, kann diese Option tatsächlich zusammengeführt werden, ohne darauf zu warten , dass die Kommentare erfüllt werden oder ohne dass die Anzeige durchgeführt wird. Aber im Idealfall können die Revers diese Option nicht sehen. Aber ich hoffe, Sie haben den Sinn dieser Branch-Schutzregel verstanden. Wir sehen uns als Nächstes. 112. 1502 Code mit Mustern konfigurieren Automatische Überprüfungsanfrage: Lassen Sie uns über diese Branch-Schutzregel sprechen, die besagt, dass eine Überprüfung durch Codebesitzer erforderlich ist. Grundsätzlich erlaubt uns Github, eine spezielle Datei mit den Namenscode-Besitzern zu erstellen , wobei wir anhand von Dateimustern angeben können, wem was gehört . Es ist etwas ähnlich zu den Mustern, die wir eine Punkt-Gitignore-Datei angeben. Wir geben aber auch an, wem die Dateien gehören, die diesen Mustern entsprechen. Und wenn Sie diese Option aktivieren, werden wir automatisch zur Überprüfung aufgefordert. Immer wenn jemand einen Pull-Request auslöst , der den Code ändert, den er besitzt. Ich weiß, das klingt verwirrend. Und deshalb werde ich schnell den gleichen Phosphor demonstrieren. Gehen wir zu unserem Endlager. Und ich bin hier im Hauptzweig, ich werde eine neue Datei erstellen. Ich nenne die Datei als Code oder Krankenschwester. Es muss genau derselbe Name sein, alles Großbuchstaben. Und in dieser Datei werde ich einen der Besitzer mit einem Muster angeben . Zum Beispiel könnte ich sagen, star dot js und alle Dateien mit der Erweiterung dot js wären im Besitz von, sagen wir mal, wir haben es uns bereits als eine der Kooperationspartner angesehen, um dieses Projekt zu lösen. Wo auch immer Sie als Eigentümer hinzufügen möchten, müssen sie über Schreibberechtigungen für dieses Projekt verfügen. Lassen Sie mich also schnell die E-Mail-Adresse von Luke kopieren und hier einfügen. Sie können auch den Benutzernamen von Luke hinzufügen. So oder so, Luke wird jetzt der Besitzer all dieser Dateien sein . Lass mich zu dieser Akte kommen. Lassen Sie mich nun versuchen, Pull-Requests mit ab.js Datei 1 zu löschen. Zweitens, lass mich einfach schnell einen zufälligen Zweig erstellen. Und lassen Sie mich schnell eine neue Datei hinzufügen. Skripte punktieren uns. Konvertiert die Datei. Lass uns jetzt weitermachen und die Pull-Anfrage erheben. Und in dem Moment, in dem ich das mache, wirst du auf die Überprüfung des Code-Besitzers von Luke's unter Corp warten . Wenn du nun zu Lukes Konto gehst auf den Pull-Request klicke, ist dies Lukes Konto. Schau wird diese Nachricht sagen , dass er einen Pull Request überprüfen muss. Seit der Tatsache, dass Luke der Besitzer aller dot js-Dateien ist und jemand Pull Request auf demselben Branch gestellt hat, in dem Luke als Eigentümer dieser Dateien hinzugefügt wurde , hat get automatisch gefragt Luke, um die Änderungen oder den Pull Request zu überprüfen. Also schau, kann jetzt etwas mit dieser Bewertung anfangen. Nehmen wir an, er hat den Änderungen zugestimmt. Und jetzt können wir weitermachen und alle Änderungen zusammenführen. Diese Option ist bereits aktiviert. Ich hatte es bereits aktiviert und die Änderungen gespeichert. Und daher ist dies wirksam geworden. Wenn wir dies deaktivieren, hätte Luke die Überprüfungsanfrage nicht erhalten. Gehen wir zurück zum Projektarchiv. Im Allgemeinen behalten wir die Code-Besitzer-Datei im Basiszweig oder im Standardzweig. Da sich diese Datei derzeit im Hauptzweig befindet, ruft der Manager oder jemand eine Pull Request bittet darum, die Änderungen an diesem Branch zusammenzuführen. Zu diesem Zeitpunkt würde dieser Code auf einer Spirale wirksam werden. Sie sollten diese Datei also in einem Zweig behalten dem Entwickler ihren Code beitragen würden. Ende. Übrigens gibt es noch eine Reihe von Mustern, die wir dafür verwenden können, die Sie der offiziellen Dokumentation entnehmen können . Dort finden Sie auch Hinweise, die Ihnen einige der Beispielmuster zusammen mit einigen Beschreibung. Ich werde das als Notiz behalten, die Sie herunterladen können , und nehme mir Zeit , um das zu verstehen. Es ist eigentlich ziemlich einfach. Die Muster sind den Mustern, die wir in die Punkt-Gitignore-Datei aufnehmen, ziemlich ähnlich . Außer wir werden auch angeben, dass der Besitzer zwei Hörner von Dateien hat, die diesen Mustern entsprechen. Sie können auch Teams angeben. Das Team würde also bestimmte Dateien besitzen. Wie in diesem Fall. Wenn du One Out Debate Mitgliedschaften GitHub für deine Organisation abschließt, kannst du auch Einschätzungen hinzufügen. Hoffe es ergibt Sinn. Wir sehen uns als Nächstes. 113. 1503 Mandating vor dem Zusammenführen: Okay, lassen Sie uns über diese Verzweigungsvorhersageregel sprechen, die besagt, dass vor dem Zusammenführen eine Konversationsauflösung Übrigens werden wir es ignorieren, über diese Option zu sprechen , da dies etwas mit externen Tools zu tun hat. Und wenn Sie viele Arten von Überprüfungen durchführen möchten , bevor Sie den Code in einen anderen Zweig zusammenführen, sollten Sie dies aktivieren. Und darüber zu sprechen Dies liegt definitiv außerhalb des Rahmens dieses speziellen Kurses, da dies etwas mit externen Tools zu tun hat. Wenn Sie jedoch Prüfungen wie Schwachstellensuche durchführen möchten, sollten Sie im Allgemeinen Prüfungen wie Schwachstellensuche durchführen möchten, nach Programmfehlern im Code suchen . Wir führen eine kontinuierliche Integration durch oder stellen den Code auf einem Build-Server bereit, erhalten den Build-Status usw. Wenn du für viele solche Dinge arbeiten willst, wann immer jemand einen Pull-Request stellt, kannst du sie hier konfigurieren. Und das hängt tatsächlich vollständig von den Standards Ihrer Organisation ab und wir müssen uns entsprechend verhalten. Vielleicht behandeln wir das alles in anderen DevOps-Kursen, aber wir werden es vorerst ignorieren. Kommen wir zurück zu dieser Option, die besagt, dass vor dem Zusammenschluss eine Lösung zur Kriminalisierung erforderlich ist. Lassen Sie mich diese Option aktivieren. Zeigen Sie Ihnen , was es genau bedeutet. Also im Grunde genommen gehen die Männer ganz schnell ans Passwort. Diese Option ist also aktiviert. Lassen Sie mich zu den Pull-Anfragen gehen , die wir zuvor angesprochen hatten. Und wie Sie sehen können, können wir die Zusammenführung derzeit durchführen , da ihre Ansicht bereits abgeschlossen ist. Aber nehmen wir an, Mr. Luke hat einen Kommentar zum Code hinzuzufügen. Gehen wir also zu Lukes Konto. Lass mich die Datei aus diesem Pull-Request öffnen. Und nehmen wir an, wir haben hier eine Menge Codezeilen. Und Luke gibt einen Kommentar ab. Also vielleicht so etwas wie so etwas. Lassen Sie mich es ein wenig vergrößern. Also möchte ich diesen Befehl hinzufügen und wir werden auf eine dieser Schaltflächen klicken. Lassen Sie mich nur einen einzigen Kommentar hinzufügen. Und da wir diese Option für die Branch-Schutzregel aktiviert hatten , lassen Sie mich die Seite neu laden, wenn ich jetzt zur Pull-Anfrage vom Absenderkonto zurückkehre wenn ich jetzt zur Pull-Anfrage vom Absenderkonto . Sie werden sehen, dass die Zusammenführung erneut blockiert ist , da es ungelöste Konversationen gibt. Nehmen wir an, der Absender hat diesen Kommentar angesprochen und er wird dieselbe Antwort noch einmal erwähnen, um nachzusehen. Ja, das habe ich überprüft. So etwas. Das ist noch einmal, geh zurück zu Lukes Konto. Er hat die Antwort hier gesehen. Und sobald Sie mit der Antwort zufrieden sind, wird Luke das Gespräch lösen. Ist es. Dann kann der Absender die Pull-Anfrage tatsächlich zusammenführen. Wenn diese Option nicht aktiviert ist, ist zum Zusammenführen des Codes keine Konversationsauflösung erforderlich. Wir sehen uns als Nächstes. 114. 1504 Erkundung aller anderen Regeln für den Schutz vor Veräumen: Lassen Sie uns hier über alle verbleibenden Regeln zum Schutz von Zweigstellen sprechen. Diese sind ziemlich einfach zu verstehen und schon unkompliziert. Und so können wir all das alleine in dieses Video einbauen. Wenn Sie diese Verzweigungsvorhersageregel beenden , sind signierte Kämpfe erforderlich. Dies erfordert tatsächlich, dass Sie verstehen, was Commits zugewiesen sind, wie wir private und öffentliche Schlüssel zum Signieren, Verschlüsseln, Entschlüsseln usw. generieren können . Das verlässt sich also auf ein eigenes Kapitel. Wir werden also im nächsten Kapitel darüber sprechen. Aber lassen Sie uns dieses Kapitel über die Regel zur Vorhersage von Zweigen abschließen nachdem wir kurz auf alle anderen Optionen eingegangen sind, die wir hier haben. Wir haben also diese Option, die die erforderliche lineare Historie angibt. Und wie der Name schon sagt, erlaubt es uns keine Merge-Commits. Wenn Sie einen Merge-Commit haben, hätten wir keinen linearen Commit-Verlauf mehr. Nehmen wir an, ich habe diese Option aktiviert. Lass es mich ganz schnell speichern. Wenn du zu den Pull-Requests zurückkehrst, lass mich hier klicken. Dies sind die Pull-Anfragen, die wir zuvor angesprochen hatten. Wenn ich nun diese Option auswähle, um einen Merge-Commit zu erstellen, wird diese Meldung angezeigt, dass der Merge-Zweig einen linearen Verlauf benötigt. Das liegt daran, dass wir diese Option aktiviert hatten. Aber wir können diese Option immer noch sehen, um Pull Request zusammenzuführen. Das liegt daran, dass ich das tatsächlich unter der Sekunde mache, wer ist der Besitzer des Repositorys? Lassen Sie mich diese Verzweigungsvorhersageregel bearbeiten. Wir haben noch eine andere Möglichkeit, dies nicht zuzulassen. Also hier ist es. Wenn wir diese Option aktivieren, die besagt, dass Umgehen nicht erlaubt ist, sind beide Einstellungen. Und die Beschreibung besagt, dass die Elbow-Einstellungen für Administratoren und benutzerdefinierte Rollen mit der Berechtigung zum Schutz von Zweigstellen umgehen gelten Administratoren und benutzerdefinierte Rollen mit . Das bedeutet, dass bisher alle Branch-Produktionsregeln nicht alle Branch-Produktionsregeln wirklich für Admins angewendet werden, nicht wirklich für Admins oder die Eigentümer des Repositorys durchgesetzt werden. diese Option aktivieren, sind Admins Eigentümer des Repositorys und können die Regeln für die Branch-Produktion nicht wirklich umgehen. Lassen Sie mich diese Option aktivieren und die Änderungen speichern. Wenn ich nun zu Pull Request zurückkehre, könnte Sender als Administrator des Repositorys diese Option nicht mehr wählen. Das wurde ausgegraut. Ich kann es auch nicht anklicken. Wenn Sie die Organisationslizenz von GitHub erwerben, sollten Sie in der Lage sein, ein Team von Einzelpersonen zu erstellen. Einige von ihnen sind Edmond, einige von ihnen sind Betreuer. Sie könnten unterschiedliche Rollen haben. Und indem Sie diese Option aktivieren, sind die für Administratoren festgelegten Regeln zur Durchsetzung der Branch-Vorhersage von Jahren die Wartung des Repositorys. Zwischen diesen beiden Optionen haben wir diese Option, die angibt, dass Bereitstellungen vor dem Zusammenführen erfolgreich sein müssen . Nun, Sie können diese Regel verwenden, um sicherzustellen, dass Änderungen erfolgreich bereitgestellt werden ohne dass Probleme bei diesem Staging oder den Tests und Römern auftreten, bevor die Änderungen mit dem Standardzweig zusammengeführt werden können . Dies hängt nun von Ihrer Organisation , welche Tools Sie verwenden. Derzeit haben wir keine Bereitstellung und kein Roman-Setup. wir also wirklich nicht nachweisen. Vielleicht ist das Thema eines anderen Kurses. Also überspringen wir das. Und wir haben noch ein paar Optionen für die Vorhersage von Zweigstellen. Und diese Optionen gelten für alle , auch für Administratoren. Hallo, Kraftstöße würden bedeuten , dass wir die Kraftstöße auf die geschützten Zweige laden wollen . Und wir können sogar wählen , wer das tun kann. Ob wir es jedem mit Push Axis ermöglichen wollen, wie zum Beispiel Mitarbeiter? Oder wollen wir gezielt auswählen, wen wir mit geringer Kraft drücken wollen? Zum Beispiel wurde Luke bereits als einer der Mitarbeiter hinzugefügt . Ich kann ihn zum Beispiel wählen , wenn ich möchte. Und schließlich haben wir eine Ladungslöschung. Indem wir diese Option aktivieren, ermöglichen wir es Benutzern mit Bush Axis, die Zweige zu löschen, die mit diesem Muster übereinstimmen. In diesem Fall sagen wir, dass all diese Regeln zur Vorhersage von Zweigstellen für die Hauptniederlassung gelten. Indem wir diese Option aktivieren, ermöglichen wir es Personen mit Push-Zugriff, diesen bestimmten Zweig in diesem Fall zu löschen. Das ist also alles über die Regeln für den Schutz von Filialen. Wir werden diese Option noch einmal explodieren lassen. Im nächsten Kapitel. Wir sehen uns als Nächstes. 115. 1601 Mimicing der Commits und die Notwendigkeit, seine Commits festzulegen: Lassen Sie mich nun etwas wirklich Interessantes demonstrieren. Ich bin sicher, du wärst überrascht , wenn das passiert. Für dieses Beispiel werde ich eines der vorhandenen Repositorys verwenden , die wir in diesem Kurs verwendet haben. Falls Sie nicht wissen, worum es in diesem Repository geht. Stellen Sie sich das einfach als ein zufälliges Repository mit einer Reihe von Dateien vor. Derzeit hat dieses Projekt diese beiden Mitarbeiter. Wir haben einen Absender, der der Eigentümer des Repositorys ist, und Luke, der einer der Mitarbeiter dieses Projekts ist. Auch für dieses Beispiel habe ich die Regeln für die Produktion von Zweigstellen für die Hauptniederlassung deaktiviert . Daher sehen Sie diese Meldung, die besagt, dass Ihre Hauptniederlassung nicht geschützt ist. Jetzt eine Frage an dich. Ist es möglich, dass Herr Luke im Namen von Cylinder eine Bemerkung abgibt, ohne seine Zustimmung einzuholen? Nun, lass uns einen Blick darauf werfen. Stellen Sie sich vor, das ist Mr. Lukes Computer. Und um Ihre Zeit zu sparen, habe ich das Projekt bereits geklont. Lass mich Git Bash hier öffnen. Lassen Sie mich den Befehl git config ausführen damit ich nicht einen Blick auf die aktuellen Konfigurationen werfen kann. Und wie Sie sehen können, sind Benutzername und E-Mail-Adresse deaktiviert. Mr. Lukes Benutzername ist Lukes in der Corp und die E-Mail-Adresse lautet wie eine E-Mail-Adresse. Lass mich versuchen, sie in Saunders zu ändern. Ich werde den globalen Benutzernamen git config sagen. Ich werde die gleiche Dosis GitHub-Benutzernamen geben, so. In ähnlicher Weise werden wir auch die E-Mail-Adresse ändern und sie mit einigen dieser E-Mail-Adressen aktualisieren. Ich kann das leicht in diesem Namen und dieser E-Mail-Adresse bekommen. Aber weiter im Befehl git log. Und schauen Sie sich einige der Kommentare von Mr. Cylinder an. Wenn ich nun eine Git-Konfigurationsliste mache, wirst du sehen, dass der Benutzername und die E-Mail-Adresse oder nein, aktualisiert mit Zylindern, ein Name und seine E-Mail-Adresse sind. Lassen Sie mich nun versuchen, ein Commit einzugehen und zu sehen, was passieren wird. Lassen Sie mich schnell eine Datei mit einem zufälligen Namen erstellen. Und ich werde sehr schnell als diese Datei bleiben, git füge den Namen der Datei hinzu. Und schließlich habe ich mich mit einer Nachricht verpflichtet. Nennen wir es falsches Commit. Und ich werde diese Änderungen auch in das GitHub-Repository übertragen . Gehen wir nun zu GitHub und schauen uns an, wie sich die Dinge dort widergespiegelt haben. Ich bin derzeit in der Hauptniederlassung. Lass mich die Seite neu laden und zum Commit gehen. Und wie Sie sehen können, können wir das Commit sehen , das gerade von Mr. Luke gemacht wurde. Aber wenn Sie bemerken, was hier gezeigt wird, heißt es, dass diese Verpflichtung von Herrn Sunda eingegangen wurde und auf das Profil von Asche verweist. Interessanterweise einige, die keine Ahnung haben , dass dieser Kommentar abgegeben wurde. Für jemanden, der sich die Commit-Historie ansieht. Sie werden denken, dass dieser Ausschuss tatsächlich den ganzen Tag von Sunder gebildet wird , nicht derjenige, der diese Bemerkung tatsächlich abgegeben hat. Dies geschieht, weil Good davon ausgeht, dass sie sie verwenden? Eine E-Mail-Adresse , die in Konfigurationen festgelegt wurde , ist dieselbe Person , die den Commit tatsächlich durchführt. Dies ist jedoch möglicherweise nicht der Fall. Und ich habe es dir gerade demonstriert. Dies muss nicht unbedingt von bestehenden Mitarbeitern des Projekts durchgeführt werden . Eine zufällige Person für das Projekt und erhebt die Pull-Anfrage mit einer Reihe von Commits, die nachahmen , dass diese Kommentare tatsächlich von einem anderen Benutzer gemacht wurden , was offensichtlich nicht der Fall ist etwas, das wir erwarten würden. Wir brauchen also eine Art Überprüfungsprozess der überprüft, ob der Commit-Autor dieselbe Person ist, die den Ausschuss tatsächlich gebildet hat. Und hier kommen verifizierte Commits ins Spiel. Und darüber werden wir als Nächstes sprechen. 116. 1602 Digitale Signaturen verstehen: Bevor wir verstehen, was unser Zeichen begeht, versuchen wir zu verstehen, was genau eine verzerrte Natur ist. Nicht im Kontext von Git und GitHub. Aber im Allgemeinen. Nehmen wir an, wir haben Bob und Alice. Und Bob will Alice eine Akte schicken. Wenn er die Datei so wie sie ist an Alice sendet, kann es passieren, dass sich jemand in das Netzwerk einmischt und die Datei manipuliert, bevor sie Alice erreicht. Und Alice hat keine Möglichkeit zu überprüfen, ob die Datei manipuliert wurde oder ob Bob tatsächlich der Absender ist. Wenn man das im Hinterkopf behält, wird Bob etwas dagegen unternehmen. Was tun wird, ist, dass er eine Art Tool verwenden wird , um einen sogenannten öffentlichen Schlüssel zu erstellen. Und ein privater Schlüssel. private Schlüssel sollte, wie der Name schon sagt, nicht mit anderen geteilt werden. Es wird bei Bob sein. Und es wird es sicher irgendwo in seinem lokalen Dateisystem aufbewahren . Auf der anderen Seite kann der öffentliche Schlüssel mit anderen geteilt werden. Jeder, der Bobs Nachricht oder Datei erhalten möchte , kann tatsächlich eine Kopie des öffentlichen Schlüssels haben. In diesem Fall wird Bob den öffentlichen Schlüssel mit Alice teilen. Alice gibt, würde sich in nur einer Weile als nützlich erweisen. Dieses Mal, bevor Bob die Datei an Alice sendet, wird er seinen privaten Schlüssel verwenden um das Dokument digital zu signieren. Aber wie groß ist die Entfernung dieser Natur? Nun, die digitale Signatur ist im Wesentlichen ein Hash der verschlüsselten Daten , aber der private Schlüssel des Unterzeichners. Wir haben bereits in einer der vorangegangenen Vorlesungen über Hash gesprochen . Zusammenfassend lässt sich sagen, Hashwert ein numerischer Wert mit einer festen Länge ist , der Daten eindeutig identifiziert. Oder in diesem Fall diese Datei. Wenn Sie dieselben Daten oder die Datei als Eingabe in die Hash-Funktion ausführen, würde sie genau denselben eindeutigen Hashwert unabhängig davon, wie oft Sie dies tun. Aber wenn Sie die Daten oder den Inhalt der Datei auch nur ein wenig ändern , würde die Hash-Funktion einen völlig anderen Hashwert zurückgeben . Im Wesentlichen identifiziert der Hash-Wert also eindeutig ein bestimmtes Datum oder eine Datei. Wenn ich Datendatei oder Nachricht sage, bedeuten sie alle dasselbe. Also schickte Bob die Datei dann über das Netzwerk an Alice. Jetzt muss Alice überprüfen, ob die Nachricht manipuliert wurde , um den Absender tatsächlich bombardiert zu haben. Ich wünschte, du würdest das tun. Nun, sie wird Bobs öffentlichen Schlüssel verwenden, um die digitale Signatur zu entschlüsseln und den Hashwert daraus zu extrahieren. Nun, wenn ich sage, dass sie das tun wird, ist es nicht gerade sie , die das tun wird. Sie wird ein Tool benutzen , das das macht. Sie würde dann ein Tool verwenden , um auch den Hashwert der gesendeten Datei herauszufinden. Diese beiden Hash-Werte sind genau gleich, dann können wir sicher sein, dass die Daten nicht manipuliert wurden. Und wenn sie die digitale Signatur nicht entschlüsseln kann, bedeutet das, dass jemand anderes die Datei mit seinem privaten Schlüssel und nicht mit Bobs privatem Schlüssel gesendet hat . Wenn die digitale Signatur mit einem privaten Schlüssel einer anderen Person signiert ist , wäre Alice nicht in der Lage, die diskursive Natur mit Bobs öffentlichem Schlüssel zu entschlüsseln . So kann sie sicher sein , dass die Akte nicht manipuliert wurde und dass die Datei tatsächlich von Bob stammt. Wenn Sie das verstanden haben, es keine große Sache sein, die verifizierte Signatur zu verstehen sollte es keine große Sache sein, die verifizierte Signatur zu verstehen. Als Nächstes werden wir über verifizierte Signaturen sprechen. 117. 1603 Verständnis von unterzeichneten Commits: Lassen Sie uns nun über verifizierte Commits sprechen. Das Konzept der verifizierten Kommentare unterscheidet sich nicht von dem Konzept der digitalen Signaturen, über das wir zuvor gesprochen haben, außer anstelle von Bob Dylan, um Stelle von Alice getreten zu sein. Wir werden GitHub haben. Und anstelle dieser Datei werden wir das Komma haben. Nehmen wir an, Luke möchte distal einen Commit zuweisen und ihn an das GitHub-Repository übertragen. Auf GitHub wollen wir überprüfen, ob dieser Commit tatsächlich von Mr. Loop stammt. Also wird Luke zunächst öffentliche und private Schlüssel generieren seinen öffentlichen Schlüssel auf sein GitHub-Konto hochladen. Und er wird den privaten Schlüssel verwenden, um die Kommentare zu signieren. Wieder einmal ist es nicht gerade Luke, der das alles tun würde. Es würde alles von get erledigt werden, indem Sie einfach einen einfachen Befehl ausführen. Wenn es diesen Befehl ausführt, wird git im Wesentlichen distal das Commit zuweisen. Und einmal danach schiebt Loop den Commit an GitHub auf der GitHub-Site. Github wird anhand seines öffentlichen Schlüssels überprüfen, ob es von Luke stammt . Lassen Sie uns einen Blick auf die einzelnen Schritte werfen in diesem gesamten Prozess involviert sind. Zunächst lokaler, geschlechtsspezifischer, öffentlicher und privater Schlüssel mit einem Tool würde es dann den öffentlichen Schlüssel auf sein GitHub-Konto hochladen , damit GitHub ihn zur Überprüfung der Commits verwenden kann. Local distal weist den Commit mit seinem privaten Schlüssel zu. Durch einfaches Ausführen eines Befehls. Luke wird die Änderungen dann auf GitHub übertragen. Github überprüft den Commit mit Lukes öffentlichem Schlüssel. Wenn GitHub die Comanches nicht entschlüsseln kann und als öffentlicher Schlüssel aussieht. Das bedeutet, dass der Komiker von Mr. Luke stammt. Jemand anderes könnte gemacht haben , dass Commit nicht ihr privater Schlüssel ist. Wir werden als Nächstes all diese Untätigkeit erleben. 118. 1604 Erstellung öffentlicher und privater Schlüssel mit GPG: Okay, lass uns sehen, wie wir öffentliche und private Schlüssel erstellen können . Nehmen wir nun an, dass dies Mr. Lukes Computer ist, und er plant nun, öffentliche und private Schlüssel für sich selbst zu erstellen , damit sie zu einem späteren Zeitpunkt zur Überprüfung verwendet werden können . Um diese Schlüssel zu erstellen, werden wir ein Tool namens GPG verwenden, für GNU Privacy Guard steht. Und es ist etwas , das Sie nicht separat installieren müssen. Wenn Sie Git bereits auf Ihrem Computer installiert haben und es bereits im Paket mit dem GPG-Tool finden. Und Sie müssen es nicht separat installieren. Falls Sie Git Bash nicht verwenden, Sie bei einer schnellen Google-Suche in der Lage sein, sollten Sie bei einer schnellen Google-Suche in der Lage sein, Anweisungen zur Installation von GPG für Ihr Betriebssystem zu finden . In diesem Fall werden wir jedoch Git Bash für dasselbe verwenden. außerdem sicher , dass Sie diese Befehle nicht im Repository-Ordner ausführen . Zu diesem Zweck habe ich tatsächlich einen neuen Ordner auf meinem Desktop erstellt und hier werde ich die Befehle ausführen. Lassen Sie uns zunächst sicherstellen, dass GPG tatsächlich installiert ist , indem Sie den Befehl GPG dash dash version ausführen. Und das sollte eine Ausgabe wie diese zeigen. Lassen Sie uns nun den Befehl ausführen, um die öffentlichen und privaten Schlüssel für Mr. Luke zu erstellen . Der Befehl dafür ist GPG, Strich, Strich , Strich, Schlüssel generieren. Dies wird uns einige Fragen stellen. Mal sehen, was wir ihnen beantworten können. Hier müssen wir den Algorithmus auswählen, den wir zum Generieren der Schlüssel verwenden möchten . Gpt unterstützt all diese Algorithmen, die hier aufgelistet sind. Der Standard ist der RSA-Algorithmus, und es ist der Algorithmus , den ich empfehle. Also drücke ich einfach die Eingabetaste, um die Standardoption auszuwählen , in diesem Fall der RSA-Algorithmus. Als nächstes wurden wir aufgefordert, die Schlüsselgröße einzugeben. Die maximale Schlüsselgröße, die wir eingeben können, beträgt 4.096 Bit. Und das ist die Mindestanforderung für GitHub. Also sagen wir 4.096. Drücken Sie die Eingabetaste. Hier werden wir gefragt, wie lange der Fall gültig sein soll. Ich möchte, dass es für immer gültig ist. Ich werde die Standardoption belassen, die 0 ist. Also würde ich niemals ablaufen. Und wir sollten in der Lage sein, diese Schlüssel für immer zu verwenden , bis wir sie löschen oder etwas mit ihnen machen. wir die Eingabetaste, um die Standardoption zu verwenden. Jetzt werden wir aufgefordert , uns anzupassen, ob wir wirklich beabsichtigen, den Schlüssel überhaupt nicht abgelaufen Ich würde y eingeben, einfach ja sagen, Enter drücken. Jetzt werden wir aufgefordert , die Benutzer-ID einzugeben. Hier. Ich werde den Benutzernamen von Mr. Lukes GitHub-Konto angeben. Ich habe es schon griffbereit. Ich werde es einfach kopieren und hier einfügen. Und natürlich müssen Sie in Ihrem Fall Ihren GitHub-Benutzernamen eingeben. In der nächsten Aufforderung gebe ich Lukes E-Mail-Adresse an. In Ihrem Fall möchten Sie Ihre E-Mail-Adresse angeben , mit der Sie sich für GitHub registriert haben. Was sind also im Wesentlichen der Name und die E-Mail-Adresse, die Sie für Ihre Commits verwenden möchten? Es sollte sie hier drüben versorgen. Wir können optional auch einen Kommentar abgeben, aber ich möchte nichts dazu geben. Also drücke ich einfach Enter. Jetzt werden wir aufgefordert, die gerade eingegebene Benutzer-ID zu überprüfen . Überprüfen Sie also noch einmal und stellen Sie sicher, dass es korrekt ist. Sobald dein Shirt ausgezogen ist, gib einfach das Zeichen o ein, um L K zu sagen . Es werden Schlüssel generiert. Jetzt werden Sie möglicherweise aufgefordert , die Passphrase einzugeben. Dies ist nur eine zusätzliche Sicherheit zum Schutz Ihres privaten Schlüssels. Wenn jemand Ihren privaten Schlüssel stiehlt, sollte er in der Lage sein, diese Passphrase zu kennen , um Ihren privaten Schlüssel verwenden zu können. Dies ist nur eine zusätzliche Sicherheitsmaßnahme. Sie können einfach OK drücken, ohne etwas einzugeben. Auf diese Weise haben Sie keine Passphrase. Es wird jedoch offensichtlich empfohlen , dass Sie eine Passphrase angeben. In meinem Fall gebe ich einfach nur nach Kaktus ein, was nicht so sicher ist. Wenn Sie es sicherer machen möchten, geben Sie eine sehr starke Passphrase mit einer Kombination aus Zeichen, Zahlen, Symbolen usw. Und ich schätze, es werden nur vier Zeichen sein . Ist es okay? Sie erhalten eine weitere Warnung , dass das Passwort nicht sehr sicher ist, da es sehr leicht zu erraten ist. Aber den würde ich trotzdem gerne benutzen . Also wähle ich diese Option, die besagt, nimm diese trotzdem. Es fordert mich auf, die Passphrase erneut einzugeben. Ich werde genau das tun und auf „Okay“ klicken. Während der Schlüsselgenerierung wird empfohlen, dass Sie einige Aktivitäten auf Ihrem Computer ausführen , z. B. das Bewegen der Maus, das Eingeben von etwas auf der Tastatur usw. Und genau das wird hier empfohlen. Es heißt, wir müssen viele zufällige Bytes generieren. Es ist eine gute Idee, einige andere Aktionen wie Tippen auf der Tastatur, Bewegen der Maus, Verwenden dieser Funktion usw. auszuführen einige andere Aktionen wie Tippen auf der Tastatur, , damit die generierte Taste zufälliger ist. wurden also beide Schlüssel generiert. Sie können überprüfen, ob sie generiert wurden, indem Sie den GPG-Befehl mit der Option list case ausführen . Also werde ich GPG-Dash, Dash, List, Dashkeys sagen . Das hat also den öffentlichen Schlüssel angezeigt. Und wenn Sie List Dash, Secret Case sagen , werden hier die Details zum privaten Schlüssel angezeigt. Dies ist nicht der tatsächliche Fall. Dies sind nur die Details zu den Schlüsseln. Dies wird sich in Kürze als nützlich erweisen. Wir sehen uns als Nächstes. 119. 1605 Öffentlichen Schlüssel exportieren und GPG-Schlüssel auf GitHub aktualisieren: Okay, nachdem wir nun öffentliche und private Schlüssel erstellt haben, versuchen wir nun, den öffentlichen Schlüssel zu exportieren , damit wir ihn auf Lukes GitHub-Konto legen können. Und der Befehl dafür ist, dass du GPG setzen wirst. Silbentrennung steht für Rüstung. Diese Option dient dazu, den Schlüssel im ASCII- oder Modusformat statt im Binärformat zu exportieren . Und dann sagen wir dash, dash, exportiere es, um den Schlüssel zu exportieren. Und dann geben wir die Schlüssel-ID an. Was ist nun die Schlüssel-ID aus unseren vorherigen Befehlen? Wenn Sie feststellen, wo wir die Erstellung des öffentlichen Schlüssels und des privaten Schlüssels überprüft haben , wurde auch die Schlüssel-ID gedruckt. Und wenn Sie feststellen, ist die Grundidee von öffentlichen und privaten Schlüsseln genau dieselbe. liegt daran, dass der private Schlüssel keine separaten Schlüsselideen hat, wie z. Und so zeigt GPG nur die öffentliche Schlüssel-ID an, an die der private Schlüssel bezahlt wird. Ich kopiere einfach diese Kennung. Alternativ können Sie auch UID verwenden, die für User ID steht, und wir können diese auch verwenden. Es wird jedoch generell empfohlen , die Schlüssel-ID anstelle der UID zu verwenden. Um es kurz zu machen, es kann zu Konflikten führen, wenn Sie einen KeyStore haben. Verwenden wir das also, um den öffentlichen Schlüssel zu exportieren. Wir können den Text aus dem öffentlichen Schlüsselblock von begin PGP kopieren. Bis zu diesem Punkt, an dem wir den Text und den öffentlichen PGP-Schlüsselblock sehen . Ich kopiere es einfach. Alternativ können Sie denselben Befehl ausführen. Und mit einer eckigen Klammer können wir tatsächlich den öffentlichen Schlüssel in ihre Datei exportieren. Öffentliche Punkttaste, zum Beispiel, wo die Öffentlichkeit exportiert werden soll. Wenn Sie möchten, können Sie den privaten Schlüssel auch exportieren. Im Moment. Das müssen wir nicht tun. Aber ich zeige nur, wie wir das machen können. Anstatt also nur Exportieren zu sagen, sagen wir Export Dash Secret Key. Und das würde auch private Schlüssel exportieren. Und wenn Sie das tun, werden Sie aufgefordert , die Passphrase einzugeben. In meinem Fall ist es nur für Charakter-Passphrase. Was ist die Passphrase, die Sie erstellt haben? Das wollte ich hier. Sobald ich auf Okay klicke, haben wir den privaten Schlüssel in diese Datei gespeichert. Mal sehen, ob wir dort hingehen können. Wenn ich dieses Verzeichnis öffne, werden diese beiden Dateien erstellt. Öffnen wir die öffentliche Punktschlüsseldatei mit Notepad Plus, Plus. Und du wirst den gleichen Text sehen , der auf Git Bash gesehen wurde. Ich werde das einfach kopieren. Und ich gehe jetzt zu Lukes GitHub-Konto. Das sieht aus wie ein GitHub-Konto. Ich werde auf dieses Symbol klicken. Und wenn Sie ein wenig nach unten scrollen, werden Einstellungen angezeigt. Klicke darauf. Klicken Sie im Menü auf der linken Seite auf, klicken Sie auf SSH- und GPG-Tasten. Und hier siehst du Option. Um einen neuen GPG-Schlüssel zu geben. Unter dem Schlüsselabschnitt fügen Sie Mörtel ein, haben gerade den öffentlichen Schlüssel kopiert, den optionalen Ignacio-Titel, und klicken Sie auf GPG-Schlüssel hinzufügen. Als Nächstes werden wir sehen, wie wir die Commits unterzeichnen können . Wir sehen uns als Nächstes. 120. 1606 Erstellen von Signed Commit Einstellung der globalen Config, die signierte Kommandos auf GitHub verifiziert.: Okay, lass uns sehen, wie wir zugewiesene Commits erstellen und sie auf GitHub verifizieren lassen können . Ich habe hier bereits die öffentliche CAP geklont. Lassen Sie mich sie öffnen und das Stammverzeichnis des Projekts aufrufen. Lassen Sie mich zuerst den Befehl git config list ausführen. Und wie Sie sehen können, verwenden sie den Namen und E-Mail-Adresse werden auf die von Asche aktualisiert, was nicht ideal ist. Mal sehen, was passieren wird, wenn wir uns zum Commit verpflichtet haben. Lassen Sie mich also eine zufällige Datei erstellen, so etwas. Lass es mich inszenieren. Und übrigens, ich mache das nicht in der Hauptniederlassung. Ich habe gerade einen zufälligen Zweig ausgewählt. In diesem Fall lautet der Zweigname QQQ , der in einer unserer vorherigen Vorlesungen zufällig erstellt wird . Lassen Sie mich nicht versuchen, Commit zugewiesen zu machen. Der Befehl dafür ist git commit. Bindestrich in Großbuchstaben, ja. Stellen Sie sicher, dass dies in Großbuchstaben geschrieben ist. Ja. Ansonsten geht dieser eine zu Fuß. Wenn Sie das Tag jedoch signieren möchten, muss es in Kleinbuchstaben geschrieben sein. Ja. Also Bindestrich in Großbuchstaben ja. Und Bindestrich md, um diesem Commit eine Nachricht zu geben. Nennen wir es mein Commit oder was auch immer. Commit ist also fehlgeschlagen. Und die Nachricht besagt, dass es keinen geheimen Schlüssel gibt. Für Mr. Sunda. Die Benutzer-ID des Schlüssels, den wir erstellt haben , gehört zu der von Luke. Aber die guten Konflikte haben oft die Anmeldeinformationen. Beide stimmten nicht mit Enter überein. diesem Fall können wir kein Zeichen setzen, um uns zu verpflichten. Lassen Sie uns also schnell die Konfigurationen ändern. Der Benutzername wird GitHub sein, der Benutzername von Luke. In ähnlicher Weise werden wir die Melodramen so aktualisieren, dass sie so aussehen. Versuchen wir nun, einen zugewiesenen Commit zu erstellen. Zum ersten Mal machst du es. Sie werden aufgefordert, die Passphrase einzugeben. Ich gebe genau das ein. Treffer. Okay? Und unser Engagement für Erfolg. Versuchen wir nun, diese Änderungen auf GitHub zu übertragen. So können wir diesen Commit, der auf GitHub gegangen ist, pushen und sehen, was sich dort widerspiegelt. Ich befinde mich derzeit in meinem öffentlichen App-Repository und ich bin in dieser Filiale, QQQ. Lass mich die Seite neu laden. Und wie Sie sehen können, können wir den Kommentar sehen , der gerade gemacht wurde. Und diesmal ist es mit verifiziertem Badge. So ist Github in der Lage, den öffentlichen Schlüssel von Mr. Luke, dem Autor von The Commit, abzurufen , um zu überprüfen, ob der Ausschuss tatsächlich von Mr. Luke durchgeführt wird. So läuft der Überprüfungsprozess ab. Wenn ich den öffentlichen Schlüssel von Mr. Luke entfernen würde, wäre der verifizierte Badge nicht mehr da. Sie könnten sagen, dass die Überprüfung nicht erfolgreich ist. Übrigens, wenn Sie nicht jedes Mal , wenn Sie einen Commit unterzeichnen möchten , die Option Bindestrich S verwenden möchten, können wir dafür tatsächlich einen guten Konflikt einführen. Sie werden also das JPG-Zeichen Git Config Global Climate Dot sagen . Und wir werden das wahr machen. Jedes Mal, wenn Sie sign commit festlegen möchten, müssen Sie die Option für Bindestrich S nicht explizit angeben. Wenn Sie dieses Flag setzen. Wenn Sie über mehrere private Schlüssel verfügen, , müssen Sie diese außerdem zur Vermeidung von Mehrdeutigkeiten darüber informieren welche privaten K12 zum Signieren der Commits verwendet werden. Der Konflikt dafür ist der Benutzersignierschlüssel. Und du wirst die eindeutige ID des Schlüssels angeben , GPG. Schlüssel. Sie können diese ID angeben. So. Nehmen wir an, es gibt eine Person mit negativer Absicht. Er hat einen privaten Schlüssel mit Lukes Anmeldeinformationen erstellt und davon aus, dass er den Commit sogar in das Repository auf der GitHub-Site übertragen hat . Github kann diesen Commit nicht mit dem öffentlichen Schlüssel in Lukes Konto überprüfen . Und auf diese Weise könnte Aufstehen überprüfen, ob der Ausschuss nicht wirklich von Mr. Luke kommt. Hoffe es ergibt Sinn. Wir sehen uns als Nächstes. 121. 1607 Manding Signed Commits Signing Commits aus VS-Code: Okay, lass uns nicht über diese Regel zur Vorhersage von Zweigen sprechen , die wir zuvor ausgelassen hatten. Es heißt, signierte Commits sind erforderlich. Das solltest du inzwischen verstehen können. Wenn Sie diese Option aktivieren, bedeutet das, dass wir nur Zeichenkometen in den passenden Zweigen zulassen wollen . So einfach das sagt, dieses Video wird sehr gedreht. Lassen Sie mich noch eine weitere Sache hinzufügen. Lassen Sie uns einen Blick darauf werfen, wie wir Commits aus Visual Studio Code signieren können . Lassen Sie mich dazu dieses Projekt mit Visual Studio Code öffnen . Die Einstellung dafür ist also , dass Sie zum Menü Datei, Einstellungen, Einstellungen gehen Menü Datei, Einstellungen, Einstellungen und nach suchen müssen. Lass es mich nochmal machen. Einstellungen und Suche nach GPG. Sie müssen diese Option aktivieren, die „ Commit-Signierung aktivieren “ besagt. Schließt die Einstellungen. Lassen Sie uns schnell eine der Dateien bearbeiten , damit wir etwas übernehmen können. Ich habe einen zufälligen Text eingegeben, speichere die Datei. Und lassen Sie mich die Änderungen übernehmen. Unterschreibe vom VS-Code, so etwas. Und lass mich das Commit machen. Möglicherweise werden Sie aufgefordert, die Passphrase einzugeben. Bitte geben Sie es ein und klicken Sie. Okay. Da ich das schon einmal gemacht habe, habe ich diese Aufforderung nicht noch einmal bekommen. Aber wenn du jetzt zu GitHub gehst und die Seite neu lädst, müssen wir diese Änderungen natürlich pushen, um sie auf GitHub sehen zu können. Also lass uns das schnell machen. Laden wir die Seite neu. Und wie Sie sehen können, können wir diesen Commit sehen und er ist auch verifiziert. Hoffe es ergibt Sinn. Wir sehen uns als Nächstes.