May the Fork be with you: Editoren und IDEs für IBM i – Teil 4

Weiter geht es mit dem vierten Teil der Serie zu „Editoren und IDEs für die IBM i“. Die vielen Beispiele aus den ersten drei Teilen konnte man selbst umsetzen. In diesem Teil geht es direkt dort weiter, wo wir aufgehört haben. Im nächsten Teil geht es dann mit einem anderen Editor weiter.

Im letzten Teil (Teil 3 der Reihe) wurde das OSSILE-Projekt von GitHub auf die IBM i mittels Git in Orion geklont und ein Blick auf die Quellen geworfen. Die Frage ist nun, wie sich die gemachten Änderungen, die an dem lokal vorliegenden Projekt vorgenommen wurden, wieder in das Hauptprojekt gelangen.

Wie im Bild 1 zu sehen ist, kann man auf GitHub problemlos über den Button „Fork“ eine Kopie eines Projektes erstellen. Diese läuft dann unter dem eigenen Namen und kann beliebig angepasst werden, ohne, dass das Original Projekt davon betroffen ist. Um einen Fork zu erstellen, benötigt man allerdings einen GitHub Account. Wie im letzten Teil erwähnt, können Sie sich dort kostenlos registrieren. Sobald Sie den Fork erstellt haben, klonen Sie diesen via Git in Orion auf Ihre IBM i (s. letzter Teil).

Nun nehmen wir eine kleine Änderung am Code vor und wollen diesen wieder mit der Welt (oder ggf. den Kollegen im Unternehmen) teilen. Ich habe im OSSILE Projekt z.B. einen kleinen Schreibfehler gefunden, den ich korrigiert habe. Dieser befand sich im Projekt „getiptf“ in der Datei „getiptf.cmd“.

Es war ein einfacher Tippfehler, denn dort stand

„Get PTF ftom iPTF site“

Das ftom habe ich in from umbenannt.

Orion speichert ja standardmäßig automatisch alle Änderungen, die ich ausführe, sodass ich nun auf den Git Button in Orion (der 2te von oben auf der linken Seite) klicken kann und meine Änderung via Commit Button bestätige:

Git zeigt mir nochmals die Änderungen und ich schreibe brav meinen Kommentar dazu.

Direkter Sync

Damit mein Repository auf GitHub nun mitbekommt, dass ich etwas lokal bei mir geändert habe, gibt es den praktischen „Sync“ Button im linken Bereich des Bild 2. Klickt man diesen, erscheint eine Meldung am oberen Rand, dass er zunächst die fernen Änderungen holt.

Kaum hat er das angezeigt, merkt der Rechner auch schon, dass er noch Ihre GitHub Zugangsdaten benötigt und bittet um Eingabe.

Geben Sie diese korrekt ein, werden alle Ihre Änderungen übertragen und neue Änderungen vom Server zu Ihnen geholt.

Hat alles funktioniert, stehen Ihre Änderungen nun in GitHub für alle bereit, inkl. Ihres Kommentars, den Sie beim Commit eingegeben haben (siehe Bild 5).

Die Gabel zurückziehen

Somit sind unsere Änderungen in unserer eigenen Kopie (Fork) auf GitHub. Damit jetzt aber das Hauptprojekt davon profitieren kann, müssen wir den verantwortlichen Projektmitgliedern mitteilen, dass wir etwas geändert haben, was für andere auch interessant sein sollte. Dies erledigen wir mittels eines sog. „Pull Requests“.

Klickt man hier auf „New pull request“ erscheint das Bild 7.

Hier in Bild 7 ist noch einmal eine Übersicht der Änderungen zu sehen, damit man auch sicher geht, keinen Blödsinn zu veröffentlichen. Wie zu sehen, kann oben auch noch einmal ein Zweig, sofern vorhanden, ausgewählt werden, um die eigene Änderung aus dem eigenen Fork ggf. in einen Zweig des Hauptprojektes einfließen zu lassen und nicht in den Master. OSSILE hat zum Zeitpunkt der Erstellung dieses Artikels drei Zweige.

Sie erinnern sich noch an die Zweige und deren Vorteile: Ein Zweig dient z.B. dazu, dass ich Programmkorrekturen in mein Projekt einbauen kann, ohne die Arbeiten an neuen Funktionen in meinem Hauptprojekt zu beeinflussen, die u.U. länger dauern. Also erstelle ich einen Zweig aus dem Master für meine neuen Programmfunktionen und einen Zweig für meine Programmkorrekturen. Habe ich meine Programmkorrekturen eingebaut und getestet, führe ich sie wieder mit dem Master zu, während mein Zweig für neue Programmfunktionen unabhängig weiterentwickelt wird.

Ein Klick auf den Button „Create pull request“ und GitHub beginnt mit seiner Arbeit im Hintergrund (Bild 8).

Jetzt wird u.a. geprüft, ob der Quellcode, den ich geändert habe, irgendwelche Konflikte mit dem vorhandenen Code hat und falls ja, wird mir dies angezeigt. Spätestens an dieser Stelle sollte man verstanden haben, warum es in der heutigen Zeit wichtig ist, kleine Module zu erstellen, die jeweils ganz spezifische Funktionen ausführen, denn je größer eine Quellcodedatei ist, desto wahrscheinlicher ist es, dass jemand anderes ebenfalls eine Änderung darin ausführt, die sich mit meiner überschneidet.

Zumindest für Teams gilt das, aber u.U. auch, wenn ich alleine entwickle und z.B. neue Funktionen zu meiner Anwendung hinzufügen will, die aufwendiger sind und zwischendurch kleinere Änderungen oder Verbesserungen ausführen soll. Bei meiner „umfangreichen“ Änderung hatte ich Glück und hatte keine Konflikte, so dass der Request angenommen wurde und nun geprüft wird. Wird er akzeptiert, wird meine Änderung in das Hauptprojekt aufgenommen.

Fazit

Es gäbe natürlich noch einiges mehr zum Thema Orion, Git und GitHub zu berichten. Mit Sicherheit wird das Ein oder andere Thema, wie z.B. die Markdown Auszeichnungssprache, noch in meiner Serie über Open Source Projekte näher beleuchtet. Für die Editoren und DIE-Serie sind wir an dieser Stelle vorerst aber einmal mit Orion durch und kümmern uns im nächsten Teil um einen anderen Editor, mit welchem man u.a. RPG Code komfortabel eintippen kann.

Wie Sie in den letzten vier Teilen sehen konnten, bietet Orion auch auf der IBM i schon einige tolle Funktionen, wenngleich für den reinen RPG Entwickler noch nicht so viele, dass man über eine Alternative zu RDi reden kann. Schaut man aber nur ab und an in den Code, hat Orion den Vorteil, dass man es von überall aus – inkl. Tablett oder gar Smartphone – aufrufen und direkt verwenden kann. Auch ist es immer noch besser, als Free RPG mit SEU oder EDTF zu entwickeln…
Was es noch für Möglichkeiten gibt, RPG Code zu editieren? Lassen Sie sich überraschen…

Markus A. Litters, edvberatung.litters

edvberatung.litters