git im Team und Remote nutzen

git im Team und Remote nutzen

https://bildung.social/@oerinformatik/110326723919640390

https://oer-informatik.de/git02-remote_nutzen

Versionsverwaltung, git, Remote-Repository, git clone, git fetch, git pull, git push, Zugriffstoken, SSH-Schlüssel, gitignore, GitHub, GitLab

tl/dr; (ca. 20 min Lesezeit): Zugegeben: Die meisten Leute meinen, wenn sie von git reden, eher Plattformen wie GitHub, GitLab oder Bitbucket. Wir sollten diese zentralen Repositories also schleunigst einbinden: klonen, holen, hochladen, anmelden per Token oder SSH-Schlüssel und festlegen, was gar nicht erst ins Repository gehört [AI-Assisted]. (Zuletzt geändert am 12.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über die Versionsverwaltung git: Erste Schritte und lokale Commits / git im Team und Remote nutzen / Versionieren mit Branches / Readme.md-Dateien erstellen / Workflows im Team / Übungsaufgaben

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Bisher lag die gesamte Historie nur auf Deinem Rechner. Im Team braucht es einen gemeinsamen Treffpunkt: ein Remote-Repository, z. B. bei GitHub, GitLab, Bitbucket oder auf einem eigenen Server. Technisch ist es ein gleichberechtigtes git-Repository; jede Arbeitskopie bleibt vollständig. Zwischen den Repositorys tauschst Du Commits mit wenigen Befehlen aus:

Ein lokales Repository erstellen

Zunächst wird ein lokales Repository benötigt, das später mit einem zentralen Repository verknüpft wird. Auf der obersten Ebene des Projektverzeichnisses erzeugen und aktualisieren wir das mit:

$ git init -b main
$ git status      # nochmal kontrollieren: wird alles einbezogen, was einbezogen werden soll? Und ignoriert?
$ git add .
$ git commit -m "Initialisierung des Projekts"

Bevor Du git add . ausführst, solltest Du festlegen, welche Dateien git ignorieren soll (Abschnitt „Ein Projekt aufsetzen“ weiter unten). Was einmal committet und hochgeladen ist, bekommst Du nur mühsam wieder aus der Historie.

Neues zentrales Repository erstellen

Ein zentrales Repository kann über die üblichen Anbieter (z.B. github, bitbucket, gitlab) erstellt werden oder in Form eines bare-Repositorys im Filesystem auf einem Server gespeichert werden. Individuelle Anleitungen hierzu finden sich bei den jeweiligen Anbietern. Hierbei ist die Reihenfolge wichtig: soll ein vorhandenes lokales Repository übernommen werden, so ist wichtig, dass entsprechend ein leeres Remote-Repository erstellt wird. Bei GitHub und GitLab also beim Anlegen kein README, keine Lizenz und keine .gitignore erzeugen lassen; sonst haben beide Repositorys unterschiedliche erste Commits. Ein bare-Repository (ohne Workspace, nur mit dem Inhalt des .git-Ordners) legst Du auf einem Server oder Netzlaufwerk mit git init --bare projekt.git an.

Zentrales Repository lokal als remote einstellen

Verknüpft wird das remote-Repository über den remote-Befehl und eine URL mit Protokollangabe:

$ git remote add origin https://github.com/testuser/testrepo.git

In diesem Beispiel wurde https als Protokoll verwendet. Es ist genauso möglich, per SSH oder file auf ein entferntes Repository zuzugreifen. Gegebenenfalls sind Firewall-Einstellungen und Portfreigaben zu beachten! Konkret: in unserem Schulnetz ist beispielsweise nur der Weg über HTTPS geöffnet, da die Standard-SSH-Ports blockiert werden. Wie Du Dich je nach Protokoll anmeldest, steht im Abschnitt „Anmelden beim Remote“.

Eine weitere eigene Arbeitskopie eines entfernten Repository kopieren

Wenn ein Repository geklont wird, merkt sich das lokale Repository, woher es stammt - das Abbild des entfernten (remote) Repositorys wird origin genannt. Jedes Teammitglied kopiert das Repository per clone auf die lokale Maschine:

$ git clone https://github.com/testuser/testrepo.git

Cloning into 'testrepo'...
done.

git legt einen Ordner testrepo mit Workspace und vollständiger Historie an, trägt origin als Remote ein und checkt den Standard-Branch aus. Ein Branch des origin kann lokal über den Pfad origin/main angesprochen werden. Allerdings verhält es sich anders als ein lokaler Branch: origin/main ist ein Remote-Tracking-Branch, also die lokale Kopie des Standes von main im Remote-Repository beim letzten Abgleich. Du kannst ihn ansehen und mergen, aber nicht direkt auf ihm committen. git branch -a zeigt lokale und Remote-Tracking-Branches zusammen an.

Den aktuellen Stand eines remote-Repositorys auf das lokale übertragen

Die Änderungen des entfernten Repositorys werden mit dem Befehl fetch in das lokale Repository geladen. Es aktualisieren sich also alle Branches unter origin. Deine eigenen Branches und Dein Workspace bleiben unverändert; fetch ist daher immer gefahrlos. Was neu hinzugekommen ist, zeigt danach z. B. git log main..origin/main --oneline.

$ git fetch

Wenn sich das lokale Repository geändert hat, müssen die Änderungen des remote Repositorys noch übernommen werden - mit den Techniken, mit denen Änderungen aus anderen Branches übertragen werden - also je nach Fall: merge, rebase oder cherry-pick. Wie diese Techniken funktionieren, zeigt der nächste Teil Versionieren mit Branches; für den Anfang genügt git pull, das die Änderungen automatisch per merge übernimmt.

$ git merge origin/main

Das Holen der Änderungen aus dem remote-Repository und Übernehmen der Änderungen in den aktuellen Branch kann auch in einem Befehl (pull) erfolgen: git pull entspricht git fetch gefolgt von git merge origin/main. Soll dies per rebase geschehen, lautet der Befehl git pull --rebase.

$ git pull

Ein Remote-Repository klonen und einem neuen Remote-Repository zuweisen

Ein Remote-Repository klonen:

$ git clone https://gitlab.com/beispiel/beispielrepo.git

ggf. das Repository umbenennen

$ mv beispielrepo neuesrepo

in das Verzeichnis wechseln:

$ cd neuesrepo

bisherige remote-Repositories ausgeben:

$ git remote -v

origin  https://gitlab.com/beispiel/beispielrepo.git (fetch)
origin  https://gitlab.com/beispiel/beispielrepo.git (push)

Variante 1: Das alte Remote-Repository soll weiterhin zugreifbar bleiben:

$ git remote rename origin old-origin
$ git remote add origin https://gitlab.com/neuesRepo/neuesRepo.git
$ git push -u origin --all
$ git push -u origin --tags

Variante 2: Das alte Remote-Repository soll ersetzt werden:

$ git remote set-url origin https://gitlab.com/neuesRepo/neuesRepo.git

Überprüfen, ob das geklappt hat mit

$ git remote -v

Den lokalen Stand hochladen: push

Der umgekehrte Weg: Wir wollen unsere lokalen Commits in das Remote-Repository übertragen. Beim ersten Mal muss git noch wissen, mit welchem Remote-Branch der lokale Branch verknüpft werden soll:

$ git push -u origin main

Die Option -u (lang: --set-upstream) verknüpft den lokalen Branch main mit origin/main. Danach genügt ein einfaches git push bzw. git pull. Welche Verknüpfungen bestehen und ob Dein Branch vor oder hinter dem Remote-Stand liegt, zeigt git branch -vv:

* main ad8894a [origin/main: ahead 1] docs: add readme

Haben andere seit Deinem letzten Abgleich etwas hochgeladen, weist das Remote-Repository Deinen Push ab, damit deren Commits nicht verloren gehen:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://github.com/testuser/testrepo.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. [...]

Die Lösung: erst die fremden Commits holen und integrieren, dann erneut pushen.

$ git pull            # oder: git pull --rebase
$ git push

Neuere git-Versionen fragen beim ersten pull mit auseinanderlaufenden Branches nach, ob per Merge oder per Rebase integriert werden soll. Die Entscheidung legst Du einmalig fest: git config --global pull.rebase false (Merge) oder git config --global pull.rebase true (Rebase). Ein Rebase ist hier unbedenklich, weil nur Deine eigenen, noch nicht geteilten Commits neu aufgesetzt werden. Wie Merge und Rebase im Einzelnen arbeiten, erklärt der Artikel Versionieren mit Branches.

Niemals solltest Du auf einem gemeinsam genutzten Branch mit git push --force die Historie im Remote-Repository überschreiben. Für den eigenen Feature-Branch, den Du nach einem Rebase aktualisieren musst, ist git push --force-with-lease die sicherere Variante: Sie bricht ab, falls inzwischen jemand anderes etwas hochgeladen hat.

Weitere nützliche Varianten, die Du spätestens brauchst, wenn Du mit Branches und mit Tags (festen Versionsmarken wie v1.0.0) arbeitest; beides stellt der nächste Teil vor:

$ git push -u origin feature/neue-funktion   # neuen Branch im Remote anlegen
$ git push origin v1.0.0                   # einen Tag übertragen
$ git push origin --tags                   # alle Tags übertragen
$ git push origin --delete feature/neue-funktion   # Branch im Remote löschen

In Teams wird ein Feature-Branch meist nicht direkt in main gemergt, sondern über einen Pull Request (GitHub) bzw. Merge Request (GitLab) im Webinterface zur Prüfung vorgelegt. Wie das in den verbreiteten Arbeitsabläufen aussieht, beschreibt der Artikel Workflows im Team.

Anmelden beim Remote: Zugriffstoken oder SSH-Schlüssel

Lesen aus öffentlichen Repositorys geht ohne Anmeldung, für push musst Du Dich ausweisen. Das Kontopasswort akzeptieren GitHub (seit 2021) und viele andere Dienste dafür nicht mehr. Stattdessen gibt es zwei Wege:

• HTTPS mit Zugriffstoken: Im Webinterface erzeugst Du ein persönliches Zugriffstoken (Personal Access Token) mit begrenzten Rechten und Ablaufdatum und gibst es beim ersten push statt des Passworts ein. Unter Windows speichert es der mitgelieferte Git Credential Manager (git config --global credential.helper manager), der auch die Anmeldung im Browser übernehmen kann.

• SSH mit Schlüsselpaar: Du erzeugst ein Schlüsselpaar und hinterlegst den öffentlichen Schlüssel (.pub) in den Einstellungen Deines Kontos. Der private Schlüssel verlässt Deinen Rechner nie.

$ ssh-keygen -t ed25519 -C "martin.mustermann@test.de"   # erzeugt ~/.ssh/id_ed25519 und id_ed25519.pub
$ cat ~/.ssh/id_ed25519.pub                              # Inhalt ins Webinterface kopieren
$ ssh -T git@github.com                                  # Verbindung testen
$ git remote set-url origin git@github.com:testuser/testrepo.git

Blockiert ein Netz den SSH-Port 22, bieten einige Dienste SSH zusätzlich über Port 443 an (bei GitHub über den Host ssh.github.com); sonst bleibt HTTPS mit Token.

Ein Projekt aufsetzen: zu ignorierende Verzeichnisse vorbereiten

Bevor ein Projekt in die Versionsverwaltung übernommen werden kann, muss geplant werden, welche Dateien und Verzeichnisse in die Versionierung aufgenommen werden sollen.

Leere Verzeichnisse werden nicht von git versioniert. Sofern sie dennoch einbezogen werden müssen (weil z.B. die IDE die Verzeichnisse benötigt), muss darin eine Datei erzeugt werden. Üblich ist eine leere Datei namens .gitkeep oder eine .gitignore wie im Beispiel unten.

git prüft in jedem Verzeichnis, ob es eine Datei .gitignore gibt, in der alle Dateien/Verzeichnisse gelistet sind, die nicht versioniert werden sollen (auch über glob-character wie *). Ausnahmen werden dort mit vorangestelltem ! notiert. Für häufig auszuschließende Dateitypen finden sich im Internet zahlreiche .gitignore-Vorlagen.

Beispiel: Im Verzeichnis leeresVerzeichnis müssten wir eine Datei .gitignore mit folgendem Inhalt aufnehmen:

#Alle Dateien bis auf diese Datei im aktuellen Verzeichnis ignorieren:
# alle Dateien im Verzeichnis ignorieren ...
*
# ... bis auf diese Datei
!.gitignore

Achtung: Kommentare beginnen in .gitignore nur am Zeilenanfang mit #. Ein # hinter einem Muster gehört zum Muster.

Analog können ganze Verzeichnisse oder Datentypen ausgenommen werden. Um im Gesamtprojekt alle *.class Dateien (Java Bytecode) und das Verzeichnis /tmp nicht zu versionieren, erstellen wir im Projektverzeichnis eine Datei .gitignore mit dem Inhalt:

#In allen Unterverzeichnissen zu ignorierende Verzeichnisse und Dateitypen:
/tmp
*.class

Ein paar Regeln für die Muster: Ein / am Anfang bezieht das Muster nur auf das Verzeichnis der .gitignore (/tmp trifft nicht src/tmp), ein / am Ende nur auf Verzeichnisse (build/), ** steht für beliebig viele Verzeichnisebenen (logs/**/*.log). Typische Kandidaten sind Build-Ergebnisse (target/, build/, *.class), Abhängigkeiten (node_modules/, .venv/), Caches (__pycache__/), Protokolle (*.log), Einstellungen der Entwicklungsumgebung (.idea/, .vscode/) und vor allem Dateien mit Zugangsdaten (.env).

Warum eine Datei ignoriert wird, verrät git check-ignore -v <datei>. Wichtig: Die .gitignore wirkt nur auf Dateien, die noch nicht versioniert sind. Wurde eine Datei schon committet, nimmst Du sie mit git rm --cached <datei> aus der Versionierung und committest das. In der Historie bleibt sie trotzdem enthalten; ein versehentlich hochgeladenes Passwort muss deshalb immer geändert werden.

Umgang mit Zeilenenden festlegen

Die Betriebssysteme speichern die Zeilenenden in unterschiedlicher Weise: carriage return (CR / \r) oder line feed (LF / \n). Während Windows beide nutzt (CR LF), wird in unix-artigen Betriebssystemen nur LF verwendet. Um bei cross-plattform Entwicklerteams nicht jeden Zeilenumbruch als Änderung ausgegeben zu bekommen, bietet sich folgendes Verfahren an:

Windows-Systeme: Ins Repository werden Unix-Zeilenenden geschrieben (LF), die für den Workspace betriebssystem-üblich umgewandelt werden:

$ git config --global core.autocrlf true

Unix/Linux/OSX-Systeme: Ins Repository werden Unix-Zeilenenden geschrieben (lf) und diese auch lokal genutzt:

$ git config --global core.autocrlf input

Selten kommt es vor, dass git versucht, auch bei Binärdateien Zeilenenden anzupassen. Das würde natürlich zu Problemen führen. In der Datei .gitattributes können wir festlegen, welche Dateiendungen als Binärdatei behandelt werden (und nicht konvertiert werden) und welche als Text. Der Dateiinhalt könnte etwa so aussehen:

* text=auto
*.xml text
*.pdf binary

Die Zeile * text=auto überlässt git die Erkennung für alle übrigen Dateien. Weil die .gitattributes mit versioniert wird, gilt die Regel für alle im Team, unabhängig von der persönlichen core.autocrlf-Einstellung.

Git hinter einem Proxy

Sofern das lokale Netzwerk einen Proxy verwendet, muss sichergestellt werden, dass git diesen verwendet. Bereits eingerichtete System-Proxys werden nicht immer erkannt. Hier hilft es, den Proxy direkt in der git config einzurichten. Beispielsweise würde ein Proxy, der ohne User-Authentifizierung auf Port 8080 der IP 10.1.1.3 lauscht, wie folgt in git eingetragen (kein Schreibfehler: die Proxy-Adresse beginnt mit http://, und der Eintrag http.proxy gilt auch für HTTPS-Verbindungen):

$ git config --global http.proxy http://:@10.1.1.3:8080

Allgemein ist die URL wie folgt aufgebaut: http://proxyUsername:proxyPassword@proxy.server.com:port

Wer in unterschiedlichen Netzen arbeitet (mal mit, mal ohne Proxy), muss die Einstellung auch wieder rückgängig machen. Den Proxy entfernt man aus der git-Konfiguration mit:

$ git config --global --unset http.proxy

Alternativ kann der Proxy auch - nur für eine Session - über Umgebungsvariablen gesetzt werden (in der git-bash mit export, in der Windows-Eingabeaufforderung stattdessen mit set):

$ export http_proxy=http://username:password@proxydomain:port
$ export https_proxy=http://username:password@proxydomain:port
$ export no_proxy=localhost,.my.company

Sofern es Probleme mit der Authentifizierung gibt, kann es helfen, die Authentifizierung (innerhalb einer Domäne) über Windows umzusetzen:

$ git config --global credential.helper manager

Der Helfer manager ist der Git Credential Manager, der mit git für Windows installiert wird und den älteren Helfer wincred abgelöst hat.

Umbenennen alter Bezeichnungen für den Haupt-Branch (Remote master in main)

Im Zuge der “Black Lives Matter”-Bewegung wurde auch die IT-Branche sprachsensibler. In diesem Zusammenhang wurde nach kultursensibleren Ausdrücken für Terminologien wie master/slave gesucht. So auch bei git: Der Standard-Branch hieß vorher in den meisten git-Projekten master-Branch. Für neu angelegte Repositories wurde das in den aktuellen git-Diensten geändert: dort heißt er nun (wie in diesem Tutorial durchgängig): main-Branch.

Auch git-Dienste wie gitlab, github, bitbucket haben inzwischen nachgezogen und nutzen die neuen Bezeichnungen.¹ git selbst zieht mit Version 3.0 nach (geplant für das Frühjahr 2027): Ohne eigene Einstellung heißt der erste Branch neuer Repositorys dann main; vorhandene Repositorys behalten ihre Branch-Namen.

Für ältere git gibt es jedoch keine automatische Umwandlung: Die Branch-Bezeichnung zieht sich durch zu viele Bereiche der Tools und Pipelines durch, Konfigurationsprobleme wären wahrscheinlich. Daher müssen ältere Projekte händisch angepasst werden. Ob das jeweilige Projekt betroffen ist, bekommt man am besten per git status heraus:

$ git status

On branch master

Für Repositories, die nur lokal vorliegen, ist die Umbenennung schnell gemacht: Wir nutzen die move-Option. Die Hilfe per git branch -h sagt uns dazu: move/rename a branch and its reflog. Genau das wollen wir:

$ git branch -m master main

Um dem lokalen git jetzt mitzuteilen, dass beim pushen der main-Branch des remote-Repositories verwendet werden soll, muss der Upstream-Branch mit der Option -u bzw. --set-upstream neu gesetzt werden:

git push -u origin main

Jetzt wissen eigentlich alle Bescheid. Dem jeweils genutzten Repository-Anbieter muss noch mitgeteilt werden, dass fortan main der Standard-Branch ist. Bei GitLab geht das z.B. unter Settings / Repository / Default Branch. Sofern weitere Tools (z.B. CI-Pipelines) genutzt werden, muss dort ebenfalls der Branch geändert werden (für GitLab z.B. die .gitlab-ci.yml). Wenn das alles geschehen ist, kann der Upstream des master-Branches gelöscht werden:

git push origin --delete master

Fazit

Mit clone, fetch, pull und push kannst Du Deinen Stand jetzt mit anderen teilen. Richtig stark wird das Zusammenspiel, sobald mehrere Personen parallel in eigenen Branches arbeiten; das zeigt der nächste Teil Versionieren mit Branches. Gelegentlich ist das Einbinden vorhandener Repositories etwas hakelig - beispielsweise, wenn sowohl lokal als auch remote ein Repo erstellt wurde, die nun zusammengeführt werden müssen. Im Zweifel hilft lokal nur der schmutzigste aller git-Tricks: das Verzeichnis .git löschen (und damit alle vorigen Versionen - also bitte wirklich nur direkt am Anfang machen). Mit diesem Handwerkszeug sollte das Arbeiten in verteilten Teams jetzt kein Problem mehr sein.

Und falls doch Probleme auftauchen, hilft neben datensparsamen Suchmaschinen auch immer ein einfaches git help in der Konsole.

Teile dieses Tutorials

• Ein git-Repository anlegen und lokal commiten

• Git Remote nutzen

• Versionieren mit Branches

• Übungsaufgaben zu git

• Readme.md Dateien für git-Repositorys erstellen

• Workflows im Team: zentral, Feature-Branches, Gitflow, Trunk-based

Leitfragen

1. Was ist origin, und was ist origin/main? Antwort

origin ist der übliche Kurzname des Remote-Repositorys, aus dem geklont wurde. origin/main ist ein Remote-Tracking-Branch: die lokale Kopie des Standes von main im Remote-Repository zum Zeitpunkt des letzten fetch. siehe Abschnitt „Eine weitere eigene Arbeitskopie eines entfernten Repository kopieren“

2. Was unterscheidet git fetch von git pull? Antwort

git fetch lädt nur die neuen Commits und aktualisiert origin/…; Deine Branches und Dein Workspace bleiben unverändert. git pull führt danach zusätzlich ein merge (oder mit --rebase ein Rebase) in den aktuellen Branch aus. siehe Abschnitt „Den aktuellen Stand eines remote-Repositorys auf das lokale übertragen“

3. Dein git push wird mit „rejected … (fetch first)“ abgewiesen. Was ist passiert, und was tust Du? Antwort

Im Remote-Repository liegen Commits, die Du lokal noch nicht hast. Du holst sie mit git pull (oder git pull --rebase), löst eventuelle Konflikte und pushst danach erneut; --force ist auf geteilten Branches tabu. siehe Abschnitt „Den lokalen Stand hochladen: push“

4. Warum funktioniert die Anmeldung bei GitHub nicht mit dem normalen Passwort, und welche Alternativen gibt es? Antwort

GitHub und viele andere Dienste akzeptieren für git über HTTPS kein Kontopasswort mehr. Du meldest Dich mit einem persönlichen Zugriffstoken (gespeichert vom Git Credential Manager) oder per SSH-Schlüsselpaar an. siehe Abschnitt „Anmelden beim Remote: Zugriffstoken oder SSH-Schlüssel“

5. Wozu dient die Datei .gitignore, und warum hilft sie bei bereits versionierten Dateien nicht? Antwort

Sie listet Muster für Dateien und Ordner, die git nicht als neue Dateien vorschlagen und nicht mit git add . erfassen soll, z. B. Build-Ergebnisse oder Dateien mit Zugangsdaten. Dateien, die schon versioniert sind, verfolgt git weiter; sie musst Du mit git rm --cached aus der Versionierung nehmen. siehe Abschnitt „Ein Projekt aufsetzen: zu ignorierende Verzeichnisse vorbereiten“

6. Wie überträgst Du einen Tag ins Remote-Repository, und wie löschst Du dort einen Branch? Antwort

Tags werden nicht automatisch übertragen: git push origin v1.0.0 überträgt einen Tag, git push origin --tags alle. Einen Branch im Remote-Repository löschst Du mit git push origin --delete <branch>. siehe Abschnitt „Den lokalen Stand hochladen: push“

Links und weitere Informationen

• als Primärquelle: die git-Dokumentation - lässt sich im Terminal mit git --help aufrufen oder unter https://git-scm.com/doc

• für .gitignore-Vorlagen: die Sammlung github/gitignore mit Vorlagen für viele Sprachen und Entwicklungsumgebungen

• zur Anmeldung: die Anleitungen zu SSH-Schlüsseln bei GitHub und zu Zugriffstoken bei GitLab

• Als Info v.a. zu zentralen Workflows mit git: René Preißel / Bjørn Stachmann: Git (dPunkt Verlag, ISBN Print: 978-3-86490-649-7)

• Aus der “von Kopf bis Fuß”-Serie von O’Reilly - erfrischend anders: “Head First Git” von Raju Gandhi (englisch), ISBN: 9781492092513

• Zahllose Tutorials im Internet wie z.B. dieses von Atlassian

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “git im Team und Remote nutzen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/git02-remote_nutzen veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/devoptools/git. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 12.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]