In der dynamischen Welt der Skriptentwicklung kann es frustrierend sein, Effizienz und Konsistenz inmitten häufiger Aktualisierungen und gemeinsamer Beiträge zu wahren. Diese Präsentation zeigt die Leistungsfähigkeit der Git-Software für die kollaborative Arbeit an Skripten und bietet Lösungen für gängige Probleme wie versehentliches Löschen, Versionskontrolle und den Aufwand manueller Backups.
Git ist ein unverzichtbares Werkzeug für die Teamarbeit und ermöglicht es mehreren Beteiligten, gleichzeitig an einem Projekt zu arbeiten. Mit Git wird jede Änderung automatisch versioniert, wodurch eine umfassende Historie entsteht, die es Teams ermöglicht, Änderungen mühelos nachzuverfolgen, rückgängig zu machen und zu überprüfen. Darüber hinaus stellt die automatische Backup-Erstellung von Git sicher, dass Ihre Arbeit in Echtzeit geschützt ist, wodurch das Risiko von Datenverlust minimiert und die Gesamtproduktivität gesteigert wird.
Nach Erläuterungen zur Struktur von Git sowie dessen Einrichtung und Verwendung zeigt diese Präsentation, wie man ein Skript entwickelt.
JMP auf Git ist ein Aufruf zum Handeln, den wir fördern möchten. Mein Name ist Britta Silbersack. Ich arbeite bei Roche Diagnostics und unterstütze dort unsere Wissenschaftler mit Skriptlösungen in JMP. Zu Beginn dieser Tätigkeit lernte ich Bernd kennen, der als Berater für Roche tätig war. Nun haben wir uns wiedergetroffen, um diese Präsentation zu halten.
Mein Name ist Bernd Heinen. Einige kennen mich vielleicht als ehemaligen Senior Systems Engineer bei JMP. Jetzt arbeite ich als Berater. Ich unterstütze meine Kunden beim Verständnis und der Anwendung von Statistik oder coache sie in JSL. So lernte ich Britta kennen. Vor einiger Zeit sprachen wir über Programmierung und kamen zu dem Schluss, dass es eine gute Idee wäre, die Verwendung von Git-Repositories für die JSL-Entwicklung zu fördern.
Was ist Git? Git ist ein verteiltes Versionskontrollsystem. Sie speichern Ihre JSL-Skripte in einem Git-Administratorordner. Anschließend stehen Ihnen zahlreiche Funktionen zur Verfügung, die Ihnen die Verwaltung Ihrer Skripte erleichtern. Git erstellt regelmäßig Snapshots Ihrer Skripte. So können Sie Ihre Backups organisieren, die Versionskontrolle durchführen, die Zusammenarbeit unterstützen und Ihre Arbeit dokumentieren.
Sie können alle Vorteile von Git nutzen, wenn Sie als Programmierer alleine arbeiten. Dann benötigen Sie keine umfangreiche Infrastruktur. Eine Sicherungskopie auf einem Remote-Server wird empfohlen. Die wahre Stärke von Git entfaltet sich jedoch in einer kollaborativen Umgebung. Teammitglieder können am selben Programm arbeiten, ihre Programmversionen in das Repository hochladen und anschließend ihre Arbeit zusammenführen. Git ist die zentrale Plattform, und die native Kommunikation erfolgt über eine Kommandozeilenschnittstelle. Es gibt aber zahlreiche Add-ons, die grafische Benutzeroberflächen für Git bereitstellen und sogar dessen Funktionalität erweitern.
Wir möchten ein kurzes Video eines typischen Arbeitsablaufs zeigen. Es ist kein Schulungsvideo für Git, sondern soll Git-Nutzer motivieren. Wir haben versucht, es kurz, aber informativ genug zu halten, um die Zusammenarbeit mit Git zu demonstrieren. Wir werden Aspekte wie die Programmierung in JSL, die Registrierung des Skripts in Git, Snapshots, die Rolle des Repositorys und das Zusammenführen verschiedener Versionen desselben Skripts beleuchten.
Wir beginnen mit der Ansicht auf Brittas Laptop. Sie navigiert zur GitLab Cloud, einer der möglichen Hosting-Optionen für Git. Sie erstellt eine neue Gruppe namens „Keep it easy“ und lädt andere, in diesem Fall mich, ein. Das geht mit wenigen Klicks. In dieser Gruppe erstellt sie ein neues, leeres Projekt namens „TryGit“. Sie füllt die Standardfelder aus, erstellt das Projekt und kopiert dann den Link hierher. Anschließend kehrt sie zu ihrem Laptop zurück oder arbeitet lokal auf ihrem Laptop. Mit Git Extensions, der GUI, die wir in diesem Beispiel verwenden – es gibt viele –, fügt sie den Link ein und klont oder kopiert das Repository. Dadurch wird ein leerer Arbeitsbereich auf ihrem Laptop erstellt.
Nun beginnt sie, ihr JSL-Skript in JMP zu schreiben. Anschließend speichert sie es in dem von Git verwalteten Ordner. Jetzt erstellt sie einen Commit – eine Art Snapshot – und überträgt den aktuellen Stand per Push oder Upload in das Web-Repository in GitLab.
Schauen wir uns nun Bernds Laptop an. Er arbeitet remote mit GitLab. Als ich die Arbeitsgruppe erstellte, erhielt Bernd eine E-Mail von Git. Neugierig folgte er dem Link zum Remote-Repository und suchte das Projekt. Zu diesem Zeitpunkt war es noch leer. Er kopierte den Link ebenfalls und ging genauso vor. Er klonte das Repository über die SSH-verschlüsselte URL und legte fest, wo auf seinem Laptop der Klon gespeichert werden sollte. Er verwendete den Namen aus dem Repository für seinen Ordner und öffnete ihn.
Wie erwartet, wird nur ein leerer Arbeitsbereich angezeigt. Leider erhielt ich einen weiteren dringenden Anruf und bat Bernd, die Arbeit fortzusetzen. Nachdem ich meinen JSL-Code hochgeladen hatte, lud er den aktuellen Stand des Projekts herunter. Er öffnete ihn in JMP und erweiterte das Programm. Seine Änderungen speicherte er in derselben Datei. Anschließend wechselte er zur Git-Erweiterung und erstellte einen neuen Branch. Dadurch kann Git die Änderungen nachverfolgen. Man speichert den aktuellen Stand, und Bernd kann sehen, wo das Programm erweitert wurde. Er übertrug den Stand auch ins Repository. Nach dem Klick auf „Prüfen“ wechselte er zu GitLab. Im Web war ein neuer Branch zu sehen. Er wählte diesen Branch aus und erstellte einen neuen Merge Request.
Im Merge-Request habe ich Britta als Reviewerin benannt und ihr eine Nachricht geschickt. Diese Nachricht bzw. die Informationen erhielt sie automatisch per E-Mail. Wir sehen uns das gerade auf ihrem Laptop an. Sie hat die E-Mail erhalten, dem Link gefolgt, ist zum Repository gelangt und hat den Merge-Request gesehen. Sie hat ihn aufgerufen, gelesen, geprüft und schließlich meine Änderungen bestätigt. Git zeigt an, wo die Änderungen vorgenommen wurden, und der Merge ist abgeschlossen.
Nun sind die beiden Branches wieder mit dem Haupt-Branch vereint. Britta ist wieder im Projekt dabei, und wir beschließen, parallel an verschiedenen Aufgaben zu arbeiten. Der Pull-Vorgang schafft auf beiden Rechnern dieselbe Entwicklungsbasis. Im Beispiel von Brittas Arbeit sieht man, wie sie einen neuen Branch erstellt. Dadurch kann Git ihre Änderungen nachverfolgen. Ich mache das Gleiche auf meinem Rechner – das ist hier nicht zu sehen – und dann setzen wir unsere Programmierarbeit fort, jeder an seiner eigenen Version des Programms.
Wir erstellen beide einen Commit oder Snapshot für unsere Programme. Die Unterschiede zum vorherigen Snapshot sind hervorgehoben. Anschließend pushen wir unsere Branches ins Repository.
Britta schaut auf ihrem Laptop im Web ins Repository und sieht, dass beide Branches vorhanden sind. Sie kommentiert ihren Branch, erstellt dann einen Merge Request und benennt mich als Reviewer.
Bernd arbeitet jetzt von zu Hause aus an seinem Laptop. Er ruft die Webseite auf, öffnet den Merge-Request und genehmigt ihn. Dann wechselt er zum Hauptzweig. Anschließend lädt er den neuen Programmstand auf seinen Laptop, wählt seinen Zweig aus und startet dort einen Merge. Er möchte den Hauptzweig in seinen „Fit a Model“-Zweig integrieren. Oh je, es gibt Konflikte!
Es gibt auch Hilfsmittel, um die Situation zu entschärfen. Bernd verwendet das Meld-Tool, um die verschiedenen Programmversionen zusammenzuführen. Hier sieht man viele Unterschiede. Man kann die Änderungen leicht erkennen, Duplikate entfernen, Teile einfügen und anderen Code kopieren und einfügen. Er speichert die Änderungen, führt einen Commit durch und lädt die Änderungen hoch. Jetzt können wir beide die aktuelle Programmversion abrufen und das fertige Programm mit beiden Teilen ausführen.
Ein Aspekt, der JMP-Nutzer besonders ansprechen dürfte, ist die Visualisierung des gesamten Entwicklungsprozesses und seines aktuellen Status. Es handelt sich dabei nicht um die reine Git-Funktionalität, sondern um eines der vielen Tools, die interaktive Benutzeroberflächen für Git bereitstellen.
Zusammenfassend lässt sich sagen, dass Git einfach einzurichten und benutzerfreundlich ist. Es ermöglicht mühelose Backups, bietet eine robuste Versionskontrolle und vereinfacht die Zusammenarbeit mit Kollegen an Skripten. Ich hoffe, wir konnten Ihnen zumindest einen Einblick in die Verwendung, die Vorteile und die Zugänglichkeit von Git geben. Jetzt sind Sie an der Reihe, einzusteigen – spätestens, wenn Sie wieder an Ihrem Schreibtisch sitzen.
