GIT und GitHub

Wer Software entwickelt, behebt Fehler und sollte über Versionierung und Dokumentation dies nachvollziehbar machen. Wenn dann noch mehrere Personen an dem gleichen Projekt kooperativ arbeiten, ist eine Softwareverwaltung unersetzbar. Das gilt erst recht auch für Consultants, Administratoren, die kleine Skripte und Codes in PowerShell, VBA Makros, CMD-Files oder VBScript schreiben.

Beachten Sie dazu auch die Seite Git für Administratoren und Consultants

In der kommerziellen Microsoft Welt wird meist mit Visual Studio entwickelt und der Team Foundation Server entwickelt, in der Linux-Welt gab es schon früh Systeme wie Subversion u.a. Aber mittlerweile scheint GIT der Platzhirsch zu sein.

GIT gäbe es in der Form wohl nicht, wenn sich Linus Torvald und seine Mitentwickler nicht über die ein oder andere Unzulänglichkeit ihres bisherigen Versionskontrollsystems geärgert hätten und 2005 die Firma BitKeeper nicht noch die kostenloste Lizenz dem Team entzogen hätte. Also macht man es selbst und so entstand GIT. GitHub hingegen ist ein Anbieter, der das Hosting von Repositories anbietet.

Wer keinen eigenen "Versionsserver" betreiben will, findet im Internet mit GitHub, Office 365 oder Sourceforge und anderen entsprechende Anbieter, die über Open Source Projekte den Platz oft kostenfrei hosten. Nutze müssen natürlich die Werbung ertragen und wer "closed Source" dort verwalten will, muss auch zahlen.

Seit Anfang 2019 kann jeder kostenfrei auch private GIT Repositories starten. Es gibt nur eine Beschränkung auf 3 Mitglieder. Wer mehr Helfer einbinden will, braucht ein Abonnement. Ich bin mal gespannt, ab wann das in Office 365 als Option auftaucht.

Sie können aber ebenso ein Quellcodeverwaltung in Azure DevOps für bis zu 5 Benutzer kostenfrei hosten.

Brauche ich das?

Ja, sie werden GIT brauchen und vielleicht auch GitHub nutzen, weil immer mehr Dienste, z.B. docs.microsoft.com letztlich auf GitHub gehostet sind. Zudem werden auch Consultants und Administratoren immer mehr Code schreiben und eine geordnete Ablage benötigen.

Sie arbeiten erst einmal weiter mit ihren Dateien auf ihrem Dateisystem. Aber mi GIT können Sie die Änderungen nachhalten und einen Stand auf ein GIT-Ziel legen. Dabei erstellt GIT aber keine komplette Kopie sondern ermittelt die Dateiunterschiede. Die aktuelle Datei wird immer komplett abgelegt und zusätzlich werden in einem Change-Journal die Änderungen zur vorherigen Version dokumentiert. Quasi eine Speicherung der Rückwärtsänderung. Sie können also auch wieder zurück. Auf einer öffentlichen Folie von Microsoft wurde ein "Microsoft loves Open Source" verkündet.

Interessant finde ich dabei, dass Microsoft angeblich schon 2017 den Windows Sourcecode mit Git verwaltet.

Vereinfachte Funktionsweise

Ich habe mehrfach versucht die Funktionsweise zu verstehen und auch wen Sie recht einfach erscheint, ist es für einen Consultant vielleicht nicht auf Anhieb immer klar, wie die Versionierung funktioniert. Ich bin nämlich davon ausgegangen, dass ein zentraler Server die Daten vorhält und ich per "Checkout" eine Kopie auf meinen Computer hole und diese andere. Wenn ich dann einen "Commit" mache, dann war das für mich ein "Upload" meiner lokalen Änderungen wieder auf den zentralen Punkt. GIT funktioniert aber anders. Jeder Client ist seine eigene lokale Verwaltung von Versionen.

Jedes Repository ist dabei einfach nur ein Verzeichnis, indem es eine versteckte Unterstruktur gibt.

Ich habe ein leeres Verzeichnis "C:\Mein Projekt" angelegt und mit "git init" darin die GIT-Verzeichnisse anlegen lassen. Diese sind verborgen und sollten mich daher eigentlich nicht stören. Ich kann nun unter "C:\Mein Projekt" mit den Hilfsmittel meiner Wahl (Notepad, Word, Excel, Visual Studio, Visual Code u.a.) Dateien jeglicher Art in selbst vorgegebenen Ordnerstrukturen anlegen. und verwalten. Noch passiert hier nichts. Erst wenn ich den aktuellen Stand dann "sichern" will, dann mach ich einen "Commit", mit dem die Änderungen dann in mein Repository übertragen werden. Das ist natürlich irgendwo unter ".git".

Interessant wird GIT aber nun, wenn ein entferntes Repository dazu kommt. Ich kann über einen "CLONE" quasi alles aus dem entfernten Repository in ein neues "leeres" Verzeichnis klonen. Das können schon einige Gigabyte werden, wenn das Projekt größer ist. Es sind auch alle Versionen und Kommentare etc. enthalten. Daher ist es wichtig, dass der Owner z.B. über IGNORE-Vorgaben die Dateien aus dem Repository ausschließt, die nicht relevant sind, d.h. Logfile, temporäre Dateien etc. Es bietet sich an auch über Verzeichnisstrukturen z.B. solche Dateien separat zu speichern. Sie können aber auch einfach nur den "master" synchronisieren um etwas Platz zu sparen.

Wenn ich lokal Daten verändert habe und diese per COMMIT bei mir lokal schon mal samt Beschreibung gesichert habt, dann kann ich diese auch über ein "PUSH" zu einem anderen Repository übertragen. Größere Umgebungen trennen hier noch ein "PUSH REQUEST" ab, bei dem meine Änderungen nicht sofort im Ziel aktiv geschaltet werden sondern erst durch einen Maintainer zugelassen werden.

Aktion Quelle Ziel Beschreibung

init

kein

Lokales Repository

Neues leeres GIT Repository anlegen

C:\>md gitdemo

C:\>cd gitdemo

C:\gitdemo>git init
Initialized empty Git repository in C:/gitdemo/.git/

clone

Remote Repository

Lokales Repository

Initialer Full Download des Repositories auf mein System (mit allen Versionen)

Rem Entferntes Repository in den aktuellen Pfad kopieren
git clone Username@host:/path/to/repository

Sie können natürlich auch einfach ein "lokales Repository" clonen. Sie haben dann die Dateien quasi "doppelt"

REM Aktuelles Repository 
git clone /path/to/repository

REM Beispiel mit Quelle und Ziel
git clone --v 'C:\Mein Projekt\.git' C:\git2\

Pull

Remote Repository

Lokales Repository

Differenzieller Download auf mein System

Commit

Dateisystem

Lokales Repository

Übernehmen lokaler Änderungen in das lokale Repository. Kommentare sind erwünscht

Push oder Push Request

Lokales Repository

Remote Repository

Einchecken der Änderungen in ein entferntes GIT-Repository

Das sind erst mal die Basis-Befehle. Ich selbst nutze eigentlich nur die "blaue" Pfeile". Ein "Pull", um eine Kopie des Masters eines Repository auf meinen PC zu übertragen und damit zu arbeiten. Wenn ich was geändert habe, dann muss ich die Änderungen in meinen Stage-Bereich übernehmen und beim Commit einen Kommentar hinterlegen. So habe ich eine neue Version bei mir. Wenn ich mit mehreren Personen zusammenarbeite, dann sollte ich meine Änderungen über einen "Push" auch zentral bereitstellen.

Bei Konflikten muss ich eventuell die Änderungen der anderen Kollegen per Pull aus dem Repository übertragen, beim Merge die Konflikte lösen und erst dann wieder ein Push machen.

Oft dürften Sie gar nicht in ein zentrales Repository schreiben und damit den Master-Code kaputt machen. Bei größeren Projekten legen Sie ich einen "Fork" des Hauptprojekts an und können dann bei sich als Teil-Team weiter arbeiten. Wenn Sie dann ein Feature fertig gestellt haben, dann könne Sie einen "Pull Request" des Maintainers anfragen, der dann ihre Änderungen aus ihrem Fork nach einer Prüfung in das Hauptprojekt übernimmt.

Es gibt noch viel mehr Befehle und Optionen, z.B.: um Änderungen im Log nachzuschauen (LOG), eine irrtümliche lokale Änderung wieder durch die Version auf dem Server zu ersetzen (FETCH) u.a. Das Bild und die Beschreibung sind auf einen Client mit einem Server abgestimmt. Zum spielen und testen brauchen Sie aber erst mal GIT auf ihrem PC

git windows download
https://git-scm.com/download/win

Fork statt Mirror

Nicht alle Repositories erlauben ihnen auch ein direktes Rückschreiben. Dazu zählt auch docs.microsoft.com. Hier müssen Sie sich erst quasi eine "Kopie" in Form eines Fork anlegen. Ein Fork ist natürlich eine komplette 1:1 Kopie, auch wenn es erst mal so aussieht. Technisch ist es zwar ihre Instanz aber Sie bleibt mit der Quelle verbunden.

Mit dem Fork können Sie nun arbeiten, als wenn es ihr komplett persönliches System ist. Sie können sich über ein Update auch immer wieder neuere Versionen der eigentlichen Quelle holen. Wenn Sie dann aber eine größere Änderung umgesetzt und in ihrem Repository abgelegt haben, dann können Sie den Owner des originalen Repository bitten, diese Änderungen aus ihrem Repository per "PULL" zu holen. Microsoft hat das ganz nett beschrieben.

Kleinere Änderungen können Sie aber auch direkt umsetzen:

Synchronisation

Aber es braucht nicht viel Phantasie um das Potential zu erkennen, wenn mehrere Personen miteinander am gleichen Projekt arbeiten und sich alle gegenseitig abgleichen. Synchronisiert wird immer zwischen zwei GIT-Repositories. Da aber jeder Client zugleich auch Repository ist, sind unterschiedliche Ansätze denkbar.

  • Abgleich zweier Repositories

    Das ist durchaus denkbar, wenn zwei Personen miteinander komplett "dezentral" Dateien gemeinsam nutzen wollen, von denen jeder eine komplette Kopie ist. GIT ist hier einfach ein leistungsfähiges "Versionsverwaltungswerkzeug" und "Synchronisations-Engine".
  • Abgleich über zentrales Repository

    Dieser Weg ist eher in Firmen oder größeren Teams zu sehen, die einen zentralen Austauschpunkt betreiben oder per Hosting betreiben lassen, der idealerweise überall und 24x7h erreichbar ist. Es gibt mehrere solcher Provider und GitHub (2018 von Microsoft gekauft) ist sicher einer der größeren Anbieter. Sie können aber auch lokal ihren eigenen GIT-Server (z.B: GitLab) installieren.
  • kleines Team per N:M

    Diese Konstellation ist zwar eher ungewöhnlich aber kommt ohne zentrale Instanz aus, wenn alle System sich irgendwie abgleichen. Ein Sync kann auch über mehrere Stationen als Relay gehen, d.h. der linke und rechte Client müssen gar nicht direkt miteinander kommunizieren, wenn beide mit dem mittleren System sprechen.
  • Abgleich über mobile Anwender

    Gerade bei Consultants ist es oft so, dass ich für einen Kunden arbeite, der sein eigenes GIT hat aber ich natürlich die Arbeit beim Kunden auch bei mir in der Firma "sichern" will. Auch das ist möglich, weil jedes Repository mit jedem anderen repliziert werden kann. Ich kann also die beiden Repositories, beim Kunden und meinem Notebook synchron halten. Wenn ich dann wieder im Office bin, kann ich mein lokales Repository auch mit dem GIT bei mir abgleichen. Mein Notebook ist quasi "Transporter" für den Abgleicht von zwei Repositories, die sich nicht direkt erreichen können.

Es gibt also eine ganze Menge von Replikationsmöglichkeiten, mit denen ich jedes in sich eigenständige Repository mit einem anderen Repository abgleichen kann. Das ganze ist auch per Kommandozeile möglich und kann damit als Task automatisiert werden.

Datenmenge

Alle Versionen auf Vorrat und auf vielen PCs und alles synchron? Da muss die Frage nach dem Datenwachstum erlaubt sein. Ich habe daher mal eine kleine Testserie gemacht.

Achtung: GIT ist bei den Parametern "casesensibel". Zur besseren Lesbarkeit habe ich die Zeilen umgebrochen.

Aktion Beschreibung Datenmenge 

git 
  --version

Zeigt die aktuell installierte Version von GIT an

keine

 

 
md "c:\Mein Projekt"
git init

Anlegen eines leeren Repository auf meinem Notebook

8 Ordner
14 Dateien
15,3KB

40Kb-File.txt anlegen

Ich habe in dem Verzeichnis eine Datei "C:\Mein Projekt\40kbfile.txt" angelegt

9 Ordner
15 Dateien
55,1KB

 
git 
  add 
  .

Datei im GIT zur Überwachung registrieren. beachten sie den "." als Referenz auf das aktuelle Verzeichnis.

10 Ordner
17 Dateien
68,7KB

 
git 
  commit
  -m "Kommentar1"

Die aktuelle Datei als "Version" einstellen.

Achtung: Wenn Sie keinen Kommentar öffnet, dann startet GIT den Editor VI, mit dem Sie den Kommentar eingeben müssen.

15 Ordner
23 Dateien
69,2KB

 
git 
  remote 
  add 
  origin 
  "c:\Mein Git"
git`
  remote 
  add 
  origin 
  https://gitserver:443/MeineProjects

Das entfernte Repository als mögliches Synchronisationsziel addieren. Ich habe hier einfach ein anderes Verzeichnis als Gegenstelle genutzt.

Das zweite Beispiel zeigt die Nutzung eines GIT per HTTPS

15 Ordner
23 Dateien
69,2KB

 
git 
  push 
  --set-upstream 
  origin 
  master
git 
  push 
  -u origin 
  --all

Das lokale Repository in das Ziel übertragen.

15 Ordner
23 Dateien
69,2KB

Das Repository wächst zwar mit der neuen Datei aber der ADD, um die Datei auch zu überwachen und der COMMIT zur "Speicherung" einer Version addiert nur noch Metainformationen. Das bedeutet aber auch, dass ich die Datei nun nicht einfach "löschen" darf. Sie wäre dann nicht aus dem GIT wiederherstellbar. Erst der "PUSH" in ein anderes Repository überträgt die Daten letztlich in das Ziel.

Sie können GIT auch anweisen, dass er nur die aktuellste "Last Version" synchronisiert, indem Sie "GIT clone git clone --depth=1 ......" verwenden

Mit den gleichen Schritten können Sie ein lokales Verzeichnis oder eine Verzeichnisstruktur zu einem Git-Repository "aufwerten und dann auf einen Server kopieren. Genauso gut können Sie aber auf einem Server auch ein neues Repository einrichten, dieses dann lokal replizieren und ihre Bestandsdateien dort einführen. Einige Server erlauben auch den Import von Dateien z.B. per Browser.

Ignore-Dateien

Wenn ich mit PowerShell arbeiten, dann sammeln sich in meinem Projektverzeichnis nicht nur die PowerShell-Skripte, Konfigurationsdateien u.a. Dateien. Ich schreibe natürlich auch Ausgabedateien (z.B. CSV-Dateien) und Traces (Transcript) etc. Diese Dateien ändern sich mit jedem Durchlauf aber sind für die Source-Verwaltung natürlich nicht relevant. Sie stören sogar eher, da GIT jede Änderung erkennt und ich beim Commit die Änderungen begründen muss. Daher ist es sinnvoll all die Dateien oder Verzeichnisse aus der Überwachung auszuschließen, die gar nicht erst durch GIT überwacht und später auch noch eingecheckt und repliziert werden.

Die Konfiguration kann sowohl global für den Host als auch pro Repository oder Verzeichnis erfolgen. Dazu werden Dateien mit den Namen ".gitignore" auf dem Basisverzeichnis oder auch Unterverzeichnissen angelegt, in denen dann die Ausschlüsse definiert werden. So könne eine solche Datei aussehen, um das Verzeichnis "\log", "\trace" und einige Dateientypen auszuschließen:

# .gitignore-Datei im Repository Root
# ignore some temporary file types
*.tmp
*.bak
*.log
*.zip

# certain subdirectories
project1/log
project1/trace

#ignore special files
project1/passwords.txt

So kann die Datenmenge dann reduziert werden.

Arbeiten mit Visual Studio Code

Sie könne natürlich mit Notepad++ auf einem lokalen Dateisystem arbeiten und per Kommandozeile sich mit dem zentralen Repository verbinden. Viel interessanter ist es aber einen Editor zu nutzen, der direkt mit GIT kommunizieren kann. Ein kostenfreier und leistungsfähiger Editor ist Visual Studio Code.

Ich habe also einfach das Verzeichnis "C:\Mein Projekt" geöffnet und im Dokumentexplorer sehe ich sofort die Datei.

Ich kann die Datei öffnen und ändern, was direkt sichtbar wird

Wenn ich die Datei speichere, dann ist sie nur noch geöffnet aber wird weiter als "modifiziert" angezeigt:

Wenn ich dann auf die GIT-Seite gehe, sehe ich direkt die beiden Versionen nebeneinander und über das Context-Menü kann ich entsprechende Aktionen auslösen.

Über ein weiteres Menü können Sie auch den COMMIT ausführen u.a.

GIT bei Microsoft

Am 4 Juni 2018 wurde bekannt gegeben, dass Microsoft bei GitHub groß einsteigt bzw. den ganzen Laden aufkauft.

Ich habe mir schon länger überlegt, wie Microsoft zukünftig damit umgehen wollte, wenn komplette Dokumentationen von Microsoft auf GitHub liegen. Wenn Sie sich mal die Webseite https://docs.microsoft.com anschauen, dann finden Sie auf den einzelnen Artikeln direkt den Link zum Bearbeiten auf GitHub. Wenn Sie z.B. auf https://docs.microsoft.com/en-us/dotnet/framework/wpf/index gehen, dann verweist der EDIT-Link auf https://GitHub.com/dotnet/docs/blob/master/docs/framework/wpf/index.md

Das ist nicht nur bei der Dokumentation sondern auch in Code-Teilen der Fall. Selbst der Team Foundation Server, einer der ureigenen Sourcecode-Verwaltungstools spricht "GIT" als zusätzliches Protokoll.

Und ein eigener Teil in docs.microsoft.com widmet sich dem Umgang mit GIT selbst

Hier eine Auswahl weitere Links, die jedem Entwickler schon früh angezeigt haben, dass Code am besten in GIT verwaltet wird.

GIT und PowerShell

Eigentlich braucht man keine weiteren Module zur Steuerung von GIT. Entweder ist die Funktion im Editor wie Visual Studio Code schon enthalten oder Sie nutzen direkt die Kommandozeile von GIT. Dennoch gibt es auch ein Modul für Powershell, welches quasi die Befehle kapselt.

POSH Kit für Git
https://GitHub.com/dahlbyk/posh-git

GIT auf NAS (Synology u.a.)

Oben habe ich als Beispiel ein lokales auf ein weiteres lokales Repository kopiert. Das macht natürlich keinen Sinn und dupliziert nur Dateien. Sie brauchen also einen GIT-Server und wenn Sie nicht gleich bei GitHub einen kostenfreien Account für Open Source für ihre Daten nutzen oder einen eigenen Server aufsetzen wollen, dann schauen Sie doch einfach mal auf ihr NAS-System. GIT als Repository kann auch auf dem ein oder anderen NAS-System sehr schnell installiert werden. Hier habe ich mal meine billige Synology DS216j (unter 200€ ohne Festplatten) genutzt. Sie brauchen im Paketzentrum einfach nur nach "GIT" zu suchen.

Eine weitere Beschreibung spare ich mir. Es gibt massenhaft Blogs dazu wie z.B.

Scope und Rechte

GIT ist relativ einfach. Es gibt einfach nur Repositories in denen Dateien und Verzeichnisse liefen. Es ist meines Wissens nach nicht vorgesehen, dass man nur Teile eines Repository repliziert oder über Berechtigungen Anwendern nur Zugriff auf einen Teil der Dateien in einem Repository gibt. Für mich entspricht dies dem alten Prinzip der SMB-Freigaben mit FAT-Dateisystem. Die Rechte auf dem "Share" sind die einzige Steuerung. Übrigens ist das auch für SharePoint Team Sites, Microsoft Teams-Teams und viele andere Systeme so. Genau genommen reicht es ja auch und es würde die Zusammenarbeit ja auch nur erschweren, wenn auch noch Rechte den Zugriff blockieren.

Das bedeutet aber auch, dass eben jeder mit Zugriff auf das Repository auch alles sehen und ändern kann. Ändern ist so erst mal kein Problem, denn Dank der Versionierung und dem Change Logging kann der Manager auch Änderungen wieder rückgängig machen und den Benutzer identifizieren. Über die Steuerung von "Requests" kann man ein Einchecken auch noch mal vorab sichten. Nur die Funktion, dass jemand den Code quasi "kopieren" könnte, dürfte für die ein oder andere Sorge führen.

Bei diesem Thema bin ich mir nicht sicher, ob das noch stimmt. Ich bin nun mal ein Repository Admin oder Maintainer sondern nutze einfach die Funktion in meiner kleinen überschaubaren Umgebung ohne allzu viele Berechtigungen

Auf GIT-Hub können Sie daher problemlos mehrere Repositories anlegen, um unterschiedliche Projekte auch Administrativ zu trennen

So nutze ich GIT/GitHub

Wenn Sie schon länger mit der MSXFAQ arbeiten, dann wissen Sie, dass ich als Webseite den Sharepoint Designer 2007 verwende, der im Hintergrund auf einem Dateisystem arbeitet. Das kann ich per GIT einfach auf ein Server-Repository ablegen, so dass ich ein Backup und Versionen habe. Allerdings muss ich etwas aufpassen, das einige Änderungen gleich sehr viele Seite anpassen und damit die Version etwas überladen ist. Aber vielleicht migriere ich die MSXFAQ irgendwann ja mal auf ein andere System basierend auf Markdown und Offline-Generatoren.

Zudem erstelle ich immer wieder PowerShell-Skripte für meine Kunden und mich. Sind Sie es nicht auch langsam satt, die "Versionierung" von Hand zu machen, indem Sie die Datei umbenennen und mit einer Versionsnummer oder einem Datum versehen? Dann ist es Zeit ihre Skripte über GIT zu verwalten.

Sie müssen nun nur noch überlegen, ob sie ein großes Repository machen, in dem es für jedes Skript ein Unterverzeichnis gibt oder ob sie wirklich für jedes Skript ein eigenes Repository starten wollen. Die Frage ist durchaus interessant, denn wie bedienen Sie einen Kunden, der auch ein GIT betreibt und bei dem sie das ein oder andere Skript einsetzen? dann wäre es doch nett, wenn Sie die Skripte zwischen dem Kunden GIT, dem Job-Server beim Kunden, der Entwicklungsumgebung auf ihrem Notebook und dem GIT in ihrer eigenen Firma abgleichen könnten. Hier wäre ein eigenes Repository wohl einfacher.

Aber wie lösen Sie dann den Konflikt, wenn Sie das gleiche Skript bei mehreren Kunden einsetzen und jeder Kunde seine eigene Version weiter entwickelt. Das käme dann einem Branch gleich. Dann wird es schon kniffliger, denn vielleicht wollen Sie die unterschiedlichen Zweige nie zusammenführen. vielleicht nutzen Sie aber auch Codeteile gemeinsam, bei denen ein Bugfix bei einem Kunden auch beim anderen Kunden vielleicht sinnvoll einzusetzen wäre. Oder wird auch diese gemeinsam genutzte Komponente gleich zu einem eigenen Repository?

Hier müssen Sie wirklich überlegen, wie Sie sich mit den Repositories und dem Abgleich organisieren.

Ich bin aber zu wenig "Entwickler", um diese Detailfragen hier klären zu können.

Aktuell bin ich "Maintainer" meiner Skripte und aus dem alten "/Skripte"-Verzeichnis auf einem Dateiserver wird einfach ein Repository. Kopien, die dann für einen Kunden ausgekoppelt werden, finden Sie beim Kunden und als Art "Snapshot" bei mir. Aber die Skripte beim Kunden landen als "letzter Stand" einfach dort, wo auch die anderen Kundendokumentationen sind.

Ich versuche aber immer mehr die Skripte "unabhängig" zu schreiben und speziell Konfiguration von Kunden einfach als eine Art "CONFIG-Datei (Siehe PowerShell Parameter) abzulegen.

Weitere Links

GitHub Tutorial without using the Command Line
https://www.youtube.com/watch?v=tCuPbW31vAw&ab_channel=AndreasSpiess