GIT für Dummies

[Rene K. (xdraconix)]

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:

rene@node-1:~# mkdir HelloWorld
rene@node-1:~# cd HelloWorld/
rene@node-1:~/HelloWorld# git init
Initialized empty Git repository in /rene/HelloWorld/.git/

Soweit so gut, ich schreibe dann also mein klein Python Script und 
speichere das lokal ab.

rene@node-1:~/HelloWorld# git add HelloWorld.py
rene@node-1:~/HelloWorld# git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   HelloWorld.py

rene@node-1:~/HelloWorld#

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"
[master (root-commit) 5896d5e] Erstelle HelloWorld.py
 Committer: draconix <[e-mail]>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email [e-mail]

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

 1 file changed, 1 insertion(+)
 create mode 100644 HelloWorld.py

Wie bekomme ich dies auf meinen Git Server?!

Kann mir da jemand unter die Arme greifen?

Liebe Grüße René

[Stefan F. (Gast)]

http://stefanfrings.de/git/index.html

[Jörg (jrg_e)]

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.

[Stefan F. (Gast)]

Jörg schrieb:
> simpler ist es das Projekt zuerst zu erstellen,

Ja, das ist auch meine bevorzugte Vorgehensweise.

[J. S. (jojos)]

da fehlte ein git commit -m "irgendein Kommentar" und git push
Die Anweisung mit dem Eintragen des Users und Mail natürlich auch noch 
befolgen.

bzw. commit hattest du ja gemacht, also git push
und den remote noch anlegen mit git remote ...

[Daniel A. (daniel-a)]

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.

[Rolf M. (rmagnus)]

Rene K. schrieb:
> 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.

[Rene K. (xdraconix)]

Ahhh Wunderbar, so geht das natürlich auch.

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.

Vielen Dank euch schonmal.

[Sheeva P. (sheevaplug)]

Rene K. schrieb:
> 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:

https://git-scm.com/book/de/v2

Viel Spaß und Erfolg mit git! :)

[Veit D. (devil-elec)]

Hallo,

dazu eine Frage. Sind Git und Github unterschiedliche Dinge oder doch 
ein und Dasselbe? Irgendwie blick ich da nicht durch.

[J. S. (jojos)]

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.

[Daniel A. (daniel-a)]

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.

[Veit D. (devil-elec)]

Hallo,

Danke für die Erklärungen. Erstmal gut zu wissen das Git die Basis für 
alles ist.

[Le X. (lex_91)]

Veit D. schrieb:
> 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.

[He. (Gast)]

J. S. schrieb:
> gitlab sind Server

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.

[Stefan F. (Gast)]

Heiko E. schrieb:
> 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.

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.

cd /home/stefan/programmieren/MeinProjekt
git remote add origin /repository/MeinProjekt.git
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.

[J. S. (jojos)]

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?

[J. S. (jojos)]

Stefan F. schrieb:
> git init --bare MeinProjekt.git

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.

[Rene K. (xdraconix)]

Ja ich nutze es halt, weil ich viele verschiedene Rechner habe, mit 
denen ich arbeite und auf einigen ein VPN nicht nutzbar ist.

[Rolf M. (rmagnus)]

Stefan F. schrieb:
> 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.

J. S. schrieb:
> 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.

[J. S. (jojos)]

Meine Ideen kommen mir auch wenn ich nicht am Rechner sitze. Smartphone 
ist aber fast immer in der Nähe.

[Harald K. (kirnbichler)]

Rolf M. schrieb:
> 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?

[Oliver S. (oliverso)]

Git für den Heimgebrauch funktioniert bestens mit Ordnern.

Auf einem Netzlaufwerk liegen die bare repos, darauf können dann alle 
Rechner zugreifen und von dort clonen.

Oliver

[Rolf M. (rmagnus)]

Harald K. schrieb:
> Rolf M. schrieb:
>> 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:

Oliver S. schrieb:
> Auf einem Netzlaufwerk liegen die bare repos, darauf können dann alle
> Rechner zugreifen und von dort clonen.

Aber oben ging's ja um mehrere Repos auf einem einzelnen Rechner.

[Le X. (lex_91)]

Rolf M. schrieb:
> 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.

J. S. schrieb:
> Meine Ideen kommen mir auch wenn ich nicht am Rechner sitze. Smartphone
> ist aber fast immer in der Nähe.

Eben. Beim Kacken hat man wenigstens Ruhe und Zeit. Da ist mobiler 
Zugriff auf seine Repositories manchmal ganz hilfreich.

[900ss (900ss)]

Le X. schrieb:
> 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.

[Le X. (lex_91)]

900ss D. schrieb:
> 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.

[900ss (900ss)]

Le X. schrieb:
> Workflows dürfen sich unterscheiden.

Ja sicher. Es gibt halt effektive Workflows und weniger effektive.

[Le X. (lex_91)]

Ok.

[Daniel A. (daniel-a)]

Le X. schrieb:
> Rolf M. schrieb:
>> 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.

[Daniel A. (daniel-a)]

Ich habe noch einen Anwendungsfall. Bei meinem image builder habe ich 
bare mirrors von Repos die ich brauche:
https://github.com/Daniel-Abrecht/dpa-image-builder/blob/d445e472d48393ce532c5a3a885f086c9ae11eec/src/make-helper-functions.mk#L124-L142

Zum bauen werden die in einem mount namespace in ein neues tmpfs 
geklont, das am ende wieder geunmounted wird:
https://github.com/Daniel-Abrecht/dpa-image-builder/blob/master/script/with-repo.sh#L36
https://github.com/Daniel-Abrecht/dpa-image-builder/blob/d445e472d48393ce532c5a3a885f086c9ae11eec/platform/pinephone-pro/uboot/makefile#L17

[Rolf M. (rmagnus)]

Le X. schrieb:
> Rolf M. schrieb:
>> Aber oben ging's ja um mehrere Repos auf einem einzelnen Rechner.
>
> Naja, vielleicht möchte man verschiedene Arbeitskopien parallel testen.

Dazu braucht man keine separaten Repos. Siehe 
https://git-scm.com/docs/git-worktree

[900ss (900ss)]

Rolf M. schrieb:
> keine separaten Repos

Das worktree feature enthält aber scheinbar noch Bugs. Siehe ganz unten 
auf der Seite, die du verlinkt hast.
Ist dann ein wenig russisch Roulette ;)

[Rolf M. (rmagnus)]

900ss D. schrieb:
> Rolf M. schrieb:
>> keine separaten Repos
>
> Das worktree feature enthält aber scheinbar noch Bugs.

Bei mir hat es problemlos funktioniert, allerdings gab es da keine 
Submodules. Die nutze ich sowieso eher selten.