Jetzt geht’s wieder weiter mit meinem neuen git-Server.
Ein git-Server alleine nutzt einma ja noch nicht viel. Man muss ihn auch verwenden. Dabei will ich mich jetzt erst einmal weiterhin in der Console unter Linux austoben, da ich hier aktuell arbeite und ich der Meinung bin, dass es ganz sinnvoll ist, wenn man die Consolen-Befehle kennt und versteht, weil man damit das System besser kennenlernen kann.
Aktuell arbeite ich an einem Angular-Projekt, das auf einen .Net-server zugreift. Der .Net-server ist ein dotnet core webapi Projekt. Also auch alles komplett unter Linux verwendbar.

Angular-Projekt auf den git-Server pushen

Fangen wir mit dem Angular-Projekt an.
Einigen ist sicherlich schon aufgefallen, dass beim Anlegen eines Angular-Projekts auch eine Datei .gitignore angelegt wird. Darin wird vom Framework her automatisch alles eingetragen, das nicht an git gepusht werden soll. Da muss man sich also nicht weiter darum kümmern.
Letztendlich muss man also das lokale Verzeichnis lediglich mit dem Server-Repository verbinden und das geht folgendermaßen:
(ich schreib jetzt zwecks Nachvollziehbarkeit auch das Erstellen des Angular-Projekts dazu)

ng new angular-test
cd angular-test
git remote add origin git@<server-ip>:angular-test

Damit ist die Verbindung erst einmal hergestellt. Ob das auch wirklich stimmt, kann man mit folgendem Kommando ausprobieren:

git remote -v

Damit bekommt man folgende Ausgabe:

origin	git@<server-ip>:angular-test (fetch)
origin	git@<server-ip>:angular-test (push)

Letztendlich muss man das Ganze dann nur noch auf den Server pushen:

git push origin master

Zur Erklärung der Parameter erlaube ich mir jetzt mal einen Spaß, den man vielleicht auch mal produktiv brauchen kann. Wir legen einfach ein zweites Repository auf dem Server an und fügen zum aktuellen Projekt einen zweiten Remote hinzu. Und dann pushen wir das Ganze in ein anderen Repository. Dazu verwenden wir folgende Kommandos:

git remote add origin2 git@<server-ip>:angular-test2
git push origin2 master

Was haben wir jetzt hier gemacht? Wir haben die ganze Arbeitskopie mit einem zweiten Repository verknüpft. Die beiden Repositories kann ich mit den Namen origin bzw origin2 ansprechen. Das kann man auch überprüfen, auf welche Repositories mit welchem Namen zugegriffen wird:

git remote -v
-->
origin	git@<server-ip>:angular-test (fetch)
origin	git@<server-ip>:angular-test (push)
origin2	git@<server-ip>:angular-test2 (fetch)
origin2	git@<server-ip>:angular-test2 (push)

So… Und was heißt master? Einfach erklärt kann man sagen, dass das der Name des Branches ist, den man einchecken will. Bei einem neu angelegten Projekt arbeitet man logischerweise im Master-Branch, da es ja sonst noch keinen Branch gibt. Wenn man später einen Branch angelegt hat und diesen einchecken will, sollte man den hier entsprechend verwenden.

Dotnet-Projekt auf den git-Server pushen

Probieren wir das Ganze jetzt gleich mal mit unserem dotnetr-Projekt aus. Dummerweise werden wir bereits beim ersten Kommando (git remote add…) feststellen, dass es nicht so funktioniert. Man bekommt nämlich die folgende Fehlermeldung:

fatal: Kein Git-Repository (oder irgendeines der Elternverzeichnisse): .git

Man muss also erst noch irgendwas machen, um dem System zu sagen, dass das Ganze ein git-Arbeitsverzeichnis werden soll. Dazu gibt es folgendes Kommando:

git init

Aber auch damit alleine klappt es noch nicht. Man muss nämlich auch noch die Dateien hinzufügen und committen. Erst dann kann man sie zum Server pushen.

git add --all
git commit -m 'initial version'
git push origin master

Jetzt wird alles zum git-Server gesendet… Und zwar wirklich alles. Auch die Ordner bin und obj und alles andere, was sich irgendwie in diesem Verzeichnis befindet und was nicht unbedingt was in der Versionsverwaltung zu suchen hat.
Jetzt kommt das, was ich oben schon geschrieben habe: Ein Angular-Projekt hat von Haus aus ein gitignore-File. Das brauchen wir jetzt auch bei unserem dotnet-Projekt, aber hier müssen wir es uns selbst anlegen. Es gibt einige Vorschläge, wie ein solchen File auszusehen hat. Ich habe hier folgendes Beispiel:

*.swp
*.*~
project.lock.json
.DS_Store
*.pyc

# Visual Studio Code
.vscode

# User-specific files
*.suo
*.user
*.userosscache
*.sln.docstates

# Build results
[Dd]ebug/
[Dd]ebugPublic/
[Rr]elease/
[Rr]eleases/
x64/
x86/
build/
bld/
[Bb]in/
[Oo]bj/
msbuild.log
msbuild.err
msbuild.wrn

# Visual Studio
.vs/

Diese Datei liegen wir also jetzt manuell an. Zusätzlich löschen wir die bereits falsch eingecheckten Verzeichnisse und Dateien. In meinem Fall sind das die Ordner bin und obj, da ich lediglich ein leeres Consolen-Projekt erstellt habe. Und dann committen und pushen wir das Ganze wieder zum Server:

git add --all
git commit -m 'added .gitignore and removed bin and obj folder'
git push origin master

Jetzt haben wir alles fertig und können das Projekt auch an einem anderen Rechner (oder Ordner) wieder auschecken und daran weiter arbeiten.

Ein kleiner Tipp noch:
Damit man nicht immer origin master mitangeben muss, kann man den upstream auch entsprechend setzen, damit immer diese Vorgabe verwendet wird:

git push --set-upstream origin master

Damit spart man sich ein bisschen Tiparbeit und muss sich nicht ganz soviel merken.