Knowledge base

Im letzten Beitrag über GIT habe wir die lokale Installation angeschaut. In diesem Beitrag werden wir nun etwas tiefer in die Materie eintauchen. So zeige ich wie man ein lokales Repository erstellen, einen Branch erstellen, mit einem Remote Repositoriy (gitea) verbinden und wie man seine Passwörter speichern kann.

Lokales und Remote Repository

Für das Teamübergreifende arbeiten macht es sinn einen zentralen Server bei dem man seine Ändungen pushen kann. Dies kann auch ein Netzlaufwerk sein. Will man einen externen Mitarbeiter befähigen auf das Repo zuzugreifen ist ein Webservice die einfachste Möglichkeit.

Lokales Repository erstellen

Wie wir im letzten Beitrag gesehen haben müssen wir zuerst ein lokales Repository erstellen. Verkürz müssen wir folgendes eingeben:

cd c:\repos
git init Sandbox
cd Sandbox
New-Item datei.txt | Set-Content -Value "Das ist mein Hello World" -encoding UTF8
git status
git add .
git commit -m "Init Repo" 

Wir haben nun unser lokales Repository

Remote Repository

Jetzt müssen wir ein Remote Repository erstellen. Für Powershell Scripte reicht hierfür z.b. ein Gitea Webservuce. Ein leichtgewichtiger GIT Service der auf fast jeder Plattform läuft. So kann man ihn auf Linux wie Ubuntu oder PhotonOS installieren oder auch aber als Windows Service. Bei mir läuft er als Docker-Image auf meinem NAS oder PhotonOS in einer VMware Infrastruktur. Git with a cup of tea. A painless self-hosted Git service. Gitea is a community managed lightweight code hosting solution written in Go

Wir erstellen nun eine Organisation Sandbox und ein leeres Repository mit Namen Sandbox:

Lokales und Remote Repository verheiraten

Jetzt müssen wir unserem lokalen Repository sein Remote-Repo bekanntmachen. Mein Git-Server ist im lokalem Netz mit http://git.lan erreichbar:

C:\repos\Sandbox [master]>git remote add origin https://git.lan/Sandbox/Sandbox.git
C:\repos\Sandbox [master]>git push -u origin master

Neu hat nun das Repo ein Gleichheitszeichen nach dem Branchnamen:

c:\repos\Sandbox [master ≡]>

Commit mit Push zum Remote Server

Wir ändern lokal die Datei:

C:\Repos\Sandbox [master ≡]> vim .\datei.txt

Fügen die Dateien zum Stage hinzu

C:\Repos\Sandbox [master ≡ +0 ~1 -0 !]> git add .
C:\Repos\Sandbox [master ≡ +0 ~1 -0 ~]> git commit -m "version 3.0"
[master 250ae68] version 3.0
 1 file changed, 1 insertion(+) 

Jetzt ist aus dem Gleichheitszeichen ein Pfeil nach oben. Somit wird signalisiert das eine Datei bereit ist zum Server gepusht werden kann:

D:\Repos\Sandbox [master ↑1]>

Nun können wir git push durchführen:

c:\Repos\Sandbox [master ↑1]> git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 271 bytes | 271.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: . Processing 1 references
remote: Processed 1 references in total
To https://git.lan/Sandbox/Sandbox.git
   23f1064..250ae68  master -> master
c:\Repos\Sandbox [master ≡]>

Wir sehen zum Schluss wieder ein Dreifach-Gleichheitszeichen das alle Daten wider synchron sind.

Somit haben wir nun 2 gleichwertige Versionen, eine lokale und eine auf dem Server.

Git Credential, oder ich weiss wer du bist

Es kann irgendwann mühsam jedes mal das Passwort bei einem git push einzugeben. Es gibt verschiedene Varianten wie man das Passwort beim Benutzer hinterlegt. Mit folgenden Befehlen kann dieser konfiguriert werden:

Use Cases

Jetzt wo wir eine Repoinfrastruktur haben, können wir verschiedene Prozesse abbilden die aus der Softwareenticklung typisch sind. Ich habe einige einfache Beispiele hier zusammengetragen:

Die Kopie des Repo hohlen

Ein neuer Admin will mit dem Repository arbeiten. Bevor er beginnen kann muss er das Repo herunterladen. Mit dem clone Befehl ist dies sehr schnell erledigt:

C:\repos\Sandbox [master]>git clone https://git.lan/Sandbox/Sandbox.git
Cloning into 'Sandbox'...
remote: Enumerating objects: 24, done.
remote: Counting objects: 100% (24/24), done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 24 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (24/24), done.
Resolving deltas: 100% (2/2), done.
c:\Repos> cd .\Sandbox\
c:\Repos\Sandbox [master ≡]>

Zum Schluss haben wir nun wiederum ein gleichwertiges Repository

Version B, lokaler Hotfix

Wir wollen nun einen lokalen Hotfix machen, d.h. eine Version B. Mit checkout erstellen wir eine 2te Version unseres Repos den wir "hotfix" nennen. Danach verändern wir wie gewohnt die Datei und machen einen zum Schluss ein Commit:

c:\Repos\Sandbox [master ≡]> git checkout -b "hotfix"
Switched to a new branch 'hotfix'
c:\Repos\Sandbox [hotfix]> vim .\datei.txt
c:\Repos\Sandbox [hotfix +0 ~1 -0 !]> git add .
c:\Repos\Sandbox [hotfix +0 ~1 -0 ~]> git commit -m "Version B"
[hotfix 237d72c] Version B
 1 file changed, 1 insertion(+), 1 deletion(-)
c:\Repos\Sandbox [hotfix]> 

Der Hotfix wurde getestet und wollen nun den Hotfix wiederum in den master eingliedern. Dafür wechseln wir wieder in den master:

c:\Repos\Sandbox [hotfix]> git checkout master
c:\Repos\Sandbox [master ≡]>

Damit man den Hotfix in den Master einpflegt muss man "mergen":

c:\Repos\Sandbox [master ≡]> git merge "hotfix"
Updating 250ae68..237d72c
Fast-forward
 datei.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
c:\Repos\Sandbox [master ↑1]> 

Das Repo merkt das die Daten zum Remote Server nicht mehr gleich sind. Wir erledigen das wiederum mit git push:

c:\Repos\Sandbox [master ↑1]> git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 311 bytes | 311.00 KiB/s, do
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
remote: . Processing 1 references
remote: Processed 1 references in total
To https://git.lan/Sandbox/Sandbox.git
   250ae68..237d72c  master -> master
c:\Repos\Sandbox [master ≡]>

Zum Schluss kann man den Hotfix wieder aufräumen und den Branch Löschen:

c:\Repos\Sandbox [master ≡]> git branch -d "hotfix"
Deleted branch hotfix (was 237d72c).

Dieser Hotfix ist nur "Lokal" erstellt worden. Die anderen Repos merken davon nichts.

Zusammfassend haben wir einen lokale Version B erstellt und habe sie dann lokal gemergt und dann auf den Remote Server einen push gemacht.

Version C, auf zu neuen Ufern

Wir wollen dieses mal einen Hotfix C machen und diesen aber Remote dem ganzen Team zu verfügung stellen. Wir erstellen wieder einen neuen Hotfix und machen einen Commit für Version C:

c:\Repos\Sandbox [master ≡]> git checkout -b "hotfixC"
Switched to a new branch 'hotfixC'
c:\Repos\Sandbox [hotfixC]> vim .\datei.txt
c:\Repos\Sandbox [hotfixC +0 ~1 -0 !]> git add .
c:\Repos\Sandbox [hotfixC +0 ~1 -0 ~]> git commit -m "Version C"
[hotfix 237d72c] Version C
 1 file changed, 1 insertion(+), 1 deletion(-)
c:\Repos\Sandbox [hotfixC]>  

Jetzt wollen wir dies aber auch am Remote Server bekannt machen:

git push -u origin hotfixC

Jetzt haben wir auf dem Remote Server neu einen Hotfix Branch:

Diesen können nun die anderen Teammitgleider wieder herunterladen oder wir können später dann mit einem Pull Request wieder in den Master mergen.

Ausblick: Visual Studio Code und Git

Wir haben bisher nur über die Commandline die git-Befehle abgearbeitet. Mit einem IDE (integrated development) können sehr viele Produkute schon von Haus aus mit GIT umgehen und vereinfachen das Commit und Push um einige faktoren.

Mit Visual Code hat Microsoft sehr viel richtig gemacht. So ist GIT schon von beginn weg untestützt und man musste nichts mehr installieren. Im Versionskontroll Menü kann man direkt einen Commit ausführen:

Ähnlich wie bei Powershell (posh-git) wird hier ein Push angezeigt. Mit einem simplem Klick wird der push ausgeführt:

Das sind nur die einfachsten Befehle im Visual Code. In einem späteren Beitrag werde ich mehr darauf eingehen.