Git vs GitHub - Was ist Versionskontrolle und wie funktioniert sie?

Warst du jemals verwirrt darüber, wie Git und GitHub funktionieren? Ärgern Sie sich nicht - Sie sind nicht allein. Git und GitHub können manchmal schwierig sein, aber am Ende dieses Beitrags haben Sie einen guten Überblick über die beiden.

Zunächst mag es verlockend sein zu glauben, dass Git und GitHub dasselbe sind. In Wirklichkeit sind sie es aber nicht. In der Tat ist es möglich, Git ohne GitHub zu verwenden! Und letztendlich existieren die beiden für unterschiedliche Zwecke.

Dieser Beitrag beginnt mit einem guten Blick auf die Zwecke von Git und GitHub. Anschließend lernen wir die Hauptunterschiede zwischen diesen beiden wichtigen Technologien kennen.

Lassen Sie uns ohne weiteres mit Git beginnen.

Was ist Git?

Git ist ein verteiltes Versionskontrollsystem (DVCS), mit dem verschiedene Versionen einer Datei (oder einer Reihe von Dateien) gespeichert werden, sodass jede Version nach Belieben abgerufen werden kann.

Git macht es auch einfach, verschiedene Dateiversionen aufzuzeichnen und zu vergleichen. Dies bedeutet, dass die Details darüber, was sich geändert hat, wer was geändert hat oder wer ein Problem initiiert hat, jederzeit überprüfbar sind.

Aber wenn Git ein verteiltes Versionskontrollsystem ist, was genau bedeuten diese Begriffe?

Was bedeutet "verteilt"?

Der Begriff „verteilt“ bedeutet, dass Git nicht nur die neueste Dateiversion freigibt, wenn Sie Git anweisen, das Verzeichnis eines Projekts freizugeben. Stattdessen verteilt es jede Version, die es für dieses Projekt aufgezeichnet hat.

Dieses "verteilte" System steht in scharfem Kontrast zu anderen Versionskontrollsystemen. Sie teilen nur die einzelne Version, die ein Benutzer explizit aus der zentralen / lokalen Datenbank ausgecheckt hat.

Okay, "verteilt" bedeutet also, alle - nicht nur einige ausgewählte - Versionen der von Git aufgezeichneten Projektdateien zu verteilen . Aber was genau ist ein Versionskontrollsystem?

Was ist ein Versionskontrollsystem?

Ein Versionskontrollsystem (VCS) bezieht sich auf die Methode , mit der die Versionen einer Datei zum späteren Nachschlagen gespeichert werden.

Intuitiv, viele Menschen bereits die Versionskontrolle ihrer Projekte durch die Umbenennung verschiedene Versionen der gleichen Datei auf verschiedene Weise wie blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, und so weiter. Dieser Ansatz ist jedoch fehleranfällig und für Teamprojekte ineffektiv.

Mit diesem traditionellen Ansatz ist es auch mühsam zu verfolgen, was sich geändert hat, wer es geändert hat und warum es geändert wurde. Dies unterstreicht die Bedeutung eines zuverlässigen und kollaborativen Versionskontrollsystems wie Git.

Um das Beste aus Git herauszuholen, ist es jedoch wichtig zu verstehen, wie Git mit Ihren Dateien umgeht.

Dateistatus in Git

In Git gibt es drei primäre Zustände (Bedingungen), in denen eine Datei sein kann: geänderter Zustand , bereitgestellter Zustand oder festgeschriebener Zustand .

Geänderter Zustand

Eine Datei im geänderten Zustand ist eine überarbeitete, aber nicht festgeschriebene (nicht aufgezeichnete) Datei.

Mit anderen Worten, Dateien im geänderten Zustand sind Dateien, die Sie geändert haben, die Git jedoch nicht ausdrücklich zur Überwachung angewiesen haben.

Inszenierter Zustand

Dateien im bereitgestellten Status sind geänderte Dateien, die ausgewählt wurden - in ihrem aktuellen Status (Version) - und die darauf vorbereitet sind, .gitbeim nächsten Commit-Snapshot im Repository gespeichert (festgeschrieben) zu werden .

Sobald eine Datei bereitgestellt wird, bedeutet dies, dass Sie Git ausdrücklich autorisiert haben, die Version dieser Datei zu überwachen.

Festgeschriebener Zustand

Dateien im festgeschriebenen Zustand sind Dateien, die erfolgreich im .gitRepository gespeichert wurden .

Eine festgeschriebene Datei ist also eine Datei, in der Sie ihre bereitgestellte Version im Git-Verzeichnis (Ordner) aufgezeichnet haben.

Hinweis: Der Status einer Datei bestimmt den Speicherort, an dem Git sie ablegt.

Dateispeicherorte

Es gibt drei wichtige Stellen, an denen sich Versionen einer Datei während der Versionskontrolle mit Git befinden können: das Arbeitsverzeichnis , der Staging-Bereich oder das Git-Verzeichnis .

Arbeitsverzeichnis

Das Arbeitsverzeichnis ist ein lokaler Ordner für die Dateien eines Projekts. Dies bedeutet, dass jeder Ordner, der irgendwo auf einem System erstellt wird, ein Arbeitsverzeichnis ist.

Hinweis:

  • Dateien im geänderten Zustand befinden sich im Arbeitsverzeichnis.
  • Das Arbeitsverzeichnis unterscheidet sich vom .gitVerzeichnis. Das heißt, Sie erstellen ein Arbeitsverzeichnis, während Git ein .gitVerzeichnis erstellt.
  • In diesem Vergleichsartikel finden Sie weitere Unterschiede zwischen den beiden Repositorys.

Bühnenbereich

Der Staging-Bereich - im Git-Sprachgebrauch technisch als „Index“ bezeichnet - ist eine Datei, die sich normalerweise im .gitVerzeichnis befindet und Informationen zu Dateien enthält, die als nächstes in das .gitVerzeichnis übernommen werden sollen.

Hinweis:

  • Dateien im bereitgestellten Zustand befinden sich im Bereitstellungsbereich.

Git-Verzeichnis

Das .gitVerzeichnis ist der Ordner (auch als "Repository" bezeichnet), den Git in dem Arbeitsverzeichnis erstellt, zu dessen Verfolgung Sie es angewiesen haben.

In dem .gitOrdner speichert Git auch die Objektdatenbanken und Metadaten der Datei (en), deren Überwachung Sie angewiesen haben.

Hinweis:

  • Das .gitVerzeichnis ist das Leben von Git - es ist das Element, das kopiert wird, wenn Sie ein Repository von einem anderen Computer (oder von einer Online-Plattform wie GitHub) klonen.
  • Dateien im festgeschriebenen Zustand befinden sich im Git-Verzeichnis.

Der grundlegende Git-Workflow

Die Arbeit mit dem Git-Versionskontrollsystem sieht ungefähr so ​​aus:

Git grundlegendes Workflow-Diagramm
  1. Ändern Sie die Dateien im Arbeitsverzeichnis.

    Beachten Sie, dass jede Datei, die Sie ändern, zu einer Datei im geänderten Zustand wird .

  2. Stellen Sie die Dateien, die Sie in das .gitVerzeichnis übertragen möchten, selektiv bereit .

    Beachten Sie, dass jede Datei, die Sie in den Staging-Bereich stellen (hinzufügen), zu einer Datei im Staged-Status wird .

    Beachten Sie außerdem, dass sich bereitgestellte Dateien noch nicht in der .gitDatenbank befinden.

    Staging bedeutet, dass Informationen über die bereitgestellte Datei in eine Datei ("Index" genannt) im .gitRepository aufgenommen werden.

  3. Übernehmen Sie die von Ihnen bereitgestellten Dateien in das .gitVerzeichnis. Speichern Sie also dauerhaft einen Snapshot der bereitgestellten Datei (en) in der .gitDatenbank.

    Beachten Sie, dass jede Dateiversion, die Sie in das .gitVerzeichnis festschreiben, zu einer Datei im festgeschriebenen Zustand wird .

Das Wesentliche bisher

Das lange und kurze an der bisherigen Diskussion ist, dass Git ein brillantes Versionskontrollsystem für die kompetente Versionierung, Verwaltung und Verteilung von Dateien ist. In dieser einfachen Anleitung erfahren Sie, wie Sie Git effizient einsetzen.

Aber Moment mal, wenn Git dabei hilft, verschiedene Versionen der Projektdatei effektiv zu verwalten und zu verteilen, was ist der Zweck von GitHub?

GitHub entmystifiziert

GitHub ist eine webbasierte Plattform, auf der Benutzer Git-Repositorys hosten können. Es hilft Ihnen, das Teilen und die Zusammenarbeit bei Projekten jederzeit mit jedem zu vereinfachen.

GitHub fördert auch eine breitere Teilnahme an Open-Source-Projekten, indem es eine sichere Möglichkeit bietet, Dateien im Repository eines anderen Benutzers zu bearbeiten.

Führen Sie die folgenden Schritte aus, um ein Git-Repository auf GitHub zu hosten (oder freizugeben):

Schritt 1: Registrieren Sie sich für ein GitHub-Konto

Der erste Schritt, um mit dem Hosting auf GitHub zu beginnen, besteht darin, ein persönliches Konto zu erstellen. Besuchen Sie die offizielle Registrierungsseite, um sich anzumelden.

Schritt 2: Erstellen Sie ein Remote-Repository in GitHub

Erstellen Sie nach der Anmeldung für ein Konto in GitHub ein Home (ein Repository) für das Git-Repository, das Sie freigeben möchten.

Schritt 3: Verbinden Sie das Git-Verzeichnis des Projekts mit dem Remote-Repository

Wenn Sie ein Remote-Repository für Ihr Projekt erstellt haben, verknüpfen Sie das Projektverzeichnis .git- das sich lokal auf Ihrem System befindet - mit dem Remote-Repository auf GitHub.

Um eine Verbindung zum Remote-Repository herzustellen, gehen Sie in das Stammverzeichnis des Projekts, das Sie über Ihr lokales Terminal freigeben möchten, und führen Sie Folgendes aus:

git remote add origin //github.com/yourusername/yourreponame.git

Hinweis:

  • Ersetzen Sie yourusernameden obigen Code durch Ihren GitHub-Benutzernamen.

    Ersetzen Sie ihn ebenfalls yourreponamedurch den Namen des Remote-Repositorys, zu dem Sie eine Verbindung herstellen möchten.

  • Der obige Befehl impliziert, dass git die angegebene URL zum lokalen Projekt als Remote-Referenz hinzufügen sollte , mit der das lokale Verzeichnis interagieren kann..git
  • Die originOption im obigen Befehl ist der Standardname (ein Kurzname), den Git dem Server gibt, auf dem sich Ihr Remote-Repository befindet.

    Das heißt, anstelle der URL des Servers verwendet Git den Kurznamen origin.

  • Es ist nicht obligatorisch, sich an den Standardnamen des Servers zu halten. Wenn Sie einen anderen Namen bevorzugen origin, ersetzen Sie einfach den originNamen im git remote addobigen Befehl durch einen beliebigen Namen.
  • Denken Sie immer daran, dass der Kurzname eines Servers (zum Beispiel   origin) nichts Besonderes ist! Es ist nur lokal vorhanden, damit Sie leicht auf die URL des Servers verweisen können. Ändern Sie es also in einen Kurznamen, auf den Sie leicht verweisen können.
  • Verwenden Sie den folgenden git remote renameBefehl, um eine vorhandene Remote-URL umzubenennen :
git remote rename theCurrentURLName yourNewURLName
  • Immer wenn Sie ein Remote-Repo klonen (herunterladen), benennt Git automatisch die URL dieses Repos origin. Sie können jedoch mit dem git clone -o yourPreferredNameBefehl einen anderen Namen angeben .
  • originFühren Sie den git remote -vBefehl aus, um die genaue URL anzuzeigen, die für Spitznamen wie gespeichert ist .

Schritt 4: Bestätigen Sie die Verbindung

Nachdem Sie Ihr Git-Verzeichnis mit dem Remote-Repository verbunden haben, überprüfen Sie git remote -vanhand der Befehlszeile , ob die Verbindung erfolgreich war .

Überprüfen Sie anschließend die Ausgabe, um sicherzustellen, dass die angezeigte URL mit der Remote-URL übereinstimmt, zu der Sie eine Verbindung herstellen möchten.

Hinweis:

  • Lesen Sie den Artikel „Herstellen einer Verbindung mit SSH“, wenn Sie eine Verbindung über die SSH-URL anstelle der HTTPS-URL herstellen möchten.
  • Wenn Sie sich jedoch nicht sicher sind, welche Remote-URL verwendet werden soll, lesen Sie „Welche Remote-URL soll ich verwenden?“. Artikel.
  • Möchten Sie Ihre Remote-URL ändern? Das Ändern der URL einer Fernbedienung ist eine hervorragende Anleitung.

Schritt 5: Schieben Sie ein lokales Git-Repo auf das Remote-Repo

Nachdem Sie Ihr lokales Verzeichnis erfolgreich mit dem Remote-Repository verbunden haben, können Sie beginnen, Ihr lokales Projekt in den Upstream zu verschieben (hochzuladen).

Wenn Sie bereit sind, Ihr Projekt an einem anderen Ort auf einem Remote-Repo freizugeben, weisen Sie Git einfach an, alle Ihre Commits, Zweige und Dateien in Ihrem lokalen .gitVerzeichnis in das Remote-Repository zu übertragen.

Die Codesyntax zum Hochladen (Push) eines lokalen Git-Verzeichnisses in ein Remote-Repository lautet git push -u remoteName branchName.

.gitFühren Sie Folgendes aus , um Ihr lokales Verzeichnis zu verschieben und anzunehmen, dass der Kurzname der Remote-URL "Ursprung" lautet:

git push -u origin master

Hinweis:

  • Der obige Befehl bedeutet , dass git sollte schieben Sie Ihren lokalen Master - Zweig an den Remote - Master Zweig an der URL genannt befindet Ursprung .
  • Technisch gesehen können Sie die originOption durch die URL des Remote-Repositorys ersetzen . Denken Sie daran, dass die originOption nur ein Spitzname der URL ist, die Sie in Ihrem lokalen .gitVerzeichnis registriert haben .
  • Das -uFlag (Upstream- / Tracking-Referenzflag) verbindet automatisch den .gitlokalen Zweig des Verzeichnisses mit dem Remote-Zweig. Auf diese Weise können Sie git pullohne Argumente verwenden.

Schritt 6: Bestätigen Sie den Upload

Zuletzt kehren Sie zu Ihrer GitHub-Repository-Seite zurück, um zu bestätigen, dass Git Ihr lokales Git-Verzeichnis erfolgreich in das Remote-Repository verschoben hat.

Hinweis:

  • Möglicherweise müssen Sie die Seite des Remote-Repositorys aktualisieren, damit die Änderungen übernommen werden.
  • GitHub bietet außerdem eine kostenlose optionale Funktion zum Konvertieren Ihres Remote-Repositorys in eine funktionierende Website. Lassen Sie uns unten sehen, wie.

Veröffentlichen Sie Ihre Website mit GitHub-Seiten

Nachdem Sie Ihr Projekt in Ihr Remote-Repository verschoben haben, können Sie es einfach wie folgt im Web veröffentlichen:

  1. Stellen Sie sicher, dass der Name der Haupt-HTML-Datei Ihres Projekts lautet index.html.
  2. Gehen Sie auf der Website-Plattform von GitHub in das Repository des Projekts, das Sie veröffentlichen möchten, und klicken Sie auf die Registerkarte Einstellungen des Repositorys .
  3. Scrollen Sie zum Abschnitt GitHub Pages und ändern Sie den Quellzweig von none in master .
  4. Anschließend wird eine Benachrichtigung mit dem Titel "Ihre Website wird unter //Ihr-Benutzername.github.io/Ihr-Github-Repo-Name/ veröffentlicht " angezeigt.
  5. Jetzt können Sie Ihr Projekt unter der angegebenen URL anzeigen und veröffentlichen.

Dieser Abschnitt hat lediglich die Oberfläche der Veröffentlichung Ihres Projekts mit GitHub zerkratzt. Weitere Informationen zu GitHub-Seiten finden Sie in der Dokumentation „Arbeiten mit GitHub-Seiten“.

Zusamenfassend

GitHub ist eine Online-Plattform zum Hosten (oder Teilen) von Git-Repositorys. Es hilft Ihnen dabei, eine Möglichkeit zu schaffen, bei Projekten einfach mit jedem zusammenzuarbeiten, an jedem Ort und zu jeder Zeit.

Immer noch im Zweifel?

Sind Sie immer noch ratlos über die feine Linie zwischen Git und GitHub? Mach dir keine Sorgen - ich habe dich gedeckt. Nachfolgend sind fünf Hauptunterschiede zwischen Git und GitHub aufgeführt.

Unterschied 1: Git vs. GitHub - Primäre Funktion

Git ist ein verteiltes Versionskontrollsystem, das verschiedene Versionen einer Datei (oder einer Reihe von Dateien) aufzeichnet. Benutzer können jederzeit auf die aufgezeichneten Versionen zugreifen, diese vergleichen, aktualisieren und verteilen.

Allerdings GitHub ist in erster Linie eine Hosting - Plattform für Endlager Online - Git - Hosting. Damit können Benutzer ihr Remote-Repository privat oder für gemeinsame Zwecke offen halten.

Unterschied 2: Git vs. GitHub - Operationsplattform

Benutzer installieren und betreiben Git auf ihren lokalen Computern. Dies bedeutet, dass die meisten Operationen von Git ohne das Internet erreichbar sind.

GitHub ist jedoch ein webbasierter Dienst, der ausschließlich online betrieben wird. Dies bedeutet, dass Sie das Internet benötigen, um etwas auf GitHub zu tun.

Unterschied 3: Git vs. GitHub - Erfinder

Linus Torvalds begann im April 2005 mit der Entwicklung von Git.

Chris Wanstrath, PJ Hyett, Tom Preston-Werner und Scott Chacon gründeten GitHub.com im Februar 2008.

Unterschied 4: Git vs. GitHub - Maintainer

Im Juli 2005 übergab Linus Torvalds die Wartung von Git an Junio ​​C. Hamano, der seitdem der Hauptbetreuer ist.

Und Microsoft hat GitHub im Oktober 2018 übernommen.

Unterschied 5: Git vs. GitHub - Konkurrenten

Beliebte Alternativen zu Git sind Mercurial, TFVC (Team Foundation Version Control), Perforce Helix Core, Apache Subversion und IBM Rational ClearCase.

Die engsten Konkurrenten von GitHub sind GitLab, Bitbucket, SourceForge, Cloud Source Repositories und AWS CodeCommit.

Alles in allem

Git und GitHub sind zwei verschiedene Entitäten, mit denen Sie Dateien verwalten und hosten können. Mit anderen Worten, Git dient zur Steuerung von Dateiversionen, während GitHub eine Plattform zum Hosten von Git-Repositorys ist.

Nützliche Ressource

  • Wie man Git benutzt - Eine atemberaubende Anleitung mit tollen Tipps