Erste Schritte mit Git: eine ausführliche Anleitung für Anfänger

Statt einer Einleitung

Hallo zukünftiger Senior Software Engineer. Heute werden wir über das Versionskontrollsystem sprechen, nämlich Git (gelesen als GIT und nicht als JIT, wie es aus der englischen Grammatik scheinen könnte). Ja, ja, ich weiß, dass es auch Mercurial und SVN gibt ... Aber seien wir ehrlich: Ihre Zeit ist bereits vergangen, und ich werde Ihre kostbare Zeit nicht mit ihnen verschwenden. Damit Sie verstehen, wie wichtig Git-Kenntnisse in unserer Zeit sind, sage ich Folgendes: Ohne Kenntnisse/Verständnis darüber haben Sie mit der Programmierung nichts zu tun. Aber das Schöne ist, dass man für die kontinuierliche Arbeit nicht alle Befehle und Möglichkeiten im Kopf behalten muss. 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 eine Art Arbeitsmanagementsystem. Wird benötigt, um Änderungen zu verfolgen, die im Laufe der Zeit auftreten. Das heißt, wir sehen Schritt für Schritt, welche Dateien sich wie geändert haben. Dies ist besonders wichtig, wenn Sie analysieren, was innerhalb einer Aufgabe erledigt wurde: So ist ein Zurückgehen möglich. Stellen wir uns eine Situation vor: Es gab einen funktionierenden Code, alles war gut darin, aber wir beschlossen, etwas zu verbessern, es hier zu optimieren, es dort zu optimieren. Alles war in Ordnung, aber diese Verbesserung machte die Hälfte der Funktionalität kaputt und machte das Arbeiten unmöglich. Und was dann? Ohne die Gita müsste man stundenlang dasitzen und sich daran erinnern, wie alles ursprünglich war. Also kehren wir einfach zum Commit zurück und das war’s. Oder was ist, wenn zwei Entwickler gleichzeitig ihre Codeänderungen vornehmen? Ohne Git sieht es so aus: Sie haben den Code vom Original kopiert und getan, was sie tun mussten. Der Moment kommt und beide möchten ihre Änderungen zum Hauptordner hinzufügen. Und was ist in dieser Situation zu tun? Ich wage nicht einmal die Zeit einzuschätzen, die für diese Arbeit erforderlich ist. Wenn Sie Git verwenden, treten solche Probleme überhaupt nicht auf.

Git installieren

Lassen Sie uns Git auf Ihrem Computer installieren. Ich verstehe, dass jeder ein anderes Betriebssystem hat, daher werde ich versuchen, mehrere Fälle zu beschreiben.

Installation für Windows

Wie üblich müssen Sie die exe-Datei herunterladen und ausführen. Hier ist alles ganz einfach: Klicken Sie auf den ersten Google-Link , installieren Sie und fertig. Für die Arbeit verwenden wir die von ihnen bereitgestellte Bash-Konsole. Um unter Windows zu arbeiten, müssen Sie Git Bash ausführen. So sieht es im Startmenü aus: Und das ist schon eine Konsole, in der man arbeiten kann. Um nicht jedes Mal in den Ordner mit dem Projekt zu gehen, um dort Git zu öffnen, können Sie mit der rechten Maustaste in den Ordner klicken, um die Konsole mit dem von uns benötigten Pfad zu öffnen:

Installation für Linux

Normalerweise ist Git bereits installiert und in Linux-Distributionen enthalten, da es sich um ein Tool handelt, das ursprünglich für die Entwicklung des Linux-Kernels geschrieben wurde. Aber es gibt Situationen, in denen es nicht da ist. Um dies zu überprüfen, müssen Sie ein Terminal öffnen und Folgendes eingeben: git --version. Wenn es eine klare Antwort gibt, muss nichts installiert werden. Öffnen Sie ein Terminal und installieren Sie es. Ich arbeite mit Ubuntu, daher kann ich Ihnen sagen, was Sie dafür schreiben sollen: sudo apt-get install git. Und das war's: Jetzt können Sie Git in jedem Terminal verwenden.

Installation auf macOS

Auch hier muss zunächst geprüft werden, ob Git bereits existiert (siehe oben, wie unter Linux). Wenn nicht, ist es am einfachsten, die neueste Version herunterzuladen . Wenn XCode installiert ist, wird Git definitiv automatisch installiert.

Git-Setup

Der Git verfügt über eine Benutzereinstellung, von der aus die Arbeit ausgeführt wird. Dies ist eine sinnvolle und notwendige Sache, denn wenn ein Commit erstellt wird, übernimmt Git genau diese Informationen für das Feld „Autor“. Um einen Benutzernamen und ein Passwort für alle Projekte einzurichten, müssen Sie die folgenden Befehle eingeben:

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

Wenn es notwendig ist, den Autor für ein bestimmtes Projekt zu ändern (z. B. für ein persönliches Projekt), können Sie --global entfernen, und das wird funktionieren:

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

Eine kleine Theorie...

Um beim Thema zu bleiben, empfiehlt es sich, Ihrer Nachricht ein paar neue Worte und Taten hinzuzufügen... Sonst gibt es nichts zu besprechen. Natürlich handelt es sich hierbei um Fachjargon und eine Kopie des Englischen, daher werde ich Bedeutungen auf Englisch hinzufügen. Welche Worte und Taten?

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

Usw.

Zustände in Git

In der Gita gibt es mehrere Zustände, die verstanden und beachtet werden müssen:

• nicht verfolgt;
• geändert;
• vorbereitet (inszeniert);
• engagiert.

Was bedeutet das?

Dies sind die Zustände, in denen sich die Dateien aus unserem Code befinden. Das heißt, ihr Lebensweg sieht normalerweise so aus:

1. Eine Datei, die erstellt und nicht zum Repository hinzugefügt wird, befindet sich im nicht verfolgten Zustand.
2. Wir nehmen Änderungen an Dateien vor, die bereits zum Git-Repository hinzugefügt wurden – sie befinden sich im geänderten Zustand.
3. Aus den von uns geänderten Dateien wählen wir nur diejenigen (oder alle) aus, die wir benötigen (wir benötigen beispielsweise keine kompilierten Klassen), und diese Klassen mit Änderungen fallen in den bereitgestellten Zustand.
4. Ein Commit wird aus den vorbereiteten Dateien aus dem bereitgestellten Zustand erstellt und in das Git-Repository verschoben. Danach ist der bereitgestellte Zustand leer. Aber geändert kann immer noch etwas enthalten.

Es sieht so aus (Bild aus dem offiziellen Dokument, damit Sie ihm vertrauen können)):

Was ist ein Commit?

Ein Commit ist das Hauptobjekt der Versionskontrolle. Es enthält alle Änderungen seit diesem Commit. Commits sind wie eine einfach verknüpfte Liste miteinander verknüpft. Nämlich: Es gibt den ersten Commit. Wenn ein zweiter Commit erstellt wird, weiß er (der zweite), dass er nach dem ersten kommt. Und auf diese Weise können Sie die Informationen verfolgen. Der Commit verfügt außerdem über eigene Informationen, sogenannte Metadaten:

• eine eindeutige Commit-ID, anhand derer Sie sie finden können;
• der Name des Commit-Autors, der es erstellt hat;
• Erstellungsdatum des Commits;
• ein Kommentar, der beschreibt, was während dieses 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 vorausging, verweisen alle vorherigen Commits ebenfalls darauf, wenn ein Zweig auf einen Commit zeigt. Auf dieser Grundlage können wir sagen, dass es beliebig viele Zweige geben kann, die auf denselben Commit verweisen. Die Arbeit erfolgt an Zweigen. Wenn also ein neuer Commit erstellt wird, verschiebt der Zweig seinen Zeiger auf den neueren Commit.

Erste Schritte mit Git

Sie können nur mit einem lokalen Repository oder mit einem Remote-Repository arbeiten. Um die notwendigen Befehle auszuarbeiten, können Sie nur das lokale Repository verwenden. Es speichert alle Informationen nur lokal im Projekt im .git-Ordner. Wenn wir von Remote sprechen, werden alle Informationen irgendwo auf einem Remote-Server gespeichert: Nur eine Kopie des Projekts wird lokal gespeichert, Änderungen daran können per Push (Git Push) in das Remote-Repository übertragen werden. Hier und weiter werden wir die Arbeit mit Git in der Konsole besprechen. Natürlich können Sie einige grafische Lösungen verwenden (z. B. in Intellij IDEA), aber zuerst müssen 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, die ich beim Lesen des Artikels durchgeführt habe. Dies wird Ihr Verständnis und Ihre Erinnerung an den Stoff verbessern. Also guten Appetit :) Um ein lokales Repository zu erstellen, müssen Sie Folgendes schreiben:

git init

Dadurch wird ein .git-Ordner an dem Ort erstellt, an dem sich die Konsole befindet. .git ist ein Ordner, der alle Informationen über das Git-Repository speichert. Es besteht keine Notwendigkeit, es zu löschen ;) Als Nächstes werden Dateien zu diesem Projekt hinzugefügt und ihr Status lautet „Nicht verfolgt“. Um den aktuellen Arbeitsstatus zu sehen, schreiben Sie:

git status

Wir befinden uns in der Hauptniederlassung, und bis wir in eine andere wechseln, wird alles so bleiben. Auf diese Weise können Sie sehen, welche Dateien geändert, aber noch nicht zum bereitgestellten Status hinzugefügt wurden. Um sie zum bereitgestellten Status hinzuzufügen, müssen Sie git add schreiben. Hier kann es mehrere Möglichkeiten geben, zum Beispiel:

• git add -A – alle Dateien aus dem bereitgestellten Zustand hinzufügen;
• git add . — Alle Dateien aus diesem Ordner und alle internen hinzufügen. Im Wesentlichen das Gleiche wie das vorherige;
• git add <Dateiname> – fügt nur eine bestimmte Datei hinzu. Hier können Sie reguläre Ausdrücke verwenden, um sie nach einem bestimmten Muster hinzuzufügen. Beispiel: git add *.java: Dies bedeutet, dass Sie nur Dateien mit der Java-Erweiterung hinzufügen müssen.

Es ist klar, dass die ersten beiden Optionen einfach sind, aber mit der Ergänzung wird es interessanter, also schreiben wir:

git add *.txt

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

git status

Daraus können wir erkennen, dass der reguläre Ausdruck ordnungsgemäß funktioniert hat und sich test_resource.txt nun in einem bereitgestellten Zustand befindet. Und schließlich die letzte Stufe (bei einem lokalen Repository, bei einem Remote-Repository wird es noch eine geben ;)) – Commit durchführen und ein neues Commit erstellen:

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

Als nächstes gibt es einen großartigen Befehl, um den Commit-Verlauf eines Zweigs anzuzeigen. Nutzen wir es:

git log

Hier sehen Sie bereits, dass unser erster Commit mit dem von uns übertragenen Text erschienen ist. Es ist sehr wichtig zu verstehen, dass der von uns übergebene Text so genau wie möglich beschreiben muss, was während dieses Commits getan wurde. Das wird in Zukunft noch oft helfen. Ein neugieriger Leser, der noch nicht eingeschlafen ist, könnte fragen: Was ist mit der Datei GitTest.java passiert? Jetzt werden wir es herausfinden. Verwenden Sie dafür:

git status

Wie wir sehen können, bleibt es im unverfolgten Zustand und wartet in den Startlöchern. Oder möchten wir es vielleicht überhaupt nicht zum Projekt hinzufügen? Manchmal passiert es. Um es interessanter zu machen, versuchen wir als Nächstes, unsere Textdatei 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 beiden Zuständen – unverfolgt und verändert. GitTest.java befindet sich im nicht verfolgten Zustand und test_resource.txt befindet sich im geänderten Zustand. Da sich nun bereits Dateien im geänderten Zustand befinden, können wir uns die Änderungen ansehen, die an ihnen vorgenommen wurden. Dies kann mit dem Befehl erfolgen:

git diff

Das heißt, Sie können hier deutlich erkennen, dass ich unserer Textdatei „hello world!“ hinzugefügt habe. Fügen Sie Änderungen zur Textdatei hinzu und übernehmen Sie Folgendes:

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, gibt es bereits zwei Commits. Auf die gleiche Weise fügen wir GitTest.java hinzu. Jetzt keine Kommentare, nur Befehle:

git add GitTest.java
git commit -m “added GitTest.java”
git status

Arbeiten mit .gitignore

Es ist klar, dass wir nur den Quellcode und nichts anderes im Repository speichern wollen. Was könnte es sonst sein? Zumindest kompilierte Klassen und/oder Dateien, die Entwicklungsumgebungen erstellen. Damit Git sie ignorieren kann, muss eine spezielle Datei erstellt werden. Wir machen Folgendes: Wir erstellen eine Datei im Stammverzeichnis des Projekts mit dem Namen .gitignore, und in dieser Datei ist jede Zeile ein Muster, das ignoriert werden soll. In diesem Beispiel würde Git Ignore so aussehen:

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

Schauen wir uns jetzt an:

• Die erste Zeile besteht darin, alle Dateien mit der Erweiterung .class zu ignorieren.
• Die zweite Zeile besteht darin, den Zielordner 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 das funktioniert, fügen Sie die kompilierte Klasse GitTest.class zum Projekt hinzu und sehen Sie sich den Projektstatus an:

git status

Natürlich möchten wir nicht versehentlich (wenn wir git add -A verwenden) dem Projekt eine kompilierte Klasse hinzufügen. Erstellen Sie dazu eine .gitignore-Datei und fügen Sie alles hinzu, was zuvor beschrieben wurde: Jetzt fügen wir Git Ignore mit einem neuen Commit zum Projekt hinzu:

git add .gitignore
git commit -m “added .gitignore file”

Und jetzt kommt die Stunde der Wahrheit: Wir haben eine kompilierte GitTest.class-Klasse in einem nicht verfolgten Zustand, die wir nicht zum Git-Repository hinzufügen wollten. Hier sollte Git Ignore funktionieren:

git status

Alles ist klar) Git ignorieren +1)

Arbeiten mit Ästen und dergleichen

Natürlich ist die Arbeit in einer Filiale für den Einzelnen umständlich und unmöglich, wenn mehr als eine Person im Team ist. Dafür gibt es eine Filiale. Wie ich bereits sagte, ist ein Zweig lediglich 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 können sehen, dass wir nur einen Master-Zweig haben und das Sternchen davor sagt, dass wir uns darin befinden. Um herauszufinden, in welchem ​​Zweig wir uns befinden, können wir übrigens auch den Statuscheck (Git-Status) nutzen. Als nächstes gibt es mehrere Optionen zum Erstellen von Zweigen (vielleicht gibt es noch mehr, ich verwende diese):

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

Erstellen Sie einen Zweig basierend auf einem bestimmten Commit

Wir verlassen uns auf die eindeutige Commit-ID. Um es zu finden, schreiben wir:

git log

Ich habe den Commit mit dem Kommentar „Hallo Welt hinzugefügt…“ hervorgehoben. Es hat eine eindeutige Kennung – „6c44e53d06228f888f2f454d3cb8c1c976dd73f8“. Ich möchte ausgehend von diesem Commit einen Entwicklungszweig erstellen. Dazu schreibe ich:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

Es wird ein Zweig erstellt, der nur die ersten beiden Commits des Hauptzweigs enthält. Um dies zu testen, stellen wir zunächst sicher, dass wir in einen anderen Zweig umgezogen sind, und sehen uns die Anzahl der darin vorgenommenen Commits an:

git status
git log

Und es stimmt: Es stellte sich heraus, dass wir zwei Commits haben. Übrigens ein interessanter Punkt: In diesem Zweig gibt es noch keine .gitignore-Datei, daher wird unsere kompilierte Datei (GitTest.class) jetzt im nicht verfolgten Zustand hervorgehoben. Jetzt können wir unsere Zweige noch einmal überarbeiten, indem wir schreiben:

git branch -a

Es ist ersichtlich, dass es zwei Zweige gibt – Master und Entwicklung – und jetzt sind wir bei der Entwicklung.

Erstellen Sie einen Zweig basierend auf dem aktuellen

Die zweite Möglichkeit, einen Zweig zu erstellen, besteht darin, auf einem anderen aufzubauen. Ich möchte einen Zweig basierend auf dem Hauptzweig erstellen, daher muss ich zuerst zu diesem wechseln und im nächsten Schritt einen neuen Zweig erstellen. Lass uns nachsehen:

• git checkout master – zum Master-Zweig wechseln;
• Git-Status – Überprüfen Sie, ob es sich auf dem Master befindet.

Hier können Sie sehen, dass wir in den Hauptzweig gewechselt sind, Git Ignore hier bereits funktioniert und die kompilierte Klasse nicht mehr als nicht verfolgt angezeigt wird. Jetzt erstellen wir einen neuen Branch basierend auf dem Master-Branch:

git checkout -b feature/update-txt-files

Wenn Sie Zweifel haben, dass dieser Zweig nicht mit dem Master-Zweig identisch ist, können Sie dies leicht überprüfen, indem Sie ein Git-Protokoll schreiben und sich alle Commits ansehen. Es sollten vier davon sein.

Konflikte lösen

Bevor wir verstehen, was ein Konflikt ist, müssen wir über das Zusammenführen (Zusammenführen) eines Zweigs mit einem anderen sprechen. Dieses Bild kann den Vorgang zeigen, wenn ein Zweig mit einem anderen zusammengeführt wird: Das heißt, es gibt einen Hauptzweig. Irgendwann entsteht daraus ein Sekundäres, in dem es zu Veränderungen kommt. Sobald die Arbeit erledigt ist, müssen Sie einen Zweig mit einem anderen zusammenführen. Ich werde nicht auf verschiedene Funktionen eingehen: Ich möchte im Rahmen dieses Artikels nur Verständnis vermitteln und Sie werden die Details bei Bedarf selbst herausfinden. In unserem Beispiel haben wir also den Zweig „feature/update-txt-files“ erstellt. Da es im Namen der Branche geschrieben steht, werden wir den Text aktualisieren. Jetzt müssen Sie ein neues Commit für diese Angelegenheit erstellen:

git add *.txt 
git commit -m “updated txt files”
git log

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

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

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

git branch -D feature/update-txt-files

Soweit ist es klar, oder? Machen wir die Situation komplizierter: Nehmen wir nun an, dass wir die TXT-Datei erneut ändern müssen. Jetzt wird aber auch diese Datei im Assistenten geändert. Das heißt, es ändert sich parallel und Git kann nicht verstehen, was in einer Situation zu tun ist, in der wir neuen Code in den Master-Zweig einbinden möchten. Gehen! Wir erstellen einen neuen Zweig basierend auf Master, nehmen Änderungen an text_resource.txt vor und erstellen ein Commit für diese Angelegenheit:

git checkout -b feature/add-header
... делаем изменения в файле

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 der Feature-Zweig:

git checkout master
… обновoder test_resource.txt

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

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

git merge feature/add-header

Wir erhalten jedoch ein Ergebnis mit einem Konflikt in der Datei test_resource.txt: Und hier können wir sehen, dass Git nicht unabhängig entscheiden konnte, wie dieser Code zusammengeführt werden soll, und sagt, dass wir zuerst den Konflikt lösen und erst dann einen Commit durchführen müssen. Ok, öffnen wir die Datei mit dem Konflikt in einem Texteditor und sehen uns Folgendes an: Um zu verstehen, was Git hier getan hat, müssen Sie sich merken, was wir wo geschrieben haben, und vergleichen:

1. Zwischen „<<<<<<< HEAD“ und „=======“ stehen die Master-Änderungen, die in dieser Zeile im Master-Zweig vorgenommen wurden.
2. Zwischen „=======“ und „>>>>>>> feature/add-header“ gibt es Änderungen, die im Feature/add-header-Zweig vorgenommen wurden.

So zeigt Git, dass er zu diesem Zeitpunkt nicht herausfinden konnte, wie diese Datei zusammengeführt werden soll, teilte diesen Abschnitt in zwei Teile aus verschiedenen Zweigen auf und schlug vor, dass wir selbst entscheiden sollten. Okay, mit starkem Willen beschließe ich, alles zu entfernen und nur die Wortüberschrift zu belassen: Schauen wir uns den Status der Änderungen an, die Beschreibung wird etwas anders sein. Es wird keinen geänderten Status geben, sondern Unmerged. Wir könnten also getrost einen fünften Zustand hinzufügen ... Aber ich denke, das ist unnötig, mal sehen:

git status

Wir waren überzeugt, dass dies ein anderer, ungewöhnlicher Fall war. Lass uns weitermachen:

git add *.txt

In der Beschreibung werden Sie feststellen, dass nur das Schreiben von Git Commit empfohlen wird. Wir hören zu und schreiben:

git commit

Und das ist alles: So haben wir es gemacht – wir haben den Konflikt in der Konsole gelöst. In Entwicklungsumgebungen geht das natürlich etwas einfacher, zum Beispiel ist in Intellij IDEA alles so gut eingerichtet, dass man darin alle notwendigen Aktionen durchführen kann. Aber die Entwicklungsumgebung macht viele Dinge unter der Haube und wir verstehen oft nicht, was genau dort passiert ist. Und wenn es kein Verständnis gibt, können Probleme entstehen.

Arbeiten mit Remote-Repositorys

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

• GitHub ist das größte Repository für Repositories und kollaborative Entwicklung. Ich habe es bereits in früheren Artikeln beschrieben.
  Abonnieren Sie mein Github-Konto . Ich stelle dort oft meine Arbeiten in den Bereichen aus, die ich während meiner Arbeit studiere.

• GitLab ist ein webbasiertes Open-Source- DevOps- Lebenszyklus-Tool , das ein Code- Repository- Verwaltungssystem für Git mit einem eigenen Wiki, einem Issue-Tracking-System , einer CI/CD-Pipeline und anderen Funktionen bereitstellt. Nach der Nachricht, dass Microsoft GitHub gekauft hat, duplizierten einige Entwickler ihre Arbeit 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 über kostenlose private Repositories verfügte. 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 Projekt klonen. Für diesen Fall 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

Nun liegt lokal eine vollständige Kopie des Projekts vor. Um sicherzustellen, dass sich die neueste Kopie des Projekts lokal befindet, müssen Sie, wie man sagt, die Daten sichern, indem Sie Folgendes schreiben:

git pull

In unserem Fall hat sich im Entferntesten nichts geändert, daher lautet die Antwort: Bereits auf dem neuesten Stand. Wenn ich jedoch einige Änderungen im Remote-Repository vornehme, wird das lokale aktualisiert, nachdem wir sie abgerufen haben. Und schließlich besteht der letzte Befehl darin, Daten in das Remote-Repository zu übertragen. Wenn wir etwas lokal erledigt haben und es in ein Remote-Repository übertragen möchten, müssen wir zunächst lokal einen neuen Commit erstellen. Dazu fügen wir unserer Textdatei noch etwas hinzu: Jetzt ist es für uns üblich, dass wir ein Commit für diese Angelegenheit erstellen:

git add test_resource.txt
git commit -m “prepated txt for pushing”

Und jetzt der Befehl, um dies in das Remote-Repository zu übertragen:

git push

Das ist alles, was ich dir sagen wollte. Vielen Dank für Ihre Aufmerksamkeit. Abonnieren Sie mein GitHub-Konto , wo ich verschiedene coole Beispielprojekte aus dem, was ich studiere und bei der Arbeit verwende, poste.

Nützliche Links

• Das offizielle Dokument zu Git ist auf Russisch . Ich empfehle es als Nachschlagewerk.
• Git