Oft werden INOSIM-Modelle von mehreren Personen gewartet. Eine Herausforderung besteht dann darin, allen Beteiligten die aktuellste Version zur Verfügung zu stellen und sie konsistent zu halten. Mit den mit INOSIM 13 eingeführten Linked-Files-Funktionen und gängigen Tools aus der Softwareentwicklung lässt sich ein Workflow erstellen, der diese Herausforderung meistert.
Überblick
Oft werden INOSIM Modelle von mehreren Personen erstellt und gepflegt. Eine Herausforderung besteht dann darin, allen Beteiligten die aktuelle Version zur Verfügung zu stellen und diese konsistent zu halten. Während Modellelemente wie Teilanlagen oder Rezepte (noch) nicht automatisch synchronisiert werden können, ist dies für den VBA-Code mit einer mit INOSIM 13 eingeführten Funktion möglich. Mit dieser Funktion und gängigen Tools aus der Softwareentwicklung kann ein Workflow erstellt werden, der eine effiziente Zusammenarbeit ermöglicht. Dieser Tipp & Trick zeigt diese Funktion und einen effizienten Workflow, um divergierende Modellversionen zu eliminieren und undokumentierte Änderungen zu vermeiden.
Dieser Tipp & Trick setzt keine Vorkenntnisse in der Versionsverwaltung voraus. Deshalb stellen wir im ersten Abschnitt die Grundlagen der verteilten Versionskontrolle und in den folgenden Abschnitten weitere Konzepte und Funktionen vor. Der zweite Abschnitt stellt die LinkedFiles-Funktion für VBA-Dateien vor und Abschnitt drei zeigt auf, wie diese zusammen mit der Versionskontrolle in drei Anwendungsfällen verwendet werden kann:
- Anwendungsfall 1: Code-Historie als persönliches Backup
- Anwendungsfall 2: Code-Library für interne Standardfunktionen oder benutzerdefinierte Klassen
- Anwendungsfall 3: Code-Management innerhalb eines Projektteams mit mehreren Usern
Der vierte Abschnitt schließt diesen Tipp & Trick mit einigen Bonustips, mit deren Hilfe der kooperative Aufwand reduziert werden kann.
Einführung in Systeme zur verteilten Versionskontrolle
Dieser Tipp & Trick baut auf bestehenden Lösungen für Distributed Version Control System (DVCS) auf, die in der Softwareentwicklung weit verbreitet sind. Die verteilte Versionskontrolle spiegelt die gesamte Codebasis, einschließlich der gesamten Historie, auf jedem Entwicklerrechner wider. Ein DVCS verwaltet automatisch Verzweigungen und Zusammenführungen, ermöglicht (vorübergehend) Offline-Arbeiten und bietet eine Form der Sicherung früherer Versionen.
Ein DVCS besteht in der Regel aus einem Remote-Repository auf einem Server, einem lokalen Repository (LR) und einem Arbeitsverzeichnis (WD). Initial sind alle identisch, d. h. aus dem Remote Repository geklont. Benutzer ändern nur Dateien in ihrem Arbeitsverzeichnis. Änderungen werden an das lokale Repository übergeben (d. h. aufgezeichnet) und können dann in ein Remote Repository verschoben werden. Fremde Changesets werden vom Remote in das lokale Repository gezogen. Die Software vergleicht LR und WD und ermöglicht es Anwendern, ihre WD zu aktualisieren und abweichende Zweige bei Bedarf zusammenzuführen.
Eine DVCS-Lösung besteht in der Regel aus zwei Komponenten: Anwendersoftware und Hosting-Plattform. (Eine Plattform ist nur für die Zusammenarbeit notwendig. Falls Sie allein arbeiten und nur an Versionierung und Dokumentation von Änderungen interessiert sind, genügen die Software und ein lokales Repository.)
Die am häufigsten verwendete Software ist Git, das wir in diesem Tipp & Trick verwenden werden. Für Git stehen viele ausgefeilte Benutzeroberflächen von Drittanbietern zur Verfügung. Um die Kompatibilität mit allen Konfigurationen zu gewährleisten, setzt dieser Tipp & Trick nur auf die Schnittstellen, die in der Git-Installation enthalten sind: die Kommandozeilenschnittstelle und die grundlegende grafische Benutzeroberfläche (Git GUI im Windows-Startmenü).
Für das Hosting sind gängige Plattformen Github, Gitlab und Bitbucket. Die meisten Hosting-Plattformen können entweder vor Ort oder über Online-Service-Provider genutzt werden.
Für diesen Tipp & Trick verzichten wir auf die Verwendung einer externen Hosting-Plattform und erstellen Remote und Local Repositories auf demselben Rechner in verschiedenen Ordnern, um die Grundfunktionen zu präsentieren.

Einführung in die Linked Files-Funktion
Die Link-Funktion ermöglicht es, VBA-Makros in INOSIM mit Dateien auf der Festplatte mit einem einzigen Tastendruck zu synchronisieren. Die Verknüpfung kann durch Rechtsklick auf das Zielmakro und Auswahl von Datei-Link hinzufügen (siehe Abbildung) erstellt werden. In der Dateiauswahl können Sie entweder eine vorhandene Datei auswählen oder einfach den Namen der Zieldatei definieren. Wenn diese nicht existiert, wird sie beim Synchronisieren erstellt. Der verknüpfte Dateiname wird in den Makro-Eigenschaften angezeigt. Um die verknüpfte Datei zu lesen oder zu schreiben, gehen Sie zu Extras/Verknüpfte Dateien synchronisieren und synchronisieren Sie in die gewünschte Richtung. Hier können Sie auch einen Basispfad angeben, wenn Sie lieber relative Pfade definieren möchten. Die Besonderheiten der Verlinkung werden wir in den nachfolgenden Abschnitten behandeln. (Siehe INOSIM-Hilfe für eine detaillierte Erklärung der Link-Funktion: Basic: Editor::Benutzen des Editors::Verknüpfen und Synchronisieren von Makros mit externen Dateien).


Anwendungsfälle
Wir stellen drei Anwendungsfälle vor, die aufeinander aufbauen; sie sollen daher nacheinander gelesen werden:
- Der erste Anwendungsfall zeigt, wie Sie die Versionskontrolle für einen einzelnen Benutzer initialisieren und verwenden, der nur VBA-Code verwaltet.
- Der zweite Anwendungsfall zeigt, wie man einen neuen Kollegen aus dem ersten Anwendungsfall für kollaboratives Arbeiten in das Projekt einführt.
- Der dritte Anwendungsfall erweitert den Workflow auf ein komplettes INOSIM-Modell.
Anwendungsfall 1: Persönlicher Backup für VBA Code
Zwar befasst sich dieser Tipp & Trick mit der Zusammenarbeit mit anderen, doch ist auch der Nutzen der Versionskontrolle für einen einzelnen Benutzer nicht zu unterschätzen. Um den Mathematiker Karl Weierstraß zu zitieren:
Als ich dies schrieb, verstanden nur Gott und ich, was ich da tat. Nun ist es nur noch Gott.
Versionskontrolle ersetzt keine gute Dokumentation, doch dient sie als kommentierte Historie aller Änderungen, auf die frei zugegriffen werden kann, um den Aufwand für die Codepflege zu verringern. Mit der vollständigen Historie ist es auch möglich, ungenutzten Code großzügig aus der aktuellen Version zu entfernen, da er einfach wiederhergestellt werden kann. Darüber hinaus ist es möglich, von jedem beliebigen Punkt der Historie abzuzweigen und diese als Grundlage für die Weiterentwicklung zu nutzen – wobei jeder Zweig leicht identifizierbar ist. Abweichende Zweige können später als neuer Punkt in der Geschichte des Codes zusammengeführt werden. So können z. B. mehrere größere Änderungen isoliert voneinander oder isoliert von einer Hauptversion entwickelt werden, die jederzeit fehlerfrei einsetzbar sein muss.
Zunächst erstellen wir im Ordner C:\VBA-Collection eine versionierte Sammlung nützlicher VBA-Makros. Wie oben beschrieben, zeigen wir die Kommandozeilenschnittstelle sowie die grundlegende grafische Benutzeroberfläche (GUI). Für die Kommandozeilenbefehle können entweder die nativen Windows-Prompts oder die installierte Git Bash verwendet werden. Letzteres wird für die Screenshots in diesem Tipp & Trick verwendet.

Drücken Sie Create New Repository im GUI und geben Sie das korrespondierende Verzeichnis (C:\VBA-Collection) in den folgenden Dialog ein, oder geben Sie in die Kommandozeile die folgenden Befehle ein:
cmd
cd C://
git init VBA-Collection
cd VBA-Collection
Die GUI öffnet automatisch das Repository, die Kommandozeile sollte das neu erstellte Verzeichnis und den aktuellen Git Branch Namen anzeigen (hier: main). Branches können verwendet werden, um einzelne Entwicklungen aus der Haupthistorie (dem Stamm) zu trennen, bevor sie später wieder zusammengeführt werden, z. B. um sicherzustellen, dass laufende Arbeiten keinen Produktionscode beeinflussen. Obwohl es nicht Teil dieses Tipp & Tricks ist, empfehlen wir Teams, die Git in ihren Workflow und ihre Deployment-Prozedur integrieren möchten, sich vertiefend mit diesem Thema zu beschäftigen.

Diese Schritte erstellen einen neuen Ordner, der für die Versionskontrolle vorkonfiguriert ist. In diesem Ordner speichern wir Makros aus unseren anderen Tipps & Tricks. Zu Demonstrationszwecken zeigen wir auch den versteckten Ordner .git an, der bei der Initialisierung des Repositorys automatisch angelegt wurde. Dies ist das lokale Projektarchiv, wie in Abbildung 1 dargestellt. Alle anderen Dateien und Ordner sind Teil des Arbeitsverzeichnisses.

Die Dateien sind nun Teil des Arbeitsverzeichnisses, aber nicht Teil der Versionskontrolle.
Die Eingabe von git status in der Kommandozeile bestätigt dies. Für die GUI drücken Sie F5 oder klicken Sie auf Rescan (unter Toolbar>Commit).

Die folgenden Befehle ändern dies:
cmd
git add Sorting.bas TableTools.bas TimerClass.bas
git commit -m "Add macros to repository"
Der Befehl git add überträgt die angegebenen Dateien zum nächsten Commit, während der Befehl git commit einen Commit erzeugt.
Ein Commit kann grob als Schnappschuss der Dateien interpretiert werden. Der String, der dem -m-Specifier folgt, dient als Beschreibung und wird zusammen mit dem snapshot gespeichert.
Das Gleiche kann in der GUI erreicht werden, indem man die gewünschte(n) Datei(en) auswählt und Strg + T betätigt (oder auf: Toolbar>Commit>Stage to Commit klicken). Die Dateien werden nun unter Staged Changes (Will Commit) angezeigt. Geben Sie die Commit-Nachricht in das Textfeld ein und drücken Sie den Commit Button. Das Fenster sollte wie in Abbildung 8 (linke Seite) aussehen.

Für neue Dateien hat git add noch einen zweiten Effekt: Nachdem sie übertragen wurden, kann Git Änderungen in diesen Dateien erkennen. Obwohl diese Änderungen erst bei der nächsten Übertragung gespeichert werden, ist es möglich zu sehen, welche Änderungen seit der letzten Übertragung vorgenommen wurden.
Wir werden zwei Dinge tun, um dieses Verhalten hervorzuheben (und die nächsten Schritte vorzubereiten): Erstens, eine neue INOSIM-Datenbank innerhalb des Arbeitsverzeichnisses erstellen; Zweitens, TableTools.bas mit einem beliebigen Texteditor öffnen (wir werden in Kürze Änderungen innerhalb von INOSIM behandeln) und eine neue Kommentarzeile am Anfang der Datei hinzufügen:
'#Language "WWB-NET"
'Hello World!
Option Explicit
[…]
Geben Sie git status in der Kommandozeile ein (oder drücken Sie F5 in der GUI) und betrachten Sie den Output.

Git zeigt nun an, dass sich das TableTools-Makro geändert hat und dem Ordner eine neue Datei hinzugefügt wurde. Die GUI zeigt diese Informationen pro Datei im gelben Banner an, wenn Sie auf jede Datei klicken. (Zusammen mit dem Dateiinhalt und den Änderungen, wenn möglich).
Wir werden die neue Datei nicht hinzufügen oder die Änderung an dieser Stelle übertragen. Tatsächlich möchten wir niemals ganze Datenbankdateien übergeben, da deren Größe die Arbeit mit Git verlangsamen kann. (Wir verwenden stattdessen Exporte in Anwendungsfall 3).
Sie können Git anweisen, bestimmte Dateien zu ignorieren, indem Sie eine Datei mit dem passenden Namen .gitignore erstellen (beachten Sie den Punkt am Anfang und achten Sie darauf, dass die Datei keine Dateierweiterung hat!). In der ersten Zeile dieser Datei schreiben Sie *.imdf, in der zweiten *.ldf.
Wenn wir git status erneut eingeben (GUI: F5), sehen wir, dass die Datenbankdatei nicht mehr für Git sichtbar ist, stattdessen sehen wir die Datei gitignore. Um die Entscheidung, Datenbankdateien zu ignorieren, zu einem Teil des Projekts zu machen – (zur Vorbereitung auf die Zusammenarbeit und um die Ausgabe des git status übersichtlich zu halten) – fügen wir die Datei gitignore hinzu und übergeben sie an das lokale Repository, so wie zuvor.
Wie bereits erwähnt, möchten wir die Änderung nicht an TableToolsübergeben. Mit git restore TableTools.bas können wir die Änderung rückgängig machen und die Datei auf den Zustand des letzten Commits zurücksetzen. GUI: Wählen Sie die Datei aus und drücken Sie entweder Strg + J oder klicken Sie auf Toolbar>Commit>Revert Changes. Auch hier zeigt die GUI einen sauberen Zustand an.

Um diese Grundlagen der Versionsverwaltung und die zuvor beschriebene Link-Funktion zu kombinieren, öffnen Sie die INOSIM-Datenbank, erstellen Sie ein neues Projekt in der Datenbank und importieren Sie die Makros:

Da die Makros sowohl als Dateien als auch im Modell zur Verfügung stehen, können wir sie über die Link-Funktion verbinden. Klicken Sie dazu mit der rechten Maustaste auf die einzelnen Makros und wählen Sie Add file link. Ein Dateidialog öffnet sich und fragt nach der Datei. Wählen und bestätigen Sie die entsprechende Makrodatei. (Hinweis: Wenn Sie einen nicht vorhandenen Dateinamen eingeben, können Sie dennoch bestätigen und später von INOSIM mit der Datei synchronisieren; die Datei wird dann erstellt.)
Der absolute Pfad zur verknüpften Datei wird nun im Eigenschaftenfenster angezeigt. Während der absolute Pfad für einen einzelnen Benutzer ausreichend ist, deckt Anwendungsfall 2 die Verwendung relativer Pfade und deren Nutzen ab.

An diesem Punkt, nach dem Import, sind die externen Dateien und der Code im Modell identisch. Lassen Sie uns vor der Synchronisierung eine kleine Änderung vornehmen: Wir erweitern das TableTools-Makro um eine vereinfachte Funktion, um Tabellen zu lesen. Die Funktion Read_Full_Vertical_Table ruft die bekannte Read_Table-Funktion auf, allerdings mit vordefinierten Argumenten. In diesem Fall geht die Funktion davon aus, dass wir an der gesamten Tabelle interessiert sind und nur die erste Zeile Header/Index-Daten enthält, also stellt das Sheet eine vertikale Tabelle dar.
VBA
Function Read_Full_Vertical_Table(XLS_Sheet As String) As Table
' Reads an entire excel sheet that is formatted vertically (only uses row index)
Read_Full_Vertical_Table = Read_Table(XLS_Sheet, 0, 0, 0, 0, True, False)
End Function
Nun enthält das Makro TableTools innerhalb von INOSIM Änderungen, die noch nicht in der entsprechenden externen Datei enthalten sind. Folglich sind Git auch noch keine Änderungen bekannt. (Testen Sie dies gerne mit dem Befehl git status oder durch Drücken von F5 in der Git GUI.)
Um eine Datei aus INOSIM zu synchronisieren, öffnen Sie im VBA-Editor das Menü Extras und klicken Sie auf Verknüpfte Dateien synchronisieren.

In diesem Dialog können Sie die Synchronisierungsrichtung auswählen, den Basispfad für relative Pfade konfigurieren (Hinweis: INOSIM 14 bietet eine feinere Kontrolle für globale und projektspezifische Pfade, INOSIM 13 bietet einen Basispfad) und konfigurieren, welche Makros Sie für die Synchronisierung auswählen möchten. Die Liste der Makros zeigt auch die Richtung der Synchronisation an, indem Quelle und Ziel dynamisch angegeben werden. Überprüfen Sie vor der Synchronisierung die Richtung noch einmal; eine versehentliche Synchronisierung von Datei zu INOSIM kann Ihre Änderungen überschreiben und zu Datenverlust führen!
Um die Änderung am TableTools-Makro zu synchronisieren, wählen Sie Verknüpfte Dateien aktualisieren und klicken Sie auf Synchronisieren. Dadurch wird die Datei mit dem neuen Inhalt überschrieben.
Der Aufruf von git status bestätigt dies.
Zusätzlich zeigt git diff TableTools.bas die genauen Änderungen in der Datei an. Wenn die Änderung die Fenstergröße überschreitet, können Sie durch Drücken der Eingabetaste in der Datei vorwärts gehen und den diff-Befehl durch Drücken der Q-Taste (Quit) beenden. Für die GUI wird durch Drücken von F5 die Liste der vorgemerkten Änderungen aktualisiert. Wenn Sie TableTools.bas auswählen, wird der Dateiinhalt angezeigt, wobei alle Änderungen hervorgehoben sind.

Mit git add TableTools.bas und ggit commit -m Add function to read vertical tables from excel sheet (oder den GUI Äquivalenzen) wird diese Änderung in der Historie des Projekts aufgezeichnet.
Da die Abdeckung aller Möglichkeiten, die Historie von Commits zu durchlaufen, den Rahmen dieses bereits ausführlichenTip & Tricks sprengen würde, beschränken wir uns auf den grundlegendsten Fall: die Rückgängigmachung eines Commits. Hier werden wir den letzten Commit rückgängig machen, aber der Befehl erlaubt es, jeden Commit in der Historie rückgängig zu machen, indem das Gegenteil der Änderung angewendet wird. Das taktische Herangehen an Änderungen und Commits sowie klare Commit-Meldungen unterstützen dies (siehe Bonussektion).
Öffnen Sie in INOSIM das TimerClass–Makro. Markieren Sie den gesamten Makroinhalt (Strg + A) und löschen Sie alles (Entf). Führen Sie die obigen Schritte aus, synchronisieren Sie von INOSIM –> Datei und erstellen Sie einen neuen Commit mit dieser ziemlich drastischen Änderung.
Um diese (oder irgendeine andere) Änderung rückgängig zu machen, müssen wir genau angeben, welchen Commit wir rückgängig machen wollen. Die Logs sind die einfachste Methode, um die eindeutige Kennung jedes Commits zu erhalten. Geben Sie git log in die Konsole ein. Ihr Commit-Verlauf wird angezeigt. In der GUI finden Sie die Historie unter: Toolbar> Repository>Visualize main’s history. Es öffnet sich ein neues Fenster mit einer detaillierten Übersicht der Historie.

Neben der Commit-Nachricht werden das Datum, die Uhrzeit und der Autor jedes Commits angezeigt. Darüber hinaus wird jeder Commit durch einen alphanumerischen String (eine SHA-1-Prüfsumme) eindeutig identifiziert. Wenn Sie diesen Bezeichner in einem beliebigen Kommando verwenden, reicht es aus, die ersten paar Zeichen zu verwenden, wenn der Commit eindeutig identifiziert werden kann (d. h., kein anderer Commit beginnt mit den gleichen Zeichen).
Wir können unseren unerwünschten Commit anhand der Commit-Nachricht identifizieren und die Kennung notieren. Bei langen Ausgaben des log-Befehls drücken Sie die Q-Taste, um den Befehl zu beenden.
Jetzt können wir den Commit rückgängig machen, indem wir git revert –-no-commit <ID> eingeben. Wenn Sie diesem Tipp & Trick folgen, werden Sie höchstwahrscheinlich eine andere Kennung sehen, also ersetzen Sie <ID> sie durch den entsprechenden Wert.
Nach git revert –no-commit wurde Ihr Arbeitsverzeichnis geändert, was durch eine schnelle Ausführung von git status überprüft werden kann. Um die Revert-Aktion abzuschließen, benutzen Sie git commit -m “Revert deletion”. Bei größeren oder aufeinanderfolgenden Reverts sollte der Zustand zwischen revert und commit verwendet werden, um die Umkehrung auf Fehler zu überprüfen. Wenn Sie die Umkehrung direkt übertragen möchten, lassen Sie –no-commit aus; in diesem Fall öffnet sich ein Texteditor und fordert eine Commit-Nachricht an. In der Benutzeroberfläche können Sie mit der rechten Maustaste auf den Commit klicken, den Sie rückgängig machen möchten, und Revert this commit auswählen, um diesen Commit rückgängig machen.

Nun hat sich die Datei innerhalb des Arbeitsverzeichnisses geändert, aber INOSIM ist sich der Änderung noch nicht bewusst. Um von Datei ->INOSIM zu synchronisieren, gehen Sie zu INOSIM und öffnen Sie den Dialog Verknüpfte Dateien synchronisieren erneut. Wählen Sie Makros aktualisieren aus. Stellen Sie vor dem Klicken auf Synchronisieren sicher, dass nur das gewünschte Makro ausgewählt ist und kein uncommiteter Code überschrieben wird. Klicken Sie nun auf Synchronisieren – der Dateiinhalt ist nun im Makro sichtbar und die Änderung wurde erfolgreich rückgängig gemacht.

Für einen einzelnen Benutzer deckt dieser Anwendungsfall alle grundlegenden Git-Befehle und Konzepte ab, um die Versionskontrolle produktiv zu nutzen, obwohl viele nützliche Befehle in diesem Anwendungsbereich nicht abgedeckt werden konnten. (Besonders erwähnenswert: git bisect, das die binäre Suche verwendet, um halbautomatisch den Commit zu finden, der einen Fehler verursacht hat. ) Basierend auf diesem Anwendungsfall ist es einfach, das Repository von der Single-User-Nutzung zu einer kollaborativen Arbeitsumgebung zwischen Kollegen zu erweitern. Es ist auch möglich, den Export eines INOSIM-Modells zur Versionshistorie hinzuzufügen, allerdings nicht ohne Vorbehalt. Beides wird im Anwendungsfall 2 bzw. im Anwendungsfall 3 behandelt.
Anwendungsfall 2: Benutzung einer gemeinsamen VBA-Bibliothek
Hinweis: Der Kürze halber werden Synchronisierungsschritte in diesem Abschnitt nicht explizit gezeigt oder erwähnt. Es wird davon ausgegangen, dass Änderungen direkt zwischen Dateien und INOSIM synchronisiert werden. Außer wenn neue Befehle eingeführt werden, werden keine Screenshots der Schnittstellen hinzugefügt. Siehe Anwendungsfall 1 für die grundlegenden Befehle.
Wichtig: Um sicherzustellen, dass keine Daten verloren gehen, gehen Sie wie folgt vor:
Bevor Sie neue Versionen aus dem entfernten Repository (Remote Repository) pullen, synchronisieren Sie zuerst in INOSIM -> Dateien und übertragen (oder verwerfen) Sie alle Änderungen. Nur dann pullen Sie die Änderungen und synchronisieren Sie sie von Dateien -> INOSIM.
Nach dem Pullen der letzten Änderungen können Sie auch Ihre eigenen Änderungen sicher in das Remote Repository pushen.
Anstatt eine Hosting-Plattform zu verwenden, erstellen wir ein Remote Repository auf der lokalen Festplatte. Wenn Sie eine Hosting-Plattform verwenden, ist es nicht ungewöhnlich, zuerst ein lokales Repository zu erstellen und dieses dann auf die Plattform hochzuladen.
Öffnen Sie Git Bash in C:\\ und geben Sie folgenden Befehl ein:
git clone –-bare VBA-Collection Remote-VBA
Anschließend können Sie den Ordner VBA-Collection löschen. (Es ist nun möglich, VBA-Collection mit dem Remote Repository zu verbinden, dies wird hier jedoch weggelassen. )
Um mit einem entfernten Projektarchiv (Remote Repository) arbeiten zu können, benötigen wir zunächst eine lokale Kopie. Dies wird allgemein als cloning bezeichnet und wird mit dem Befehl git clone durchgeführt.
Zu Demonstrationszwecken werden wir zwei lokale Repositories erstellen, um zu überprüfen, ob die Historie wie erwartet ist. Nach den folgenden Kommandos sollte der letzte Commit des Anwendungsfalls 1 angezeigt werden (Revert deletion..).
git
cd c:\\
git clone Remote-VBA LocalOne
git clone Remote-VBA LocalTwo
cd LocalOne
git log -1
Öffnen Sie für die grafische Oberfläche ein neues Git GUI Fenster und klicken Sie auf Vorhandenes Repository klonen. Verwenden Sie im Klon-Dialog den Ordner Remote-VBA als Quelle und geben Sie den Pfad eines neuen Ordners als Ziel ein. Bestätigen Sie mit der Schaltfläche Klonen.

Erstellen Sie nun, wie in Anwendungsfall 1 gezeigt, eine beliebige Änderung im Repository LocalOne im VBA-Code und committen Sie diese. Für die Änderung reicht bereits ein neuer Kommentar im Makro Sorting.bas. Diese Änderung existiert derzeit nur im lokalen Repository LocalOne, was mit git log in beiden lokalen Repositorys überprüft werden kann.
Lokale Repositorys von Mitarbeitern werden über das Remote Repository synchronisiert. Der Vorgang, das entfernte Repository mit neuen Änderungen zu aktualisieren, wird Push genannt, der Vorgang des Herunterladens von Änderungen vom entfernten Repository wird Pull genannt (vergleiche Abbildung 1).
Um die neue Änderung von LocalOne zu Remote-VBA zu pushen, geben Sie git push in der Kommandozeilenschnittstelle ein oder klicken Sie in der grafischen Benutzeroberfläche auf Toolbar>Remote>Push (und bestätigen Sie dann mit der Schaltfläche Push).

Um die Änderungen zu pullen, wechseln Sie in das LocalTwo-Repository und verwenden Sie den Befehl git pull. In Abbildung 20 sehen Sie auch den optionalen Befehl git remote update, der Referenzen auf Commits aus dem Remote-Repository herunterlädt. Auf diese Weise kann git status sehen, wie weit die aktuelle Version zurückliegt (siehe Konsolenausgabe in Abbildung 20).
Für die Git GUI ist eine weitere Erklärung notwendig: git pull ist eine Kombination aus dem Herunterladen aller entfernten Änderungen und dem automatischen Zusammenführen mit dem Kommando git fetch, gefolgt von git merge. In der Git GUI müssen beide Schritte manuell ausgeführt werden, indem man zuerst Toolbar>Remote>Fetch from origin benutzt, gefolgt von Toolbar>Merge>LocalMerge. In diesem Dialog können Sie die entfernte Version des Hauptzweigs auswählen und mit Ihrer lokalen Version zusammenführen.

Das Zusammenführen wird in der Regel automatisch von Git durchgeführt, auch wenn mehrere Benutzer an derselben Datei arbeiten. Wenn Sie Ihre Commits klein halten, wird das Zusammenführen robuster. Manchmal kann es vorkommen, dass Git eine Datei nicht automatisch zusammenführen kann, z. B. wenn zwei Benutzer dieselbe Zeile in einer Datei ändern. In diesem Fall gibt Git eine Warnung aus und fordert Sie auf, den Konflikt manuell zu lösen, indem Sie die Dateien im Arbeitsverzeichnis ändern und einen nachfolgenden Commit für das Zusammenführen erstellen.
Dies deckt die grundlegenden Befehle ab, um gemeinsam an einer Sammlung von VBA-Code zu arbeiten, obwohl noch viel mehr möglich ist.
Ein solches geteiltes Remote Repository kann einfach erweitert werden, um ganze Bibliotheken mit unternehmens- oder projektspezifischen Vorlagen und universellem Code zu speichern. Mehrere Teams können dann jederzeit auf die neueste Version zugreifen und alle Änderungen zurückverfolgen.
Dies wird in INOSIM 14 insbesondere dadurch erleichtert, dass ein genereller Basispfad für alle Projekte und ein relativer projektspezifischer Pfad verwendet wird. Ein Hinweis zur Implementierung: Der allgemeine Basispfad könnte auf C:\VBA-Code\General verweisen, das ein Repository für unternehmensweite Makros ist, während der Projektpfad auf ..\TheProject gesetzt ist, was als relativer Pfad auf C:\VBA-Code\TheProject verweist, das ein anderes Repository mit projektspezifischen Makros sein kann.
Im Anwendungsfall 3 gehen wir einen anderen Weg und verwenden dieses Repository als Single Point of Truth für die Entwicklung eines einzigen Modells.
Anwendungsfall 3: Modellversionierung / Project Code Management
Generell wird die Versionierung für Modellierungsprojekte empfohlen, bei denen hauptsächlich Änderungen am VBA-Code vorgenommen werden. Diese Änderungen können von der Software leicht visualisiert werden, z. B. durch Hervorheben bestimmter Codeabschnitte. Eine Versionierung für Änderungen an der Modell- und Parameter-Arbeitsmappe ist ebenfalls möglich, jedoch ohne Visualisierung.
Die folgenden Unterabschnitte führen Sie durch das initiale Setup, wie Sie fremde Changesets anwenden und wie Sie Ihre Änderungen committen.
Initialer Setup
In diesem Anwendungsfall modifizieren wir die Repository-Struktur leicht, basierend auf dem LocalOne-Repository und dem Remote-Repository aus Anwendungsfall 2 oder dem Repository VBA-Collections aus Anwendungsfall 1. Im letzteren Fall können die Interaktionen mit dem Remote Repository ignoriert werden.
Zuerst wird aller VBA-Code in ein separates Verzeichnis verschoben, hier VBA-Code.
Wenn Sie dem Tipp & Trick bis hierher gefolgt sind, erstellen Sie diesen Ordner manuell, verschieben Sie die VBA-Dateien und übertragen Sie sie diesen Schritt als separate Änderung. (Alternativ ist es etwas besser, den Befehl git mv zu verwenden und dann zu übertragen).

Während die INOSIM-Datenbank im vorherigen Anwendungsfall nur zum Editieren des Codes verwendet wurde, verwenden wir nun ein Modell, mit dem wir arbeiten wollen. Für diesen Tipp & Trick verwenden wir das Recycling-Beispiel, das Sie im Download-Bereich bei den Beispielprojekten für INOSIM 13 finden.
Wenn Sie die Datenbank im Arbeitsverzeichnis speichern, stellen Sie sicher, dass sie von Git ignoriert wird, indem Sie die .gitignore-Datei verwenden (siehe Anwendungsfall 1).
Öffnen Sie nun das Modell und exportieren Sie alle Makros in den Ordner VBA-Code. Zusätzlich fügen wir dem Modell die Makros aus dem vorherigen Schritt hinzu.
Verknüpfen Sie die externen Dateien und INOSIM-Makros wie in Anwendungsfall 1 beschrieben und stellen Sie sicher, dass alle Pfade relativ zu Ihrem Projektarchiv-Ordner sind und dass der Basispfad korrekt eingestellt ist – wie in der Abbildung unten gezeigt:

Nachdem Sie alle Datei-Links eingerichtet haben, exportieren Sie das Projekt in das Verzeichnis Local Repository. Fügen Sie die beiden zusätzlichen Makros und die Projektexportdatei (.IXML) dem Repository hinzu und committen Sie die Änderung. Übertragen Sie die Änderungen aus dem lokalen Repository LocalOne mit git push in das Remote Repository.
Da alle Dateien vorhanden sind, können wir nun die Git-Befehle aus den vorherigen Anwendungsfällen verwenden, um Änderungen in jeder Datei zu verfolgen, wobei der Modell-Export ein Sonderfall ist: Da es sich um eine Binärdatei und keine Textdatei handelt, kann Git nicht zwischen einzelnen Änderungen innerhalb der Datei unterscheiden und auch nicht zwei voneinander abweichende Dateien zusammenführen. Jeder Commit eines aktualisierten Modell-Exports ist wie das Speichern einer vollständigen Kopie, während Aktualisierungen in den VBA-Code-Dateien nur die minimale Information (d. h. die Differenz) zwischen zwei Dateien erfordern.
Nach diesem Setup ist das Repository bereit für die Weiterentwicklung und den Austausch mit Mitarbeitern.
Setup-Schritte für Zusammenarbeitende
Klonen Sie das Remote Repository wie in Anwendungsfall 2 beschrieben (oder pullen Sie die neuen Änderungen in das zuvor erstellte lokale Repository LocalTwo, wenn Sie diesen Tipp & Trick durcharbeiten). Ihr Arbeitsverzeichnis enthält den VBA-Code Ordner, den Modell-Export und die gitignore Datei.
Importieren Sie den Modellexport in eine (neue) INOSIM-Datenbankdatei. Wichtig: Bei diesem Workflow kann nicht garantiert werden, dass der Modellexport den aktuellen VBA-Code enthält! Gehen Sie daher zum INOSIM Basic Editor, Extras und öffnen Sie das Menü Verknüpfte Dateien synchronisieren. Nach dem initialen Setup sollten alle Pfade relativ sein und auf den VBA-Code-Ordner im Repository verweisen. Wenn sich der Basispfad zwischen den Zusammenarbeitenden unterscheidet, muss jeder Beteiligte den Basispfad individuell konfigurieren und sicherstellen, dass der Pfad nach jeder Modellaktualisierung korrekt ist. Nach Befolgen der vorherigen Anweisungen ist es beispielsweise notwendig, den Ordner in C:\LocalTwo zu ändern. Wenn die lokalen Projektarchive den gleichen Namen und Pfad auf verschiedenen Rechnern hätten, wäre keine Änderung notwendig.
Wenn alle Pfade korrekt sind, synchronisieren Sie über Dateien -> INOSIM. Damit ist Ihre Datenbank bereit für die weitere Entwicklung.
„Committen“ eigener Änderungen
Die Schritte zum Hinzufügen und Übertragen von Änderungen sind die gleichen wie oben beschrieben, mit einem leicht modifizierten Workflow:
Wenn sich das Modell oder das Parameterblatt geändert hat, exportieren Sie das gesamte Modell und überschreiben Sie die vorhandene .IXML-Datei. Wichtig: Wenn sich das Modell nicht geändert hat und nur der VBA-Code aktualisiert wurde, exportieren Sie das Projekt nicht! Das Exportieren eines unveränderten Modells könnte von Git fälschlicherweise als Änderung erkannt werden und zu Verwirrung führen!
Um weiteren Speicherplatz zu sparen, sollten Sie die Ergebnisdaten vor dem Export aus dem Projekt entfernen (INOSIM-Hauptfenster > Projekt > Säubern, dann alle Ergebnisse zum Löschen markieren).
Wenn der VBA-Code geändert wurde, verwenden Sie die Sync-Funktion, um die Änderungen in den externen Dateien zu speichern:
- Menü Extras> Verknüpfte Dateien synchronisieren und Verknüpfte Dateien aktualisieren aufrufen.
- Achten Sie auf die Richtung, Gefahr von Datenverlust! Wenn Sie Makros aktualisieren wählen, werden die Makros im VBA-Editor mit dem Inhalt der verknüpften Dateien überschrieben. Das kann nicht rückgängig gemacht werden.
- „Committen“ Sie Ihre Änderungen und „pushen“ Sie sie zum Remote Repository, falls erforderlich.
„Pullen“ und „Mergen“ fremder Änderungen
Für Änderungen am VBA-Code gelten die gleichen Grundsätze wie im Anwendungsfall 2. Änderungen am Modell erfordern die Kommunikation mit Ihren Mitarbeitenden; es wird empfohlen, dass jeweils nur eine Person am Modell/Parameterblatt arbeitet (andere können weiter am Code arbeiten). Der Grund dafür ist die technische Limitation von Git, dass Änderungen in Modellen nicht automatisch zusammengeführt werden können und dass einzelne Änderungen innerhalb der Modelle nicht verfolgt werden können. Fortgeschrittene Anwender können die Verzweigungsfunktionen von Git nutzen und später die beiden abweichenden Versionen manuell zusammenführen.
Rekapitulieren wir die Schritte zum „Pullen“ von Änderungen:
- Synchronisieren Sie Ihren Code aus INOSIM -> File.
- Falls Sie das Modell geändert haben, exportieren und überschreiben Sie die .IXML-Datei. Beachten Sie obige Warnung!
- „Adden“ und „committen“ Sie die Lokalen Änderungen, die Sie behalten möchten.
- „Pullen“ Sie neue Änderungen vom Remote Repository. Überspringen der vorherigen Schritte kann zum Datenverlust führen!
- Lösen Sie eventuelle Konflikte im VBA-Code auf (Modelländerungen: Die letzte Version wird ohne Kommentar übernommen).
- Falls das Modell sich geändert hat: Re-importeren Sie den Modellexport in die Datenbank und löschen Sie das alte Projekt.
- Importieren Sie VBA-Dateien in die Modelldatenbank.
Bonus-Tipps
In den folgenden Unterabschnitten finden Sie einige Bonus-Tipps für eine konsistente und produktive Zusammenarbeit mit einer gemeinsamen Codebasis und Modellversionierung.
VBA-Kommentare
Den Code zu verstehen, den jemand anderes geschrieben hat, kann eine Herausforderung sein. (Selbst den eigenen Code zu verstehen, nachdem einige Zeit vergangen ist…). Das Hinzufügen von beschreibenden und präzisen Kommentaren zu komplexen Algorithmen, Subs oder Funktionen kann der nächsten Person, die eine Änderung vornehmen muss, enorm helfen. Ebenso hilft nach Best Practices genau geschriebener Code (Clean Code).
Ad-hoc-Notizen mögen im Moment klar erscheinen, können aber Monate später sehr verwirrend sein; Verwenden Sie gängige Schlüsselwörter in VBA-Code-Kommentaren, um ihren Zweck zu verdeutlichen.
- Die asynchrone Kommunikation kann durch gängige Schlüsselwörter wie NOTE, QUESTION, HACK, TODO, FIXME usw. erleichtert werden.
- Beispiel: ‚TODO Add counter to for-loop‘
- Codezeilen, die mit diesen Schlüsselwörtern markiert sind, müssen beachtet werden, können aber vom aktuellen Benutzer nicht gelöst werden, z. B. weil etwas unklar ist.
Tactical Commits und gute Commit-Meldungen
Erstellen Sie Commits taktisch in kleinen Schritten, von einer stabilen Änderung zum nächsten.
- Taktisch: Schaffen Sie zuerst die Voraussetzungen für die gewünschte Änderung und „committen“ Sie kontinuierlich einzelne, kleine Änderungen. Zum Beispiel: Schreiben und „committen“ Sie zuerst eine neue Funktion, ändern Sie dann den vorhandenen Code, um die neue Funktion zu verwenden, und „committen“ Sie diese Änderung separat.
- Nicht-taktisch: Fügen Sie die gewünschte Änderung ein und ändern Sie dann nachträglich alles andere entsprechend der Änderung. (Bad Practice!)
Schreiben Sie gute Commit-Meldungen: Beginnen Sie sie mit Präfixen, zum Beispiel: [FIX], [DOCS], [INTERNAL], [FEATURE] und führen Sie eine kurze, aber aussagekräftige Zusammenfassung hinzu.
Beispiele:
- [FIX] Fehler, wobei die falsche Teilanlage belegt wurde, wenn das CustomAttribute Test null war.
- [DOC] Update der Funktionsbeschreibung von WriteTable.
- [FEATURE] Berechnung Utility-Bedarf für Zentrifugen.
Eine Online-Suche kann viele weitere Tipps und Richtlinien zu Commit-Nachrichten aufdecken. Entscheidend ist, eine einheitliche Methode für das gesamte Team zu entwickeln.
Modell-Versionsnummern
Die Kommunikation zwischen den Modellen kann durch eindeutige Versionsnummern vereinfacht werden. Hier ist eine mögliche Taktik, um ein konsistentes Versionierungsmuster zu implementieren. Die Versionsnummern folgen dem Schema: MAJOR.MINOR.REVISION, z. B. 3.0.1 oder 1.3.2. Neue Modelle starten ab 0.1.0.
Die Revision wird erhöht, wenn der VBA-Code zur Fehlerbehebung geändert wird. Wird z. B. ein Fehler in einem Makro erkannt und korrigiert, wird die Versionsnummer von 1.3.2 auf 1.3.3 erhöht.
Der Minor wird erhöht, wenn sich der VBA-Code ändert, wenn neue Funktionen hinzugefügt werden oder vorhandene Funktionen sich funktional ändern. Die Revision ist auf 0 gesetzt. Wenn Sie beispielsweise ein neues Allokationssteuerelement in VBA integrieren, ändert sich die Versionsnummer von 1.3.3 auf 1.4.0.
Der Major wird erhöht, wenn sich etwas außerhalb von VBA ändert (Parameter-Arbeitsmappe, neue Modellelemente wie Rezepte oder Einheiten). Revision und Moll werden auf 0 gesetzt. Wenn Sie beispielsweise ein neues Rezept hinzufügen, ändert sich die Versionsnummer von 1.4.0 auf 2.0.0.
Um zu viele große Inkremente zu vermeiden, empfiehlt es sich (aber nicht zwingend!) ein Modell zu verwenden, bei dem die Entwicklung von Rezepten und Parametern fast abgeschlossen ist.
Die Version kann in der Versionskontrollsoftware markiert und/oder in einer VERSION.TXT-Datei dokumentiert werden. Die Nummer macht es den Kollegen leicht einzuschätzen, was sie erwartet, wenn neue Updates eintreffen:
- Revision: VBA-Dateien müssen synchronisiert/aktualisiert werden. Wenn sie nicht vom Fehler betroffen sind, keine spürbare Veränderung
- Minor: VBA-Dateien müssen synchronisiert/aktualisiert werden. Modell verhält sich wahrscheinlich anders oder kann zumindest rekonfiguriert werden.
- Major: Aktualisierte IXML-Datei muss importiert werden & VBA-Dateien müssen synchronisiert werden. Das Modell könnte sich drastischer geändert haben.
Wie viele Änderungen auch immer in einer Revision gebündelt werden, eine kleinere oder größere Änderung wird am besten innerhalb der Arbeitsgruppe besprochen. Es wird empfohlen, kleine Änderungen vorzunehmen, um den vorherigen Status problemlos wiederherstellen zu können. (Anmerkung: Kurze Englische Commit-Nachrichten im Imperativ bieten sich besonders für klare Änderungsbeschreibungen an.)
Fragen?
Möchten Sie mehr über dieses Thema erfahren oder haben weitere Fragen? Bitte kontaktieren Sie uns.
Mehr Tipps & Tricks
INOSIM 13 – WWB.NET vs. WWB-COM
Mit der neuen INOSIM 13 Version wurde der Basic-Editor umgestellt. So unterstützt dieser nun zusätzlich zu der WWB-COM auch die WWB.NET Sprachvariante, welche mit Visual…
Kooperation und Versionskontrolle für INOSIM Modelle
Oft werden INOSIM-Modelle von mehreren Personen gewartet. Eine Herausforderung besteht dann darin, allen Beteiligten die aktuellste Version zur Verfügung zu stellen und sie konsistent zu…
Schichtkalender: Wie Prozeduren während einer Schichtpause unterbrochen werden können
In INOSIM kann die Verfügbarkeit von Ressourcen und Equipment mithilfe von Schichtkalendern ausgedrückt werden. Ein Schichtkalender legt fest, wann ein Equipment verfügbar ist oder wie…