====== Allgemeine Verwendung von GIT ======

GIT ist der heutige Standard in Sachen Versionierung, wohl muss man aber sagen, dass auch Subversion hier immer wieder ausreichen würde. Wie Subversion ist hier GIT mittlerweile mit GIT for Windows, TortoisePlink und TortoiseGIT gut in die Windows Landschaft integriert.

Um in Sachen GIT also zu starten empfehlen sich folgende Programme:

  * Git für Windows (die Basis auch für TortoiseGIT notwendig): https://git-scm.com/install/windows
  * TortoiseGIT (der ShellClient für Windows): https://tortoisegit.org/download/

Wichtig: anders als bei TortoiseSVN ist hier der GIT Client schon ein Grundelement und in der Regel immer notwendig.

===== Den richtigen GIT Anbieter wählen =====

Wie immer hier Geschmacksfrage. Microsoft hat ja GitHub vor einer halben Ewigkeit erworben. Im letzten Jahr aber einmal angekündigt auch die Inhalte der Plattform für das KI-Training zu nutzen. Das hat natürlich ein Für/Wider. So manches Projekt hat also hier schon einmal beschlossen der Plattform wieder den Rücken zuzukehren. GitHub hat wie Atlassian BitBucket auf jeden Fall Schnittstellen für die Automatisierung rund um die Repositories (automatisierte Erstellung)

Alternativen wären:

  * BitBucket (Atlassian): hier ist halt ebenfalls die Frage, ob hier Atlassian nicht einen gleichwertigen Move wie Microsoft irgendwann mal durchzieht, wobei, sie müssten es ja nicht. Die Einnahmen aus den Hauptprodukten wie JIRA, Confluence und Co. müssten ja reichen.
  * Codeberg
  * Gitea

===== Eigener GIT Server =====

Auch ein eigener GIT Server kann hier in Betracht gezogen werden. Die Frage ist hier aber, ob man sich das wirklich antun möchte:

  * https://git-scm.com/book/de/v2/Git-auf-dem-Server-Git-auf-einem-Server-einrichten
  * https://www.reddit.com/r/selfhosted/comments/1375clj/git_server/

===== ELO und Entwicklungsstandards =====

ELO verwendet hier für seine Business Solutions anscheinend einen Mechanismus in Verbindung mit GitHub, der aber dem normalsterblichen Partner eher nicht wirklich zugänglich und bekanntgemacht ist. Vielleicht muss er hier dann Teil des inneren Solution-Zirkels sein. ISSP legt hier allerdings auch äußerst wenig wert hier Teil des Ganzen zu sein, da hier dieses Javagescripte nie unser Ding gewesen ist. Wir haben das schon zu JavaClient Zeiten nicht sonderlich gemocht, hier war immer unser Weg JAR Dateien in abzuleiten und in den JavaClient einzubetten. Das ermöglichte einerseits die Wiederverwendung von Code in Modulen, andererseits auch die feste Kompilierung gegen einen Client. Des einen Freud ist natürlich wiederum des anderen Leid. Wenn hier andere Entwickler an diese Lösungszweige hinzugefügt werden, weicht dies dann natürlich vom "Armutsstandard" der Scripter ab und sie wirken halt wie verlorene Schuljungen im Dunkelwald, weil sie dann nicht mehr wissen, wo im Script sie dies und jenes nachlesen oder korrigieren können.

==== ELO und GIT ====

Wenn man also ELO Solutions "gitten" möchte, dann bleibt hier einerseits die Variante den inneren Zirkel durch eine Solution Schulung zu betreten und Kontakte zu knüpfen, um vielleicht an die ELO Internas ranzukommen. Vielleicht wird man dort allerdings ernüchtert und dann auf das dem entsprechende Partnerprogramm verwiesen.