Soooo... GIT für Dummies sagt es ja auch schon irgendwie.
Ich arbeite viel von zu Hause und noch mehr von Unterwegs in Hotels. Nun habe ich dies bisher immer so gelöst:
Laptop auf, WLAN an, VPN verbunden Projekt auf Laptop kopiert - gearbeitet.
Wieder zu Hause:
Laptop an, aktuelles Projekt auf das NAS kopiert und überschrieben - gearbeitet.
Nun dachte ich mir, in meinem Jugendlichen Leichtsinn, dafür ist doch eigentlich dieses GIT gedacht. Gesagt - getan: ich habe mir auf meinen Server eine GitLab LXC installiert. Dieser funktioniert wunderbar und läuft tadellos, ist über Web zu erreichen, ich habe einen User angelegt, ein Projekt angelegt und habe mir von meinem Laptop auch den SSH Schlüssel kopiert.
Nun dachte ich, in meinem zweiten jugendlichen Leichtsinn, ich probiere dies einfach mal mit einem "Hello World" Projekt in Python aus.
Und da fehlt es dann schon an Fundamentalen Wissen. Also ich initialisiere das Projekt so:
1
rene@node-1:~# mkdir HelloWorld
2
rene@node-1:~# cd HelloWorld/
3
rene@node-1:~/HelloWorld# git init
4
Initialized empty Git repository in /rene/HelloWorld/.git/
Soweit so gut, ich schreibe dann also mein klein Python Script und speichere das lokal ab.
1
rene@node-1:~/HelloWorld# git add HelloWorld.py
2
rene@node-1:~/HelloWorld# git status
3
On branch master
4
5
No commits yet
6
7
Changes to be committed:
8
(use "git rm --cached <file>..." to unstage)
9
new file: HelloWorld.py
10
11
rene@node-1:~/HelloWorld#
Nun denke ich mir, ich übertrage dies, aber es erscheint halt dann nicht in meinem Repository:
Erstelle einfach mal ein neues Projekt auf der Web-UI deines Gitlab Servers.
Dort wird die im Anschluss eine Anleitung angezeigt wie du dein lokales Repository verbindest.
Kleiner Tip: simpler ist es das Projekt zuerst zu erstellen, dann auf das Laptop zu klonen und erst dann zu programmieren.
Du kannst per "git remote add <name> <projekturl>" ein remote repo hinzufügen. Das kann z.B. ein Repo auf einem Server, oder auch ein lokales bare repo sein. Der remote für das Hauptrepo wird oft "origin" genannt, muss man aber nicht zwangsläufig. Jenachdem wie es eingestellt ist, kann gitlab auch repos erstellen, wenn die URL passt und man pusht, dann muss man das nicht erst im Webinterface machen.
Nachdem du ein Remote hast, kannst kannst du mit "git push" da hin pushen. Da kannst du remote & branch mit angeben, wenn der upstream mal gesetzt ist muss man es meist nicht mehr, aber git sagt dir beim ersten mal schon, was einzugeben ist.
Nun dachte ich mir, in meinem Jugendlichen Leichtsinn, dafür ist doch
eigentlich dieses GIT gedacht. Gesagt - getan: ich habe mir auf meinen
Server eine GitLab LXC installiert. Dieser funktioniert wunderbar und
läuft tadellos, ist über Web zu erreichen, ich habe einen User angelegt,
ein Projekt angelegt und habe mir von meinem Laptop auch den SSH
Schlüssel kopiert.
Für git brauchst du gar nicht mal nicht unbedingt Gitlab. Das bringt dir eine schöne bunte Web-GUI und Issue-Tracking und so. Im Grunde reicht ein Rechner mit ssh-Zugriff aus.
Nun denke ich mir, ich übertrage dies, aber es erscheint halt dann nicht
in meinem Repository:
rene@node-1:~/HelloWorld# git commit -m "Erstelle HelloWorld.py"
Damit machst du einen Commit in dein (lokales) Repository. Mit einer Übertragung hat das erst mal nichts zu tun.
Kleine Anmerkung: Das # am Ende deines Prompts lässt mich vermutet, dass du das alles als root machst, was keine gute Idee ist.
Wie bekomme ich dies auf meinen Git Server?!
Du musst es in das Repository auf deinem Server pushen, d.h. im Prinzip den Inhalt deines lokalen Repositorys mit dem des Servers synchronisieren. Dazu musst du dieses aber erst per "git remote add" hinzufügen.
Git an sich ist nämlich erst mal dezentral, d.h. jeder Rechner, an dem man mit git arbeitet, hat sein eigenes Repository, und diese Repos können dann mit git push und git pull zwischen den Rechnern synchronisiert werden. Natürlich hält einen niemand davon ab, sich einen dieser Rechner als "zentralen" Server zu definieren.
Also ich habe mir dann in meiner WebUI ein Projekt erstellt. Dann per git clone eben dieses Projekt geladen. Eine Datei erstellt, mit git add diese Datei hinzugefügt. Dann ein git commit gefolgt von git push hat diese Datei dann hochgeladen :-D
Nunja, um da die Feinheiten zu verstehen und zu ergründen, werde ich sicherlich noch ein paar Tage brauchen. Aber bei Stefan Frings auf der Seite werde ich da schon fündig.
Also ich habe mir dann in meiner WebUI ein Projekt erstellt. Dann per
git clone eben dieses Projekt geladen. Eine Datei erstellt, mit git add
diese Datei hinzugefügt. Dann ein git commit gefolgt von git push hat
diese Datei dann hochgeladen :-D
Nunja, um da die Feinheiten zu verstehen und zu ergründen, werde ich
sicherlich noch ein paar Tage brauchen. Aber bei Stefan Frings auf der
Seite werde ich da schon fündig.
Stefan Frings' Seite ist schon sehr gut. Wenn Du noch ein wenig tiefer einsteigen möchtest oder vielleicht mit der einen oder anderen Erklärung auch nach dem dritten Lesen noch nicht warm werden solltest, findest Du hier noch weiter gehende Informationen und andere Erklärungsansätze:
git ist das Programm zur Versionskontrolle, damit löst du die Aktion wie commit, branch, push usw aus.
github oder gitlab sind Server die das git Protokoll verstehen und die dann z.B. als Remote für das git Programm agieren. Mit vielen Zusatzfunktionen, z.B. das Aktionen ausgeführt werden wenn etwas auf den Server gepusht wird.
Das ist schon ein gigantisch gewachsenes Ökosystem, aber sehr genial.
Git hat nichts mit GitHub zutun. Aber GitHub verwendet git / baut darauf auf.
Git ist ein Programm & Libraries, um Git Repos zu verwalten. Git Repos beinhalten die Daten / stellen die Bereit, die git braucht, das kann in form von Dateien sein, (schau in deinen .git Folder rein), oder über (remote) Schnittstellen / Protokolle.
GitHub / GitLab / Gitea, etc. sind Webanwendungen. Sie bauen auf Git auf, und bieten ein Web Frontend an, um git Repos zu verwalten. Zusätzlich bieten sie viele weitere Funktionen.
Als Beispiel, mit git kann man z.B. etwas aus einem anderen Repo, in sein eigenes Mergen. Aber Merge Requests (jemand anderes will eine Änderung gemerged haben), kennt es nicht. GitHub / GitLab / Gitea bieten dafür eine Funktion in ihrem Web Frontend an. Das eigentliche Mergen am Schluss macht dann wieder git. Man könnte es auch manuell lokal machen. Früher (und bei manchen Projekten heute noch), hat man statt Merge Requests auf Web Platformen, einfach Patches als E-Mail versendet, und der Empfänger hat die dann bei sich gemerged.
GitHub / GitLab / Gitea bieten auch noch viele weitere Services an, die nichts mehr mit git selbst zutun haben. Sachen wie Package Manager, CI / CD Pipelines, Issue Tracker (früher hatte man da Sachen wie "track" verwendet, machen manche immer noch), etc. Bei GitHub jetzt auch noch AI und online IDE und und und. Klar, man will die User möglichst konstant auf seiner Plattform halten.
GitHub und GitLab sind auch noch Service Provider. Sie (bei GitHub
Microsoft) Betreiben diese Web Anwendungen (GitHub respektive GitLab genannt), und stellen sie dir zur Verfügung, und damit auch die damit einhergehenden Services wie das Hosting von Git Repos, und all die anderen Funktionen, die die Web Anwendung unterstützt. Bei GitLab / Gitea kann das jeder auch selbst machen, oder andere Provider nehmen. Bei GitHub nicht, deren Web Anwendung ist nur als Service verfügbar, die Anwendung selbst ist proprietär, kann anders als bei GitLab / Gitea nicht heruntergeladen usw. werden.
Aber alle bauen auf git auf, und unterstützen die git Protokolle, darum kann man mit Git mit Repos auf jedem der Platformen interagieren. Die zusätzlichen Services wiederum, die nichts mit git selbst zutun haben, sind bei jedem Anbieter wieder anders gelöst.
Und zu guter Letzt, um Git zu nutzen, braucht man GitHub, GitLab, etc. nicht zwingend. Repos kann man auch ohne diese anlegen & verwalten, z.B. mit dem git command line Client, oder über die diversen Anwendungen mit Git Integration. Und die Repos können lokal sein, oder auf einem Server, auch alles ohne diese Web Platformen.
dazu eine Frage. Sind Git und Github unterschiedliche Dinge oder doch
ein und Dasselbe? Irgendwie blick ich da nicht durch.
Im Gegensatz zu den meisten anderen Tools zur Versionskontrolle gibt es in git keine zentrale Instanz und keine spezielle Software für Server und Clients.
Jedes Repository, sei es lokal oder auf einer entfernten Maschine ist theoretisch gleichwertig, jeder darf von jedem klonen, pullen und pushen.
Ein git-Hardliner wird dich schon mal rügen wenn du im git-Kontext von einem Server sprichst.
Weil aber zentrale Instanzen und Rechtverwaltung in der Praxis doch ganz dufte sind ging man her und hat Tools wie github, gitlab usw. entwickelt. Die setzen auf ein normales git auf.
Macht es eigentlich Sinn, sich so einen Server selber auf dem Recher zu installieren?
Fürs SVN habe ich das schon gemacht und ein passive Repository auf einem anderen LW angelegt, auf das ich ständig commite und Versionen und branches lokal bei mir zu haben. Dann wird das eigentlich R auf dem Server nur gefüttert, wenn eine Version total stabil und getestet ist und ein milestone erreicht ist, der mit dem, was die Kollegen programmieren zuusammenpasst.
Macht es eigentlich Sinn, sich so einen Server selber auf dem Rechner zu
installieren?
Für eine Einzelperson wohl kaum. Alle Zusatzfunktionen von GitLab zielen darauf ab, die Zusammenarbeit von Team-Mitgliedern zu koordinieren. Wenn man Gitlab installiert, sollte das dann an zentraler Stelle sein, worauf alle Team-Mitglieder zugreifen können.
Mit Git ist es durchaus möglich, lokal mehrstufig zu arbeiten, wie du es dir vorstellst. Dazu brauchst du aber kein Gitlab. Der Git Client kann das schon von sich aus.
1
cd /repository
2
git init --bare MeinProjekt.git
Danach kannst du von deinem Arbeistverzeichnis aus zu diesem lokalen Repository pushen. Es geht genau so, wie das pushen zum zentralen Repository.
1
cd /home/stefan/programmieren/MeinProjekt
2
git remote add origin /repository/MeinProjekt.git
3
git push --all --set-upstream origin
Ich bin hingegen gewohnt, für solche Aufgaben persönliche Branches anzulegen, die erst nach "main" gemergt werden, wenn sie fertig sind.
Ein eigener git Server macht schon Sinn. Z.B. wenn man seine Geheimnisse nicht den fremden Hostern anvertrauen möchte. Oder man möchte mit den Actions und Buildserver oder den verschiedenen Einstellungen experimentieren.
Ich weiß nicht wieviele Projekte man in privaten Repos bei github/gitlab speichern kann, auf dem eigenen Server soviel wie man Speicherplatz hat.
Mit fertigen Images für Proxxmox oder den Turnkey Solutions ist das auch kein Hexenwerk ein gitlab ans rennen zu bekommen. Und mit gitea ist ja noch leichtgewichtigere Variante dazugekommen.
Ich hatte auch mal einen Weg gefunden beim push gleichzeitig auf mehrere remotes zu schreiben. Muss ich auch noch mal suchen für mich, das ist auch praktisch wenn es auf zwei remotes synchron sein soll.
Aber vielleicht gibt es dafür noch weitere Möglichkeiten?
so ein git Server für Arme ist sicher die einfachste Methode, aber ein 'richtiger' git Server bietet ja schon ein bisschen mehr. Schon das man einfach mit dem Smartphone brauchbar durch den ganzen Quellcode brausen kann ist doch genial. Oder die eingebaute WebIDE, gitlab bietet in der aktuellen Version ein VSCode als IDE im Browser.
Das nutze ich auch alles ohne Team.
Überhaupt sollte man vergessen das man git nur braucht wenn man im Team arbeitet. Es ist so unendlich hilfreich wenn man Fehler sucht oder fremden Code stückweise verbessert. Wenn etwas nicht klappt sieht man genau Seine Änderungen und hat einen viel besseren Überblick. Oder kramt ein Projekt nach langer Zeit raus, da freut man sich unendlich über die kommentierten Entwicklungsschritte. Was man über die Commits natürlich auch tun sollte.
Mit Git ist es durchaus möglich, lokal mehrstufig zu arbeiten, wie du es
dir vorstellst. Dazu brauchst du aber kein Gitlab. Der Git Client kann
das schon von sich aus.
cd /repository
git init --bare MeinProjekt.git
Danach kannst du von deinem Arbeistverzeichnis aus zu diesem lokalen
Repository pushen. Es geht genau so, wie das pushen zum zentralen
Repository.
Aber wozu? Das Arbeitsverzeichnis enthält ja bereits ein vollständiges Repository. Für mich ergibt ein zweites Repo, in das man alles pusht, nur dann einen Sinn, wenn mehrere Rechner involviert sind.
so ein git Server für Arme ist sicher die einfachste Methode, aber ein
'richtiger' git Server bietet ja schon ein bisschen mehr. Schon das man
einfach mit dem Smartphone brauchbar durch den ganzen Quellcode brausen
kann ist doch genial.
Ich wüsste nicht, wozu ich das auf dem Telefon bräuchte.
Oder die eingebaute WebIDE, gitlab bietet in der
aktuellen Version ein VSCode als IDE im Browser.
Das nutze ich auch alles ohne Team.
Dort, wo ich meinen Code bearbeite, habe ich bereits einen Editor, der auch ohne permanente Internetverbindung funktioniert. Sowas per Web zu haben, ist ein nettes Gimmick und bei Nutzung in einem Team ganz praktisch, aber nun auch nicht essenziell.
Aber wozu? Das Arbeitsverzeichnis enthält ja bereits ein vollständiges
Repository. Für mich ergibt ein zweites Repo, in das man alles pusht,
nur dann einen Sinn, wenn mehrere Rechner involviert sind.
Ist halt noch eine Möglichkeit, ein Backup zu machen. Und wer hat schon nur einen einzigen Rechner?
Aber wozu? Das Arbeitsverzeichnis enthält ja bereits ein vollständiges
Repository. Für mich ergibt ein zweites Repo, in das man alles pusht,
nur dann einen Sinn, wenn mehrere Rechner involviert sind.
Ist halt noch eine Möglichkeit, ein Backup zu machen. Und wer hat schon
nur einen einzigen Rechner?
Ich schrieb ja: Wenn mehrere Rechner involviert sind, kann das sinnvoll sein. Mache ich auch genau so:
Aber oben ging's ja um mehrere Repos auf einem einzelnen Rechner.
Naja, vielleicht möchte man verschiedene Arbeitskopien parallel testen. Zwar sind git-Branches sehr leichtgewichtig und es kann schnell zwischen Branches gewechselt werden, aber nur wenn keine lokalen Änderungen uncomitted sind.
Ich seh da schon einen, wenn auch kleinen, Sinn.
aber nur wenn keine lokalen Änderungen uncomitted sind
Dann nutzt du Stash. Branches durch verschiedene Verzeichnisse zu ersetzen, ist ziemlich ungeschickt. Damit machst du Vorteile von git komplett zunichte.
Dann nutzt du Stash. Branches durch verschiedene Verzeichnisse zu
ersetzen, ist ziemlich ungeschickt. Damit machst du Vorteile von git
komplett zunichte.
Diesem Absolutismus kann ich nicht zustimmen.
Alleine schon wenn ich mehrere Feature-Branches in den Master merge finde ich es hilfreich, die verschiedenen Branches gleichzeitig lokal zu halten.
Workflows dürfen sich unterscheiden.
Aber oben ging's ja um mehrere Repos auf einem einzelnen Rechner.
Naja, vielleicht möchte man verschiedene Arbeitskopien parallel testen.
Zwar sind git-Branches sehr leichtgewichtig und es kann schnell zwischen
Branches gewechselt werden, aber nur wenn keine lokalen Änderungen
uncomitted sind.
Ich seh da schon einen, wenn auch kleinen, Sinn.
Sowas mache ich auch manchmal. Git clone geht übrigens nicht nur bei bare repos (hat dann aber ein paar Limitationen). stash mochte ich nie besonders.
