Erste Schritte mit Git: eine umfassende Anleitung für Neulinge

Statt einer Einleitung

Hallo! Heute sprechen wir über ein Versionskontrollsystem, nämlich Git. Mit Programmieren hast du nichts zu tun, wenn du Git nicht kennst/verstehst. Aber das Schöne ist, dass Sie nicht alle Git-Befehle und -Funktionen im Kopf behalten müssen, um kontinuierlich eingesetzt zu werden. Sie müssen eine Reihe von Befehlen kennen, die Ihnen helfen, alles zu verstehen, was passiert.

Git-Grundlagen

Git ist ein verteiltes Versionskontrollsystem für unseren Code. Warum brauchen wir es? Verteilte Teams benötigen ein System zur Verwaltung ihrer Arbeit. Es ist erforderlich, Änderungen zu verfolgen, die im Laufe der Zeit auftreten. Das heißt, wir müssen Schritt für Schritt sehen können, welche Dateien sich wie geändert haben. Dies ist besonders wichtig, wenn Sie untersuchen, was sich im Kontext einer einzelnen Aufgabe geändert hat, damit die Änderungen rückgängig gemacht werden können.

Git installieren

Lassen Sie uns Java auf Ihrem Computer installieren.

Installation unter Windows

Wie üblich müssen Sie eine exe-Datei herunterladen und ausführen. Hier ist alles ganz einfach: Klicken Sie auf den ersten Google-Link , führen Sie die Installation durch und fertig. Dazu verwenden wir die von Windows bereitgestellte Bash-Konsole. Unter Windows müssen Sie Git Bash ausführen. So sieht es im Startmenü aus: Dies ist nun eine Eingabeaufforderung, mit der Sie arbeiten können. Um nicht jedes Mal in den Ordner mit dem Projekt gehen zu müssen, um Git dort zu öffnen, können Sie mit der rechten Maustaste die Eingabeaufforderung im Projektordner mit dem von uns benötigten Pfad öffnen:

Installation unter Linux

Normalerweise ist Git Teil von Linux-Distributionen und bereits installiert, da es sich um ein Tool handelt, das ursprünglich für die Linux-Kernel-Entwicklung geschrieben wurde. Aber es gibt Situationen, in denen das nicht der Fall ist. Um dies zu überprüfen, müssen Sie ein Terminal öffnen und Folgendes schreiben: git --version. Wenn Sie eine verständliche Antwort erhalten, muss nichts installiert werden. Öffnen Sie ein Terminal und installieren Sie Git unter Ubuntu . Ich arbeite an Ubuntu, daher kann ich Ihnen sagen, was Sie dafür schreiben sollen: sudo apt-get install git.

Installation unter macOS

Auch hier muss zunächst geprüft werden, ob Git bereits vorhanden ist. Wenn Sie es nicht haben, können Sie es am einfachsten herunterladen, indem Sie die neueste Version hier herunterladen . Wenn Xcode installiert ist, wird Git definitiv automatisch installiert.

Git-Einstellungen

Git verfügt über Benutzereinstellungen für den Benutzer, der Arbeiten einreichen wird. Dies ist sinnvoll und notwendig, da Git diese Informationen beim Erstellen eines Commits für das Feld „Autor“ übernimmt. Richten Sie einen Benutzernamen und ein Passwort für alle Ihre Projekte ein, indem Sie die folgenden Befehle ausführen:

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

Wenn Sie den Autor für ein bestimmtes Projekt ändern müssen, können Sie „--global“ entfernen. Dadurch erhalten wir Folgendes:

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

Ein bisschen Theorie...

Um tiefer in das Thema einzutauchen, sollten wir Ihnen ein paar neue Wörter und Taten vorstellen...

• Git-Repository
• begehen
• Zweig
• verschmelzen
• Konflikte
• ziehen
• drücken
• So ignorieren Sie einige Dateien (.gitignore)

Usw.

Status in Git

Git hat mehrere Statuen, die verstanden und erinnert werden müssen:

• nicht verfolgt
• geändert
• inszeniert
• engagiert

Wie soll man das verstehen?

Dies sind Status, die für die Dateien gelten, die unseren Code enthalten:

1. Eine Datei, die erstellt, aber noch nicht zum Repository hinzugefügt wurde, hat den Status „nicht verfolgt“.
2. Wenn wir Änderungen an Dateien vornehmen, die bereits zum Git-Repository hinzugefügt wurden, ist ihr Status „geändert“.
3. Unter den von uns geänderten Dateien wählen wir diejenigen aus, die wir benötigen, und diese Klassen werden in den Status „bereitgestellt“ geändert.
4. Ein Commit wird aus vorbereiteten Dateien im bereitgestellten Zustand erstellt und in das Git-Repository verschoben. Danach gibt es keine Dateien mit dem Status „bereitgestellt“. Es können aber dennoch Dateien vorhanden sein, deren Status „geändert“ ist.

So sieht es aus:

Was ist ein Commit?

Ein Commit ist das Hauptereignis bei der Versionskontrolle. Es enthält alle Änderungen, die seit Beginn des Commits vorgenommen wurden. Commits sind wie eine einfach verknüpfte Liste miteinander verknüpft. Genauer gesagt: Es gibt einen ersten Commit. Wenn der zweite Commit erstellt wird, weiß er, was nach dem ersten kommt. Und auf diese Weise können Informationen nachverfolgt werden. Ein Commit verfügt auch über eigene Informationen, sogenannte Metadaten:

• die eindeutige Kennung des Commits, die zum Auffinden des Commits verwendet werden kann
• der Name des Autors des Commits, der es erstellt hat
• das Datum, an dem der Commit erstellt wurde
• ein Kommentar, der beschreibt, was während des Commits getan wurde

So sieht es aus:

Was ist eine Filiale?

Ein Branch ist ein Zeiger auf einen Commit. Da ein Commit weiß, welcher Commit ihm vorangeht, gelten alle vorherigen Commits auch für ihn, wenn ein Zweig auf einen Commit zeigt. Dementsprechend könnten wir sagen, dass Sie so viele Zweige haben können, wie Sie möchten, die auf denselben Commit verweisen. Die Arbeit erfolgt in Zweigen. Wenn also ein neuer Commit erstellt wird, verschiebt der Zweig seinen Zeiger auf den neueren Commit.

Erste Schritte mit Git

Sie können sowohl mit einem lokalen Repository allein als auch mit einem Remote-Repository arbeiten. Um die erforderlichen Befehle zu üben, können Sie sich auf das lokale Repository beschränken. Es speichert lediglich alle Projektinformationen lokal im .git-Ordner. Wenn wir über das Remote-Repository sprechen, werden alle Informationen irgendwo auf dem Remote-Server gespeichert: Nur eine Kopie des Projekts wird lokal gespeichert. An Ihrer lokalen Kopie vorgenommene Änderungen können per Push (Git Push) in das Remote-Repository übertragen werden. In unserer Diskussion hier und unten sprechen wir über die Arbeit mit Git in der Konsole. Natürlich können Sie eine Art GUI-basierte Lösung verwenden (z. B. IntelliJ IDEA), aber zunächst sollten Sie herausfinden, welche Befehle ausgeführt werden und was sie bedeuten.

Arbeiten mit Git in einem lokalen Repository

Als nächstes schlage ich vor, dass Sie alle Schritte befolgen und ausführen, die ich beim Lesen des Artikels ausgeführt habe. Dies wird Ihr Verständnis und Ihre Beherrschung des Materials verbessern. Nun, guten Appetit! :) Um ein lokales Repository zu erstellen, müssen Sie Folgendes schreiben:

git init

Dadurch wird ein .git-Ordner im aktuellen Verzeichnis der Konsole erstellt. Im .git-Ordner werden alle Informationen zum Git-Repository gespeichert. Löschen Sie es nicht ;) Als nächstes werden Dateien zum Projekt hinzugefügt und ihnen wird der Status „Untracked“ zugewiesen. Um den aktuellen Status Ihrer Arbeit zu überprüfen, schreiben Sie Folgendes:

git status

Wir befinden uns im Hauptzweig und bleiben hier, bis wir in einen anderen Zweig wechseln. Hier wird angezeigt, welche Dateien geändert wurden, aber noch nicht in den Status „bereitgestellt“ aufgenommen wurden. Um ihnen den Status „staged“ hinzuzufügen, müssen Sie „git add“ schreiben. Hier haben wir einige Möglichkeiten, zum Beispiel:

• git add -A – fügt allen Dateien den Status „bereitgestellt“ hinzu
• git add . – Alle Dateien aus diesem Ordner und allen Unterordnern hinzufügen. Im Wesentlichen ist dies dasselbe wie das vorherige
• git add <Dateiname> – fügt eine bestimmte Datei hinzu. Hier können Sie reguläre Ausdrücke verwenden, um Dateien nach einem bestimmten Muster hinzuzufügen. Beispiel: git add *.java: Dies bedeutet, dass Sie nur Dateien mit der Java-Erweiterung hinzufügen möchten.

Die ersten beiden Optionen sind eindeutig einfach. Mit der neuesten Ergänzung wird es noch interessanter, also schreiben wir:

git add *.txt

Um den Status zu überprüfen, verwenden wir den uns bereits bekannten Befehl:

git status

Hier sehen Sie, dass der reguläre Ausdruck korrekt funktioniert hat: test_resource.txt hat nun den Status „staged“. Und schließlich der letzte Schritt für die Arbeit mit einem lokalen Repository (bei der Arbeit mit dem Remote-Repository gibt es noch einen weiteren ;)) – Erstellen eines neuen Commits:

git commit -m "all txt files were added to the project"

Als nächstes folgt ein großartiger Befehl zum Betrachten des Commit-Verlaufs in einem Zweig. Nutzen wir es:

git log

Hier können Sie sehen, dass wir unser erstes Commit erstellt haben und es den Text enthält, den wir in der Befehlszeile bereitgestellt haben. Es ist sehr wichtig zu verstehen, dass dieser Text so genau wie möglich erklären sollte, was während dieses Commits getan wurde. Das wird uns in Zukunft noch oft helfen. Ein neugieriger Leser, der noch nicht eingeschlafen ist, fragt sich vielleicht, was mit der Datei GitTest.java passiert ist. Finden wir es gleich heraus. Dazu verwenden wir:

git status

Wie Sie sehen können, ist es noch „unverfolgt“ und wartet in den Startlöchern. Aber was ist, wenn wir es überhaupt nicht zum Projekt hinzufügen möchten? Manchmal passiert das. Um die Sache interessanter zu machen, versuchen wir nun, unsere Datei test_resource.txt zu ändern. Fügen wir dort etwas Text hinzu und überprüfen Sie den Status:

git status

Hier erkennt man deutlich den Unterschied zwischen den Status „untracked“ und „modified“. GitTest.java ist „untracked“, während test_resource.txt „modified“ ist. Da sich die Dateien nun im geänderten Zustand befinden, können wir die daran vorgenommenen Änderungen untersuchen. Dies kann mit dem folgenden Befehl erfolgen:

git diff

Das heißt, Sie können hier deutlich sehen, was ich unserer Textdatei hinzugefügt habe: Hallo Welt! Fügen wir unsere Änderungen zur Textdatei hinzu und erstellen einen Commit:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

Um alle Commits anzuzeigen, schreiben Sie:

git log

Wie Sie sehen, haben wir jetzt zwei Commits. Wir werden GitTest.java auf die gleiche Weise hinzufügen. Keine Kommentare hier, nur Befehle:

git add GitTest.java
git commit -m "added GitTest.java"
git status

Arbeiten mit .gitignore

Natürlich möchten wir nur den Quellcode und nichts anderes im Repository behalten. Was könnte es sonst noch sein? Zumindest kompilierte Klassen und/oder Dateien, die von Entwicklungsumgebungen generiert wurden. Um Git anzuweisen, sie zu ignorieren, müssen wir eine spezielle Datei erstellen. Gehen Sie folgendermaßen vor: Erstellen Sie eine Datei mit dem Namen .gitignore im Stammverzeichnis des Projekts. Jede Zeile in dieser Datei stellt ein Muster dar, das ignoriert werden soll. In diesem Beispiel sieht die .gitignore-Datei so aus:

```
*.class
target/
*.iml
.idea/
```

Lass uns einen Blick darauf werfen:

• Die erste Zeile besteht darin, alle Dateien mit der Erweiterung .class zu ignorieren
• Die zweite Zeile besteht darin, den Ordner „Ziel“ und alles, was er enthält, zu ignorieren
• Die dritte Zeile besteht darin, alle Dateien mit der Erweiterung .iml zu ignorieren
• Die vierte Zeile dient zum Ignorieren des .idea-Ordners

Versuchen wir es anhand eines Beispiels. Um zu sehen, wie es funktioniert, fügen wir die kompilierte GitTest.class zum Projekt hinzu und überprüfen den Projektstatus:

git status

Natürlich möchten wir die kompilierte Klasse nicht versehentlich zum Projekt hinzufügen (mithilfe von git add -A). Erstellen Sie dazu eine .gitignore-Datei und fügen Sie alles hinzu, was zuvor beschrieben wurde: Nun fügen wir die .gitignore-Datei per Commit zum Projekt hinzu:

git add .gitignore
git commit -m "added .gitignore file"

Und jetzt der Moment der Wahrheit: Wir haben eine kompilierte Klasse GitTest.class, die „nicht verfolgt“ ist und die wir nicht zum Git-Repository hinzufügen wollten. Jetzt sollten wir die Auswirkungen der .gitignore-Datei sehen:

git status

Perfekt! .gitignore +1 :)

Arbeiten mit Zweigen und dergleichen

Natürlich ist die Arbeit in nur einer Branche für Einzelentwickler unbequem und unmöglich, wenn mehr als eine Person in einem Team ist. Deshalb haben wir Niederlassungen. Wie ich bereits sagte, ist ein Zweig nur ein beweglicher Zeiger auf Commits. In diesem Teil befassen wir uns mit der Arbeit in verschiedenen Zweigen: wie Änderungen von einem Zweig in einen anderen zusammengeführt werden, welche Konflikte auftreten können und vieles mehr. Um eine Liste aller Zweige im Repository anzuzeigen und zu verstehen, in welchem ​​Zweig Sie sich befinden, müssen Sie Folgendes schreiben:

git branch -a

Sie sehen, dass wir nur eine Hauptniederlassung haben. Das Sternchen davor zeigt an, dass wir uns darin befinden. Übrigens können Sie auch den Befehl „git status“ verwenden, um herauszufinden, in welchem ​​Zweig wir uns befinden. Dann gibt es mehrere Möglichkeiten, Zweige zu erstellen (möglicherweise gibt es noch mehr – diese verwende ich):

• Erstellen Sie einen neuen Zweig basierend auf dem, in dem wir uns befinden (99 % der Fälle).
• Erstellen Sie einen Zweig basierend auf einem bestimmten Commit (1 % der Fälle)

Lassen Sie uns einen Zweig basierend auf einem bestimmten Commit erstellen

Wir verlassen uns auf die eindeutige Kennung des Commits. Um es zu finden, schreiben wir:

git log

Ich habe den Commit mit dem Kommentar „Hallo Welt hinzugefügt…“ hervorgehoben. Seine eindeutige Kennung ist 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Ich möchte einen „Entwicklungs“-Zweig erstellen, der mit diesem Commit beginnt. Dazu schreibe ich:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Ein Zweig wird nur mit den ersten beiden Commits des Hauptzweigs erstellt. Um dies zu überprüfen, wechseln wir zunächst zu einem anderen Zweig und schauen uns dort die Anzahl der Commits an:

git status
git log

Und wie erwartet haben wir zwei Commits. Hier ist übrigens ein interessanter Punkt: In diesem Zweig gibt es noch keine .gitignore-Datei, daher wird unsere kompilierte Datei (GitTest.class) jetzt mit dem Status „Untracked“ hervorgehoben. Jetzt können wir unsere Filialen noch einmal überprüfen, indem wir Folgendes schreiben:

git branch -a

Sie können sehen, dass es zwei Zweige gibt: „Master“ und „Entwicklung“. Wir befinden uns derzeit in der Entwicklung.

Erstellen wir einen Zweig basierend auf dem aktuellen

Die zweite Möglichkeit, einen Zweig zu erstellen, besteht darin, ihn aus einem anderen zu erstellen. Ich möchte einen Zweig basierend auf dem Hauptzweig erstellen. Zuerst muss ich dorthin wechseln und im nächsten Schritt muss ich ein neues erstellen. Lass uns einen Blick darauf werfen:

• git checkout master – Wechseln Sie zum Master-Zweig
• Git-Status – Überprüfen Sie, ob wir uns tatsächlich im Master-Zweig befinden

Hier können Sie sehen, dass wir zum Hauptzweig gewechselt sind, die .gitignore-Datei wirksam ist und die kompilierte Klasse nicht mehr als „nicht verfolgt“ hervorgehoben ist. Jetzt erstellen wir einen neuen Branch basierend auf dem Master-Branch:

git checkout -b feature/update-txt-files

Wenn Sie sich nicht sicher sind, ob dieser Zweig mit „master“ identisch ist, können Sie dies ganz einfach überprüfen, indem Sie „git log“ ausführen und sich alle Commits ansehen. Es sollten vier davon sein.

Konfliktlösung

Bevor wir untersuchen, was ein Konflikt ist, müssen wir über die Zusammenführung eines Zweigs mit einem anderen sprechen. Dieses Bild zeigt den Prozess der Zusammenführung eines Zweigs mit einem anderen: Hier haben wir einen Hauptzweig. Irgendwann wird aus dem Hauptzweig ein sekundärer Zweig erstellt und dann geändert. Sobald die Arbeit erledigt ist, müssen wir einen Zweig mit dem anderen zusammenführen. Ich werde nicht auf die verschiedenen Funktionen eingehen: In diesem Artikel möchte ich nur ein allgemeines Verständnis vermitteln. Wenn Sie die Details benötigen, können Sie diese selbst nachschlagen. In unserem Beispiel haben wir den Zweig „feature/update-txt-files“ erstellt. Wie aus dem Namen des Zweigs hervorgeht, aktualisieren wir den Text. Jetzt müssen wir ein neues Commit für diese Arbeit erstellen:

git add *.txt 
git commit -m "updated txt files"
git log

Wenn wir nun den Zweig „feature/update-txt-files“ im Master zusammenführen möchten, müssen wir zum Master gehen und „git merge feature/update-txt-files“ schreiben:

git checkout master
git merge feature/update-txt-files
git log

Daher enthält der Master-Zweig nun auch den Commit, der zu den Feature/Update-txt-Dateien hinzugefügt wurde. Diese Funktionalität wurde hinzugefügt, sodass Sie einen Feature-Zweig löschen können. Dazu schreiben wir:

git branch -D feature/update-txt-files

Bisher ist alles klar, oder? Machen wir die Situation noch komplizierter: Nehmen wir an, Sie müssen die TXT-Datei erneut ändern. Nun wird diese Datei aber auch im Master-Zweig geändert. Mit anderen Worten: Es wird sich parallel ändern. Git wird nicht herausfinden können, was zu tun ist, wenn wir unseren neuen Code in den Master-Zweig einbinden möchten. Lass uns gehen! Wir erstellen einen neuen Zweig basierend auf Master, nehmen Änderungen an text_resource.txt vor und erstellen einen Commit für diese Arbeit:

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

Gehen Sie zum Master-Zweig und aktualisieren Sie auch diese Textdatei in derselben Zeile wie im Feature-Zweig:

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

Und nun der interessanteste Punkt: Wir müssen Änderungen vom Feature/Add-Header-Zweig zum Master zusammenführen. Wir befinden uns im Master-Zweig, also müssen wir nur schreiben:

git merge feature/add-header

Das Ergebnis wird jedoch ein Konflikt in der Datei test_resource.txt sein: Hier sehen wir, dass Git nicht selbst entscheiden konnte, wie dieser Code zusammengeführt wird. Es sagt uns, dass wir zuerst den Konflikt lösen und erst dann den Commit durchführen müssen. OK. Wir öffnen die Datei mit dem Konflikt in einem Texteditor und sehen: Um zu verstehen, was Git hier gemacht hat, müssen wir uns merken, welche Änderungen wir wo vorgenommen haben, und dann vergleichen:

1. Die Änderungen, die in dieser Zeile im Hauptzweig vorgenommen wurden, befinden sich zwischen „<<<<<<< HEAD“ und „=======".
2. Die Änderungen, die im Zweig „feature/add-header“ vorgenommen wurden, befinden sich zwischen „=======" und „>>>>>>> feature/add-header".

So teilt uns Git mit, dass es nicht herausfinden konnte, wie die Zusammenführung an dieser Stelle in der Datei durchgeführt werden kann. Es unterteilt diesen Abschnitt in zwei Teile aus den verschiedenen Zweigen und lädt uns ein, den Zusammenführungskonflikt selbst zu lösen. Fair genug. Ich entscheide mich mutig, alles zu entfernen und nur das Wort „Header“ übrig zu lassen: Schauen wir uns den Status der Änderungen an. Die Beschreibung wird etwas anders sein. Anstelle eines „modifizierten“ Status haben wir einen „aufgelösten“ Status. Hätten wir also einen fünften Status erwähnen können? Ich glaube nicht, dass das notwendig ist. Mal sehen:

git status

Wir können uns davon überzeugen, dass es sich hierbei um einen besonderen, ungewöhnlichen Fall handelt. Lass uns weitermachen:

git add *.txt

Möglicherweise fällt Ihnen auf, dass in der Beschreibung nur „Git Commit“ vorgeschlagen wird. Versuchen wir, Folgendes zu schreiben:

git commit

Und einfach so haben wir es geschafft – wir haben den Konflikt in der Konsole gelöst. In integrierten Entwicklungsumgebungen geht das natürlich etwas einfacher. In IntelliJ IDEA ist beispielsweise alles so gut eingerichtet, dass Sie alle notwendigen Aktionen direkt darin ausführen können. Aber IDEs erledigen viele Dinge „unter der Haube“, und wir verstehen oft nicht, was genau dort passiert. Und wenn es kein Verständnis gibt, können Probleme entstehen.

Arbeiten mit Remote-Repositorys

Der letzte Schritt besteht darin, einige weitere Befehle herauszufinden, die für die Arbeit mit dem Remote-Repository erforderlich sind. Wie gesagt, ein Remote-Repository ist ein Ort, an dem das Repository gespeichert ist und von dem aus Sie es klonen können. Welche Arten von Remote-Repositorys gibt es? Beispiele:

• GitHub ist die größte Speicherplattform für Repositories und kollaborative Entwicklung. Ich habe es bereits in früheren Artikeln beschrieben.
  Folgen Sie mir auf GitHub . Ich zeige dort oft meine Arbeit in den Bereichen, die ich beruflich studiere.

• GitLab ist ein webbasiertes Tool für den DevOps- Lebenszyklus mit Open Source . Es handelt sich um ein Git -basiertes System zur Verwaltung von Code-Repositorys mit eigenem Wiki, Bug-Tracking-System , CI/CD-Pipeline und anderen Funktionen.
  Nach der Nachricht, dass Microsoft GitHub gekauft hat, duplizierten einige Entwickler ihre Projekte in GitLab.

• BitBucket ist ein Webdienst für Projekthosting und kollaborative Entwicklung, der auf den Versionskontrollsystemen Mercurial und Git basiert. Einst hatte es einen großen Vorteil gegenüber GitHub, da es kostenlose private Repositories anbot. Letztes Jahr hat GitHub diese Funktion auch allen kostenlos zur Verfügung gestellt.

• Usw…

Wenn Sie mit einem Remote-Repository arbeiten, müssen Sie zunächst das Projekt in Ihr lokales Repository klonen. Dazu habe ich das Projekt, das wir lokal erstellt haben, exportiert, und jetzt kann es jeder für sich selbst klonen, indem er Folgendes schreibt:

git clone https://github.com/romankh3/git-demo

Es gibt nun eine vollständige lokale Kopie des Projekts. Um sicherzustellen, dass die lokale Kopie des Projekts die neueste ist, müssen Sie das Projekt abrufen, indem Sie Folgendes schreiben:

git pull

In unserem Fall hat sich im Remote-Repository derzeit nichts geändert, daher lautet die Antwort: Bereits auf dem neuesten Stand. Wenn ich jedoch Änderungen am Remote-Repository vornehme, wird das lokale aktualisiert, nachdem wir sie abgerufen haben. Und schließlich besteht der letzte Befehl darin, die Daten in das Remote-Repository zu übertragen. Wenn wir etwas lokal erledigt haben und es an das Remote-Repository senden möchten, müssen wir zunächst lokal einen neuen Commit erstellen. Um dies zu demonstrieren, fügen wir noch etwas zu unserer Textdatei hinzu: Nun etwas ganz Gemeinsames für uns – wir erstellen einen Commit für diese Arbeit:

git add test_resource.txt
git commit -m "prepared txt for pushing"

Der Befehl, um dies in das Remote-Repository zu übertragen, lautet:

git push

Nun, das ist alles, was ich sagen wollte. Danke für Ihre Aufmerksamkeit. Folgen Sie mir auf GitHub , wo ich verschiedene coole Beispielprojekte poste, die sich auf mein persönliches Studium und meine Arbeit beziehen.

Nützlicher Link

• Offizielle Git-Dokumentation . Ich empfehle es als Referenz.