Git-Repository erstellen: git init und Remote einrichten

Ein Git-Repository ist ein Projekt, dessen Änderungen Git verfolgt. Physisch ist das ein ganz normaler Ordner mit Ihren Dateien plus dem versteckten Verzeichnis .git, in dem die gesamte Historie liegt: Commits, Branches, Tags, Einstellungen. Löschen Sie .git, bleiben nur noch die Dateien übrig – ohne eine einzige frühere Version.

Woraus ein Git-Repository besteht

Bei der Arbeit mit Git hilft es, drei Bereiche im Kopf zu behalten, zwischen denen Änderungen wandern:

• Arbeitsverzeichnis (Working Tree) – die Dateien, die Sie sehen und bearbeiten;
• Index (Staging Area) – der Entwurf des nächsten Commits, in den Änderungen per git add gelangen;
• Historie – die Commit-Datenbank in .git, in die Änderungen per git commit gelangen.

Genau genommen ist das Repository selbst der Inhalt von .git. Das Arbeitsverzeichnis ist nur eine „ausgecheckte“ Version des Projekts, die Git aus der Historie holt.

Git-Repository mit git init erstellen

Wechseln Sie in den Projektordner und führen Sie einen einzigen Befehl aus:

cd ~/projects/my-app
git init

Initialized empty Git repository in /home/user/projects/my-app/.git/

Sie können ein Repository sowohl in einem leeren Ordner anlegen als auch in einem, in dem bereits Dateien liegen. Im zweiten Fall geht nichts verloren: Die vorhandenen Dateien sind einfach so lange untracked, bis Sie sie mit git add hinzufügen.

Nützliche Varianten des Befehls:

# Ordner anlegen und darin direkt ein Repository erstellen
git init my-app

# Namen des ersten Branches festlegen (sonst master oder Wert aus der Konfiguration)
git init -b main

# main als Standard-Branch für alle neuen Repositories setzen
git config --global init.defaultBranch main

Der erste Commit

Ein leeres Repository ohne Commits ist praktisch nutzlos. Direkt nach git init geht man üblicherweise so vor:

git config --global user.name "Max Mustermann"
git config --global user.email "max@example.com"

git status
git add .
git commit -m "Initiale Projektstruktur"

Name und E-Mail müssen Sie nur einmal pro Rechner setzen – sie landen in jedem Commit. Ohne diese Angaben verweigert Git den Commit und bittet Sie, sich vorzustellen.

Legen Sie sofort eine .gitignore an

Erstellen Sie noch vor dem ersten git add . eine Datei .gitignore mit allem, was nicht ins Repository gehört: Abhängigkeiten, Build-Artefakte, Secrets, IDE-Dateien.

node_modules/
dist/
.env
.idea/
.vscode/
*.log
__pycache__/

Ist eine Datei bereits committet, entfernt .gitignore sie nicht. Sie müssen die Datei aus dem Tracking nehmen und sie dabei auf der Platte behalten: git rm --cached .env, danach committen.

Was steckt im Ordner .git?

Im Alltag müssen Sie dort nicht hineinschauen, aber wer die Struktur kennt, hat viele Fragen gar nicht erst:

Daraus folgt etwas Wichtiges: Ein Branch in Git ist eine winzige Datei mit einem einzigen Hash. Deshalb ist das Anlegen von Branches sofort erledigt und kostet nichts.

Prüfen, ob ein Ordner ein Git-Repository ist

git status
# oder genauer
git rev-parse --is-inside-work-tree

Außerhalb eines Repositorys erhalten Sie fatal: not a git repository (or any of the parent directories): .git. Beachten Sie das „parent directories“: Git sucht .git den Verzeichnisbaum aufwärts. Wenn Sie versehentlich git init in Ihrem Home-Verzeichnis ausführen, wird das komplette Home-Verzeichnis zum Repository – diesen .git-Ordner sollten Sie dann löschen.

Lokales und entferntes Repository

Ein per git init angelegtes Repository existiert nur auf Ihrem Rechner. Um Code zu teilen und ein Backup zu haben, verbinden Sie es mit einem Remote-Repository – einer Kopie auf einem Server: GitHub, GitLab, Bitbucket oder ein eigener Git-Server.

Aus Sicht von Git ist das Remote-Repository nicht das „Haupt-Repository“: Jede Kopie ist vollwertig und enthält die komplette Historie. Zentral wird es nur durch die Absprache im Team.

git remote: Remote-Repository verbinden

Ein Remote ist ein Kurzname für eine Serveradresse. Der Standardname ist per Konvention origin.

# Remote hinzufügen
git remote add origin git@github.com:username/my-app.git

# Liste mit Adressen anzeigen
git remote -v

origin  git@github.com:username/my-app.git (fetch)
origin  git@github.com:username/my-app.git (push)

Pushen Sie anschließend den Branch und verknüpfen Sie ihn mit dem Remote-Branch:

git push -u origin main

Die wichtigsten git-remote-Befehle

Adressformate

• https://github.com/user/repo.git – HTTPS, funktioniert überall, für Schreibzugriff brauchen Sie ein Token;
• git@github.com:user/repo.git – SSH, erfordert einen Schlüssel, nach der Einrichtung fragt niemand mehr nach Passwörtern;
• /srv/git/repo.git oder file:///srv/git/repo.git – lokaler Pfad, praktisch für Experimente.

Typische Fehlermeldungen

„error: remote origin already exists“. Ein Remote mit diesem Namen gibt es schon. Wenn Sie die Adresse ändern wollen, nutzen Sie git remote set-url origin <url> statt eines erneuten add.

„failed to push some refs“ / „Updates were rejected“. Auf dem Server liegen Commits, die Sie lokal nicht haben – oft eine README, die beim Anlegen des Repositorys auf der Website erzeugt wurde. Führen Sie git pull --rebase origin main aus und pushen Sie erneut. Sind die Historien völlig unabhängig, antwortet Git mit „refusing to merge unrelated histories“ – dann braucht git pull das Flag --allow-unrelated-histories. Einfacher ist es, das Repository auf der Website leer anzulegen.

„src refspec main does not match any“. Sie versuchen, einen Branch zu pushen, den es nicht gibt: Entweder existiert noch kein einziger Commit, oder der Branch heißt master. Prüfen Sie das mit git branch.

Eigener Git-Server: das Bare-Repository

GitHub ist kein Muss. Als Remote-Repository taugt jede Maschine, auf die Sie SSH-Zugriff haben. Dafür legt man auf dem Server ein „nacktes“ (bare) Repository an – ohne Arbeitsverzeichnis, nur mit dem Inhalt von .git:

# Auf dem Server
ssh user@server
git init --bare /srv/git/my-app.git

# Auf Ihrem Rechner
git remote add origin user@server:/srv/git/my-app.git
git push -u origin main

Um zu dritt mit so einem Server zu arbeiten, genügt es, den Kollegen SSH-Zugriff auf den Repository-Ordner und eine gemeinsame Gruppe mit Schreibrechten zu geben. Für Berechtigungen pro Branch oder Projekt reicht das nicht mehr – dann brauchen Sie ein vollwertiges Git-Hosting.

In einem Bare-Repository können Sie nicht „schnell eine Datei korrigieren“ – es ist ausschließlich für den Austausch per push und fetch gedacht. Genau so funktionieren die Repositories bei jedem Git-Hoster. Wer Weboberfläche, Code-Reviews und Issues braucht, setzt auf Self-Hosted-Lösungen wie GitLab, Gitea oder Forgejo.

Remote-Tracking-Branches: wie das lokale Repository den Server sieht

Nachdem Sie ein Remote verbunden und erstmals git fetch oder git push ausgeführt haben, tauchen im Repository Remote-Branches wie origin/main auf. Das sind keine Branches auf dem Server, sondern lokale „Schnappschüsse“ dessen, was Sie bei der letzten Synchronisation auf dem Server gesehen haben. Sie werden nur bei fetch, pull und push aktualisiert.

Daraus ergibt sich der wichtige Unterschied zwischen den drei Austausch-Befehlen:

Wie weit Ihr Branch zurückliegt oder voraus ist, sehen Sie so:

git fetch
git status -sb

## main...origin/main [ahead 2, behind 1]

Sie haben hier zwei Commits, die auf dem Server fehlen, und der Server hat einen, der Ihnen fehlt. Vor dem Push müssen Sie diesen Commit zuerst holen.

Die Verknüpfung des lokalen Branches mit dem Remote-Branch (Upstream) setzt das Flag -u beim ersten Push. Falls Sie es vergessen haben, lässt sie sich separat setzen: git branch --set-upstream-to=origin/main. Alle Verknüpfungen zeigt git branch -vv.

Mehrere Repositories: Monorepo oder eines pro Projekt?

Eine häufige Einsteigerfrage: Wie viele Git-Repositories sollte man anlegen? Die einfache Regel: ein Repository pro Einheit, die unabhängig entwickelt und released wird. Lernprojekte, Side-Projects und einzelne Services gehören in getrennte Repositories. Legen Sie kein Repository für Ihren ganzen Ordner „Meine Projekte“ an: Die Historie vermischt sich, und ein einzelnes Projekt separat ins Portfolio zu stellen, wird mühsam.

Große Unternehmen halten manchmal den gesamten Code in einem Monorepo – wegen übergreifender Änderungen und eines einheitlichen Builds. Das ist aber eine bewusste Architekturentscheidung mit eigenem Tooling. Als Einsteiger fahren Sie am besten mit „ein Projekt – ein Repository“ und verschachteln niemals ein Repository in einem anderen ohne Submodules.

git init oder git clone?

Nach git clone ist das Remote origin bereits eingerichtet, Sie müssen es nicht manuell hinzufügen.

Schritt für Schritt: vom Ordner zum Repository auf GitHub

1. Legen Sie den Projektordner an und führen Sie git init -b main aus.
2. Fügen Sie .gitignore und eine README hinzu.
3. Erstellen Sie den ersten Commit: git add . und git commit -m "Initial commit".
4. Legen Sie auf GitHub ein leeres Repository an – ohne README, Lizenz und .gitignore.
5. Verbinden Sie es: git remote add origin <adresse>.
6. Pushen Sie den Code: git push -u origin main.
7. Danach arbeiten Sie im Kreislauf: Änderungen → git add → git commit → git push.

Fazit

Ein Git-Repository ist Ihr Projekt plus der Ordner .git mit der vollständigen Historie. Sie erstellen es mit git init, die Verbindung zum Server richten Sie über git remote add origin und den ersten git push -u ein. Als Remote-Repository dient GitHub, GitLab oder Ihr eigener Git-Server mit Bare-Repository. Das erste Repository, den Index und das Verbinden eines Remotes üben Sie praktisch im Git-Kurs.