Git-Tutorial: Repository auf GitHub oder GitLab anlegen und klonen

Eine nützliche Erinnerung vorweg, ausführlich in der Einführung zum Tutorial: Git läuft auf deinem Rechner, GitHub und GitLab sind nur Hoster für Git-Repositories.

Es gibt zwei Wege zu einem Projekt, das unter Git steht und mit GitHub oder GitLab verbunden ist, und welcher es wird, hängt allein davon ab, was zuerst existiert. Entweder das Remote-Repository ist schon da und du holst es dir: das ist klonen. Oder du hast einen Ordner auf deinem Rechner und veröffentlichst ihn: das ist initialisieren und pushen. Dieses Kapitel behandelt beide Fälle.

Das Remote-Repository anlegen

Bei GitHub die Schaltfläche New auf der Startseite oder die Adresse github.com/new. Bei GitLab New project, dann Create blank project.

Beim Anlegen sind drei Entscheidungen zu treffen.

Der Name. Er wird Teil der URL des Repositorys. Nimm Kleinbuchstaben und Bindestriche, ohne Umlaute und ohne Leerzeichen.

Die Sichtbarkeit. Öffentlich heißt für jeden lesbar, samt vollständiger Historie und damit allem, was du versehentlich committet hast. Privat beschränkt den Zugriff auf die Personen, die du einlädst. Im Zweifel fang privat an: von privat auf öffentlich zu wechseln geht sofort, umgekehrt verschwindet nicht, was bereits kopiert wurde.

Die Datei README. Setz das Häkchen nur, wenn du das Repository klonen willst. Hast du bereits einen Ordner zum Veröffentlichen, lass das Repository völlig leer, sonst musst du hinterher zwei Historien zusammenführen, die nichts gemeinsam haben.

SSH-Adresse oder HTTPS-Adresse

Sobald das Repository angelegt ist, bietet die Seite dir die URL in zwei Formen an. Beide zeigen auf dasselbe Repository und unterscheiden sich nur in der Art der Authentifizierung.

Achte auf den Unterschied in der Schreibweise: Die SSH-Adresse setzt einen Doppelpunkt hinter den Hostnamen, keinen Schrägstrich. Und vor allem wechselt die Domain je nach Dienst. Eine github.com-URL für ein Projekt anzugeben, das bei GitLab liegt, ist ein klassischer Copy-and-paste-Fehler.

Hast du im vorigen Kapitel einen SSH-Schlüssel hinterlegt, nimm die SSH-Adresse: Du wirst nie wieder nach etwas gefragt. Die HTTPS-Adresse verlangt ein persönliches Access Token, das der Credential-Manager speichern kann.

Erster Fall: Das Repository existiert, du klonst es

Das ist die Lage, wenn du zu einem Projekt dazustößt oder das Repository mit einem README angelegt hast.

git clone git@github.com:utilisateur/projet.git

Git legt im aktuellen Verzeichnis einen Ordner projet an, lädt die vollständige Historie hinein und trägt das Remote-Repository unter dem Namen origin ein. Für einen anderen Ordnernamen hängst du ihn als zweites Argument an:

git clone git@github.com:utilisateur/projet.git mon-dossier

Prüf nach, was dabei herausgekommen ist:

cd projet
git remote -v
git branch --show-current

origin	https://github.com/git/git.git (fetch)
origin	https://github.com/git/git.git (push)
master

Zwei Anmerkungen zu dieser Ausgabe. origin steht zweimal da, weil Git die Adresse zum Lesen von der zum Schreiben trennt, fast immer sind beide gleich. Und der Branch heißt hier master, weil das der Standard-Branch des geklonten Repositorys ist: Beim Klonen übernimmt Git den Namen vom Server und ignoriert deine Einstellung init.defaultBranch vollständig – sie gilt nur für Repositories, die du selbst anlegst.

Zweiter Fall: Der Ordner existiert, du veröffentlichst ihn

Das ist die Lage, wenn du zu arbeiten angefangen hast, bevor du an Git gedacht hast. Wechsle in den Projektordner.

cd ~/projets/ma-boutique
git init

Initialized empty Git repository in /root/a2/.git/

Git hat gerade einen Unterordner .git angelegt, der die gesamte Historie enthält. Ihn zu löschen hieße, die Versionierung zu löschen, deine übrigen Dateien bleiben unangetastet.

Halte anschließend einen ersten Commit fest, sonst gibt es nichts zu veröffentlichen:

git add .
git commit -m "Premier commit"

Jetzt trägst du das Remote-Repository ein und pushst:

git remote add origin git@github.com:utilisateur/ma-boutique.git
git branch -M main
git push -u origin main

Diese drei Zeilen sind eine Erklärung wert, denn sie werden oft abgeschrieben, ohne verstanden zu werden.

git remote add origin verknüpft den Kurznamen origin mit der URL des Repositorys. An origin ist nichts magisch, es ist eine Konvention, du könntest es anders nennen, es macht nur niemand.

git branch -M main benennt den aktuellen Branch in main um. Das große -M erzwingt die Umbenennung, selbst wenn es schon einen Branch main gibt. Wer init.defaultBranch im vorigen Kapitel gesetzt hat, braucht die Zeile nicht, sie schadet aber auch nicht.

git push -u origin main schickt den Branch hoch und merkt sich dank -u die Verbindung zwischen deinem lokalen Branch und dem auf dem Server. Genau diese Verbindung erlaubt es, später nur noch git push und git pull zu schreiben. Ohne sie stoppt Git dich:

fatal: No configured push destination.
Either specify the URL from the command-line or configure a remote repository using

    git remote add <name> <url>

and then push using the remote name

    git push <name>

To push to multiple remotes at once, configure a remote group using

    git config remotes.<groupname> "<remote1> <remote2>"

and then push using the group name

    git push <groupname>

Die Falle des angehakten README

Hast du das Remote-Repository mit einem README angelegt, während dein lokaler Ordner schon Commits hatte, besitzt jede Seite ihren eigenen ersten Commit, ohne gemeinsamen Vorfahren. Git weigert sich dann, beide zusammenzuführen:

fatal: refusing to merge unrelated histories

Die Lösung besteht darin, es einmalig ausdrücklich anzufordern:

git pull origin main --allow-unrelated-histories

Merge made by the 'ort' strategy.
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

Ein Merge-Commit führt die beiden Historien zusammen, und das README landet bei deinen Dateien. Danach kannst du ganz normal pushen.

Remote-Repositories verwalten

Ein paar Befehle, die du für später kennen solltest.

git remote -v                                    # Remotes auflisten
git remote set-url origin git@github.com:u/p.git # URL ändern, zum Beispiel von HTTPS auf SSH wechseln
git remote rename origin upstream                # umbenennen
git remote remove origin                         # entfernen

git remote set-url ist der Befehl, den du dir merken solltest: Er repariert ein per HTTPS geklontes Repository, das du auf SSH umstellen willst, ohne alles neu zu klonen.

Ein lokales Repository kommt ohne Server aus

Nichts zwingt dich zu veröffentlichen. Ein git init mit anschließenden Commits funktioniert bestens in einem Ordner, der deinen Rechner nie verlässt, und du hast damit schon die Historie und die Möglichkeit, zurückzugehen. Das Remote-Repository bringt drei Dinge: eine Sicherung außerhalb deiner Festplatte, einen Ort zum Teilen mit anderen und Zugang zu den Werkzeugen des Hosters.

Dein Projekt steht. Das nächste Kapitel geht zu den Befehlen der täglichen Arbeit über und dazu, wie du einen Fehler rückgängig machst.