git im Team und Remote nutzen
https://bildung.social/@oerinformatik/110326723919640390
https://oer-informatik.de/git03-remote_nutzen
tl/dr; (ca. 10 min Lesezeit): Zugegeben: die meisten Leute meinen, wenn sie von git reden eher Plattformen wie GitHub, GitLab oder Bitbucket. Wir sollten diese zentralen Repositories als schleunigst einbinden… Neben diesem Teil gibt es noch die beiden Tutorialfolgen Ein git-Repository anlegen und lokal commiten und Versionieren mit Branches. (Zuletzt geändert am 27.05.2023)
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
$ git status # nochmal kontrollieren: wird alles einbezogen, was einbezogen werden soll? Und ignoriert?
$ git add .
$ git commit -m "Initialisierung des Projekts"Neues zentrales Repository erstellen
Ein zentrale 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.
Zentrales Repository lokal als remote einstellen
Verknüpft wird das remote-Repository über den remote-Befehl und eine URL mit Protokollangabe:
In diesem Beispiel wurde https als Protokoll verwendet. Es ist genauso möglich, per SSH oder file auf ein entferntes Repository zuzugreifen. Gegebenenfalls sind Firewalleinstellungen und Portfreigaben zu beachten! Konkret: in unserem Schulnetz ist beispielsweise nur der Weg über HTTPS geöffnet, da die Standard-SSH-Ports blockiert werden.
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:
On branch main
nothing to commit, working tree cleanEin Branch des origin kann lokal über den Pfad origin/main angesprochen werden. Allerdings verhält es sich anders, als ein lokales Repository.
Den aktuellen Stand eines remote-Repositorys auf das lokale übertragen
Die Änderungen des entfernten Repositorys wird mit dem Befehl fetch in das lokale Repository geladen. Es aktualisieren sich also alle Branches unter origin.
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.
Das Aktualisieren des remote-Repositorys und Übernehmen der Änderungen in den aktuellen Branch kann auch in einem Befehl (pull) erfolgen. Wenn dies per rebase stattfinden soll wäre das: pull --rebase.
Ein Remote-Repositorys klonen und einem neuen Remote-Repository zuweisen:
Ein Remote-Repository klonen:
ggf. das Repository umbenennen
in das Verzeichnis wechseln:
bisherige remote-Repositories ausgeben:
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 --tagsVariante 2: Das alte Remote-Repository soll ersetzt werden:
Überprüfen, ob das geklappt hat mit
Den aktuellen Stand eines lokalen-Repositorys auf das remote-Repository übertragen
Der umgekehrte Weg: wir wollen unsere lokalen Änderungen auf das remote Repository übertragen. Hierzu muss zunächst sichergestellt sein, dass wir unsere Änderungen von der aktuellen Version des remote-Repositorys ableiten (s.o.: pull)
TODO to be continued
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.
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
!.gitignore # bis auf diese DateiAnalog 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
*.classUmgang 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:
Unix/Linux/OSX-Systeme: Ins Repository werden Unix-Zeilenenden geschrieben (lf) und diese auch lokal genutzt:
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:
*.xml text
*.pdf binaryGit 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: der Pfad wird in beiden Fällen mit http:// angegeben, nicht https://):
$ git config --global http.proxy http://:@10.1.1.3:8080
$ git config --global https.proxy http://:@10.1.1.3:8080Allgemein 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:
Alternativ kann der Proxy auch - nur für eine Session - über Umgebungsvariablen gesetzt werden:
$ set http_proxy=http://username:password@proxydomain:port
$ set https_proxy=http://username:password@proxydomain:port
$ set no_proxy=localhost,.my.companySofern es Probleme mit der Authentifizierung gibt, kann helfen, die Authentifizierung (innerhalb einer Domäne) über Windows umzusetzen:
Um das lokale Repository erstmals auf das remote Repository zu übertragen, geben Sie ein (hier Beispiel mit main, bei älteren Installationen wird der Branch oft noch master genannt):
Damit wird der lokale main-Branch mit dem main-Branch des origin/main (lokale Kopie des remote-Repos) verknüpft.
Remote master-Branch in main umbenennen
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 akutellen git-Repositories 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.1
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:
On branch masterFü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:
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:
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:
Fazit
Wer mit git branches umgehen kann hat wird auch mit den beiden neuen Befehlen pull und push keine Probleme bekommen. Gelegentlich ist das einbinden vorhandener Repositories etwas hakelig - beispielsweise, wenn sowohl lokal als auch remot 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 Anfagn machen). Mit diesem Handwerkszeug sollte das Arbeiten in verteilten Teams jetzt kein Problem mehr sein.
Und falls doch Probelme auftauchen hilft neben datensparsamen Suchmaschinen auch immer ein einfaches git help in der Konsole.
Teile dieses Tutorials
Weitere Literatur zur Versionsverwaltung git
als Primärquelle: die git-Dokumentation - lässt sich im Terminal mit
git --helpaufrufen oder unter https://git-scm.com/docAls 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/git03-remote_nutzen veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/devoptools/git. Stand: 27.05.2023.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
Siehe z.B. diesen Artikel über GitHub↩
