GitHub ist eine Online-Plattform, auf der Softwareprojekte und deren Dateien gespeichert und gemeinsam verwaltet werden können.

Die Grundlage dafür bildet das Versionsverwaltungssystem Git. Git zeichnet Änderungen an Dateien auf. GitHub stellt diese Git-Projekte online bereit und ergänzt sie um weitere Funktionen für Verwaltung, Zusammenarbeit und Dokumentation.

Ein auf GitHub gespeichertes Projekt wird als Repository bezeichnet.

Für mich ist GitHub noch Neuland. Diese Seite dokumentiert deshalb meinen Einstieg, die wichtigsten Grundlagen und vor allem die Dinge, die ich bei meiner eigenen Arbeit tatsächlich kennenlerne und nutze.

Nein. Git und GitHub gehören zusammen, sind aber nicht dasselbe.

Git ist ein Versionsverwaltungssystem. Es läuft auf meinem Rechner und kann Änderungen an Dateien eines Projekts nachvollziehen und speichern.

GitHub ist eine Online-Plattform, auf der Git-Repositories gespeichert werden können. Dadurch kann ich mein lokales Git-Projekt zusätzlich online ablegen und beispielsweise von anderen Rechnern darauf zugreifen oder mit anderen daran arbeiten.

Vereinfacht kann ich mir den Unterschied so merken:

Git     → Versionsverwaltung auf meinem Rechner
GitHub  → Plattform für meine Git-Repositories im Internet

Git funktioniert auch ohne GitHub. GitHub baut dagegen auf Git auf.

GitHub ist für mich vor allem im Zusammenhang mit meinen eigenen Entwicklungsprojekten interessant.

Bei TheCruiserBlog nutze ich bereits Git zur Versionsverwaltung. Das Projekt besitzt außerdem ein GitHub-Repository, sodass der lokale Entwicklungsstand zusätzlich auf GitHub gespeichert werden kann.

Bisher habe ich GitHub dabei eher benutzt, ohne mich intensiver damit zu beschäftigen. Jetzt möchte ich verstehen, was dabei eigentlich passiert und wie Git und GitHub zusammenspielen.

Mein Ziel ist nicht, möglichst viele GitHub-Funktionen kennenzulernen. Ich möchte zunächst genau die Funktionen verstehen und dokumentieren, die ich für meine eigenen Projekte tatsächlich benötige.

Auf meinem Rechner befindet sich zunächst das eigentliche Projekt mit seinen Dateien.

Git verwaltet die Änderungen an diesen Dateien lokal. Bestimmte Arbeitsstände kann ich als sogenannten Commit festhalten.

Ein GitHub-Repository ist die Online-Gegenstelle zu meinem lokalen Git-Repository. Beide können miteinander verbunden werden.

Das Grundprinzip kann ich mir zunächst so vorstellen:

Projektdateien auf meinem Rechner
          ↓
         Git
          ↓
       Commit
          ↓
        Push
          ↓
       GitHub

Mit push übertrage ich meine lokal gespeicherten Änderungen zu GitHub.

Umgekehrt können Änderungen von GitHub auch wieder auf meinen Rechner übernommen werden. Diesen Weg lerne ich später genauer kennen.

GitHub nutze ich im Zusammenhang mit meiner lokalen Entwicklungsumgebung für TheCruiserBlog.

Meine derzeitige Umgebung:

• Betriebssystem: Windows
• Lokale Entwicklungsumgebung: XAMPP
• Projekt: TheCruiserBlog
• Lokales Projektverzeichnis: E:\xampp\htdocs\thecruiserblog
• Versionsverwaltung: Git
• Online-Plattform: GitHub
• Hauptbranch: main

Das lokale Projekt ist bereits als Git-Repository eingerichtet und mit einem Repository auf GitHub verbunden.

Änderungen kann ich lokal mit Git erfassen und anschließend zu GitHub übertragen.

Mein erstes GitHub-Repository gehört zu meinem Projekt TheCruiserBlog.

Das Projekt existiert lokal auf meinem Rechner als Git-Repository und ist mit einem Repository auf GitHub verbunden.

Damit gibt es zwei Seiten meines Projekts:

Lokal auf meinem Rechner
E:\xampp\htdocs\thecruiserblog

        ↕ Git

Repository auf GitHub

Für mich ist zunächst wichtig zu verstehen, wie diese Verbindung eingerichtet ist und wie ich erkennen kann, mit welchem GitHub-Repository mein lokales Projekt verbunden ist.

Die vorhandene Konfiguration untersuche ich deshalb Schritt für Schritt direkt mit Git.

Mit folgendem Befehl kann ich prüfen, mit welchem entfernten Repository mein lokales Git-Repository verbunden ist:

git remote -v

Bei TheCruiserBlog wird das GitHub-Repository unter dem Namen origin geführt.

Die Ausgabe unterscheidet zwei Verwendungsrichtungen:

• fetch → Änderungen vom entfernten Repository abrufen
• push → eigene Änderungen zum entfernten Repository übertragen

In meiner aktuellen Konfiguration zeigen beide auf dasselbe GitHub-Repository.

Der Name origin ist dabei lediglich der lokale Kurzname für dieses entfernte Repository.

Mein lokales Repository verwendet den Branch main.

Ein Branch ist vereinfacht gesagt eine Entwicklungslinie innerhalb eines Git-Repositories.

Für meinen Einstieg arbeite ich zunächst nur mit:

main

main ist die Entwicklungslinie, auf der sich mein aktueller Projektstand befindet.

Später können weitere Branches sinnvoll werden, beispielsweise um Änderungen zunächst getrennt vom Hauptstand zu entwickeln. Für den Einstieg konzentriere ich mich jedoch bewusst nur auf main.

Git und GitHub möchte ich nicht nur theoretisch verstehen. Entscheidend ist für mich, wie beide Werkzeuge in meinen normalen Arbeitsablauf passen.

Dabei möchte ich Schritt für Schritt nachvollziehen:

• welche Dateien Git als geändert erkennt
• wie ich Änderungen für einen Commit vorbereite
• wie ich einen Arbeitsstand als Commit speichere
• wie ich diesen Stand anschließend zu GitHub übertrage
• wie ich kontrollieren kann, ob lokales Repository und GitHub auf demselben Stand sind

Diesen Ablauf dokumentiere ich anhand meiner tatsächlichen Arbeit am Projekt TheCruiserBlog.

Bevor ich mit Git weiterarbeite, kann ich zunächst den aktuellen Zustand meines lokalen Repositories prüfen:

git status

Der Befehl verändert nichts, sondern zeigt mir den aktuellen Git-Status.

Beispiel aus meinem TheCruiserBlog-Repository:

On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

Das bedeutet für meinen aktuellen Stand:

• Ich arbeite auf dem Branch main.
• Mein lokaler Branch hat gegenüber origin/main keine ausstehenden Commits.
• Es gibt momentan nichts zu committen.
• Mein Arbeitsverzeichnis ist sauber.

git status ist damit für mich ein wichtiger Kontrollbefehl: Erst schauen, was Git sieht – dann handeln.

Bei Git und GitHub begegnen mir viele Begriffe, deren Bedeutung am Anfang nicht selbstverständlich ist.

Hier sammle ich nur Begriffe, die mir bei meiner eigenen Arbeit tatsächlich begegnet sind. Die Liste wächst deshalb zusammen mit meiner praktischen Erfahrung.

• Repository → ein von Git verwaltetes Projekt mit seiner Versionsgeschichte
• Branch → eine Entwicklungslinie innerhalb eines Repositories
• main → der Hauptbranch meines aktuellen Projekts
• Remote → ein entferntes Repository, mit dem mein lokales Repository verbunden ist
• origin → der lokale Kurzname für mein verbundenes GitHub-Repository
• Commit → ein mit Git gespeicherter Arbeitsstand
• Push → lokale Commits zum entfernten Repository übertragen
• Fetch → Informationen und Änderungen vom entfernten Repository abrufen
• Working Tree → die aktuell ausgecheckten Projektdateien, an denen ich lokal arbeite