Quellcodeverwaltung git

Bei der Quellcodeverwaltung git handelt es sich um ein dezentrales Quellcodeverwaltungssystem. In der TSO-DATA wird es mittelfristig das primär verwendete System zur Verwaltung von jeglicher Art Code. Nähere Informationen zu git gibt es unter git-scm.com. Serverseitig wird in Osnabrück Azure DevOps von Microsoft verwendet, in dem für die jeweiligen Projekte ein entsprechender git Server bereitgestellt wird.

Installation

Git muss auf der lokalen Maschine installiert werden. Unter git downloads kann die jeweilige aktuelle Version heruntergeladen werden. Bei den Einstellungen können die Standardwerte übernommen werden. Bei der Auswahl der Standardeditors ist Visual Studio Code zu verwenden.

Terminologie

Um sich mit git vertraut zu machen, ist es empfehlenswert sich ein paar Grundlagen unter 1 anzulesen (Stand Juni 2019: Kapitel 1 und 2). Außerdem ist hier eine Aufzeichnung aus dem NEM gespeichert, bei dem über Git Grundlagen gesprochen wurde.

Im folgenden werden aber auch hier einige Begriffe aufgeführt, die im git Umfeld wichtig sind:

Repository

Das Repository ist der Aufbewahrungsort für den Code. In einem Repository kann der Code von beliebig vielen Programmen, Apps, Dlls, AddIns, Plug-Ins etc. verwaltet werden. Es empfiehlt sich aber für verschiedene Programme separate Repositories zu verwenden. In Azure DevOps können je Projekt beliebig viele Repos genutzt werden, wobei nur diejenigen darauf Zugriff haben, die die entsprechenden Rechte für das Azure DevOps Projekt haben.

Cloning

Um mit dem Quellcode in einem Repository arbeiten zu können, muss dies am Anfang einmal auf das lokales System übertragen werden. Dieser Vorgang wird als "Cloning" bezeichnet. Später werden mit anderen speziellen Befehlen dann nur noch die inkrementellen Änderungen zwischen Server Repo und dem lokalem Repo übertragen.

Dezentral und Remote

git ist ein dezentrales System und kommt theoretisch ohne Server aus. D.h. jeder Entwickler hat eine vollständige lokale Version eines Repositories inklusive der kompletten Änderungshistorie. In einer Multientwickler-Umgebung ist aber sinnvoll einen zentralen Server zu nutzen, in dem der Code zusammengeführt wird. Damit kann er für weitere Prozesse (Deployment etc.) verwendet werden. Das Server Repo wird dabei als Remote bezeichnet.

Stage und Commit

Alle Änderungen an den lokalen Dateien werden von git erkannt und werden z.B. in VS Code visuell dargestellt. Um die Änderung verbindlich zu machen, müssen diese committet werden. Alle Änderungen, die committet werden sollen, müssen vorher gestaged werden, d.h. es kann auch nur eine Auswahl aller aktuellen Änderungen committet werden. Die committeten Änderungen werden zu einem Commitset zusammengefasst und sind durch einen eindeutigen Hash identifizierbar (Commit ID). Es ist jederzeit möglich den Stand eines beliebigen Commits wieder herzustellen, wenn z.B. Änderungen fälschlicherweise gemacht wurden.

Datenspeicherung

Die Versionshistorie des Repository wird durch eine verkettete Liste von Commits gespeichert. Dabei enthält jedes Commit nur die Änderungen gegenüber des vorigen (parent) Commits. Ein beweglicher Zeiger, der auf einen Commit aus der verketteten Liste zeigt, definiert den Versionsstand auf den sich das lokale Repository befindet. Beim Committen wird der Zeiger automatisch auf den neuen Commit gesetzt. Ein Branch ist nur ein weiterer Zeiger, der auf einen bestimmten Commit aus der verketteten Liste zeigt.

Push

Befehl um lokale Commits in das Server Repo (Remote) zu übertragen. Gibt es Commits auf dem Server, die in das lokale Repo noch nicht übertragen wurden, muss zunächst ein Pull durchgeführt werden.

Pull

Befehl um die letzten Änderungen (Commits) vom Server Repo in das lokale Repo zu übertragen. Hierbei kommt es zu automatischen Mergevorgängen, wenn eine Datei durch ein lokales Commit und durch ein Remote Commit geändert wurden. Die zusammengeführten Objekte werden in einem eigenen Commit abgelegt. Wurde sogar dieselbe Zeile in einer Datei geändert, kommt es zu einem Konflikt, der manuell gelöst werden muss. Diese Änderungen müssen dann neu committet werden.

Branch

Zu jedem Git Repository gehört mindestens ein Branch. Beim Erzeugen des Repository wird dieser Branch(Masterbranch) mit erzeugt. Ein Branch ist technisch nur ein beweglicher Zeiger auf ein Commit.

Branches können als vollständiges eigenes Arbeitsverzeichnis mit eigenem Projektverlauf verstanden werden. Der Branch wird dabei zu einem beliebigen Zeitpunkt vom Hauptentwicklungsstrang abgezweigt.

In diesem abgezweigten Arbeitsverzeichnis können wie im Hauptentwicklungsstrang Änderungen gemacht und committet werden. Diese Änderungen sind nur innerhalb des Branches vorhanden.

Über einen Merge können die getätigten Änderungen in den Hauptentwicklungsstrang/Hauptbranch gebracht werden. Dieser Merge kann zu jedem beliebigen Zeitpunkt und auch beliebig oft erfolgen.

Branches sind ein mächtiges Tool um die Entwicklung zu organisieren. Damit ist es z.B. möglich mehrere Versionen eines Produkts zu warten oder auch einen Releasestand vorzubereiten. Azure Devops und VS Code unterstützen das Erstellen von Branches in der GUI.

Mögliche Branching Strategien sind hier definiert.

Sonstiges

Settings

GIT versucht den Benutzernamen und E-Mailadresse auf dem System des Benutzers automatisch zu ermitteln. Sollte dies nicht richtig funktionieren bzw. die ermittelten Werte nicht gewünscht sein, kann man diese manuell mit folgenden Befehlen setzen:

git config --global user.name "Mein Name"
git config --global user.email "ich@tso.de"

Lässt man das --global weg gilt die Einstellung nur für das aktuelle Repository

Änderungshistorie

Die Änderungen an Dateien können in Azure Devops in dem jeweiligen Repo beauskunftet werden. Gelöschte Dateien können dort allerdings nicht mehr ausgewählt werden. Um die herauszufinden wann und von wem eine Datei gelöscht wurde gibt es folgenden git Befehl

git log --all --full-history --

Siehe dazu auch: 2

Verwendung mit C

Für die Entwicklung von C# Projekten wird in der Regel Visual Studio verwendet. VS benutzt den Team Explorer um Verbindungen mit Quellcodeverwaltungssystem zu managen. D.h. die gängigen Befehle, die im Umgang mit git nötig sind, werden durch die gui unterstützt (clone, push, pull, commit etc. ).

Verwendung mit AL

Für die Entwicklung von AL Projekten wird Visual Studio Code verwendet. VS Code hat eine eingebaute Unterstützung von git. Sobald git auf dem lokalen System installiert wird die Verwendung in der VS Code Gui unterstützt.

Ablauf - Best practice

Datenbank durch Update-DevFromGit auf dem aktuellen Stand halten inkl. Pull = Yes
In NAV: Sync. Schema
Jetzt die Entwicklung tätigen
In NAV: Modified entfernen und auszuliefernde Objekte locken
Export-ObjectsToGit
Git Commit
Git pull
Konflikte / Fehler beheben
Stagen + Commit!
Update-DevFromGit
In NAV: Sync. Schema
Git push
Jetzt kann wieder weiter entwickelt werden.

Kategorie:Softwareentwicklung Business Central