Umstellung auf MQL5 Algo Forge (Teil 2): Arbeiten mit mehreren Repositorys

Einführung

Im ersten Artikel haben wir mit der Umstellung von der integrierten SVN-basierten MQL5-Ablage in MetaEditor auf eine flexiblere und modernere Lösung auf der Grundlage des Versionskontrollsystems Git begonnen: MQL5 Algo Forge. Der Hauptgrund für diesen Schritt war die Notwendigkeit, Repository-Zweige bei der Arbeit an mehreren Projekten oder an verschiedenen Funktionen innerhalb eines einzelnen Projekts vollständig zu nutzen.

Der Übergang begann mit der Erstellung eines neuen Repositorys in MQL5 Algo Forge und der Einrichtung einer lokalen Entwicklungsumgebung mit Visual Studio Code, zusammen mit den notwendigen MQL5- und Git-Erweiterungen und unterstützenden Tools. Wir haben dann eine .gitignore-Datei zum Repository hinzugefügt, um Standard- und temporäre Dateien von der Versionskontrolle auszuschließen. Alle bestehenden Projekte wurden in einen eigenen Archivzweig hochgeladen, in dem der gesamte zuvor geschriebene Code archiviert wird. Der Hauptzweig wurde leer gelassen und für die Organisation neuer Projektzweige vorbereitet. Auf diese Weise haben wir die Grundlage für die Verteilung verschiedener Projektcodes auf verschiedene Zweige des Repositorys geschaffen.

Seit der Veröffentlichung des ersten Artikels hat MetaEditor jedoch seine Unterstützung für das neue Repository-System erheblich erweitert. Diese Änderungen veranlassen uns, den zuvor beschriebenen Ansatz zu überdenken. Deshalb werden wir in diesem Artikel ein wenig vom ursprünglichen Plan abweichen und untersuchen, wie ein öffentliches Projekt geschaffen werden kann, das andere öffentliche Projekte als Komponenten integriert. Das Projekt, auf das wir uns konzentrieren werden, ist die Entwicklung eines Expert Advisors für mehrere Währungen. Es wurden bereits mehrere Artikel veröffentlicht, in denen die Ansätze für die Codeentwicklung und die Änderungen für dieses Projekt beschrieben werden. Jetzt werden wir die Vorteile der Git-Versionskontrolle voll ausschöpfen, um den Entwicklungsprozess zu organisieren und zu rationalisieren.

Der Weg ist vorgezeichnet

Es ist kaum zu glauben, aber zum Zeitpunkt des letzten Artikels enthielt MetaEditor noch nicht das Menü „Git:“ oder Befehle aus dem Dateikontextmenü für die Arbeit mit MQL5 Algo Forge Repositorys. Infolgedessen war ein erheblicher Aufwand erforderlich, um Workflows mithilfe externer Tools wie Visual Studio Code zu konfigurieren. Da wir nicht wussten, wie MetaEditor die Repository-Unterstützung letztendlich implementieren würde, mussten wir die zu diesem Zeitpunkt verfügbaren Werkzeuge verwenden.

Seitdem haben neue MetaEditor-Versionen eine integrierte Unterstützung für MQL5 Algo Forge eingeführt. MetaQuotes hat außerdem einen neuen Artikel mit dem Titel „Erste Schritte mit MQL5 Algo Forge“ veröffentlicht, in dem die Grundlagen erläutert und die wichtigsten Funktionen demonstriert werden. Die wichtigste Entwicklung ist unserer Meinung nach jedoch die Implementierung von Shared Projects in MetaEditor.

Warum ist das wichtig? Bisher wussten wir, dass der MQL5-Ordner als Repository auf den Git-Servern von MQL5 Algo Forge fungieren würde. Offensichtlich hätte dieses Repository den festen Namen mql5. Dies bedeutete, dass jeder Nutzer ein Repository mit dem Namen mql5 in Algo Forge haben würde. Dieses Repository würde dann in den MQL5-Ordner geklont werden, nachdem ein neues Terminal installiert, die Anmeldung bei der Community vorgenommen und das Repository verbunden wurde. Gleichzeitig hat MQL5 Algo Forge immer die Erstellung zusätzlicher Repositorys erlaubt. Genauer gesagt, keine zusätzlichen, sondern separate, die nichts mit dem Repository mql5 zu tun haben. Das warf natürlich die Frage auf: Wie würde MetaEditor mit diesen anderen Repositorys umgehen? 

Könnten die Nutzer bei jeder Installation des Terminals auswählen, welches Repository sie verwenden wollen? Oder nicht? Wird nur das mql5-Repository unterstützt, sodass die Nutzer gezwungen sind, ihre Arbeit in Zweige für verschiedene Projekte aufzuteilen? Wir haben uns zunächst auf dieses Worst-Case-Szenario vorbereitet. Die Verwaltung mehrerer Projekte über verschiedene Zweige hinweg in einem einzigen Repository ist nicht besonders praktisch. Glücklicherweise erwiesen sich unsere Bedenken als unbegründet.

MetaQuotes hat eine elegantere Lösung eingeführt, die effektiv zwei Probleme auf einmal löst. Auf der einen Seite haben wir das Haupt-Repository namens mql5. Dies funktioniert gut für diejenigen, die bereits mit MQL5 Storage vertraut sind. Sie können nun weiterhin die Versionskontrolle nutzen, ohne sich Gedanken darüber zu machen, welches Versionskontrollsystem darunter liegt.

Andererseits sind alle anderen Nutzer-Repositorys jetzt als Ordner innerhalb von Shared Projects verfügbar. Dies bietet einen neuen Standard-Stammordner neben den bestehenden (wie MQL5, MQL5/Experts, MQL5/Include usw.), der für die Speicherung von Code aus den zusätzlichen Repositorys des Nutzers vorgesehen ist.

Betrachten wir ein Beispiel. Angenommen, wir haben zwei getrennte Repositorys in MQL5 Algo Forge, von denen keines das Standard-MQL5 ist. Das erste Repository (Adwizard) enthält nur Bibliothekscode, d. h. nur Include-Dateien *.mqh, aber keine Dateien *.mq5, die zu einem Expert Advisor oder Indikator kompiliert werden könnten. Das zweite Repository (Simple Candles) enthält *.mq5-Dateien, die die Include-Dateien aus dem ersten Repository verwenden. Der Einfachheit halber bezeichnen wir das erste Repository als Bibliotheks-Repository und das zweite als Projekt-Repository.

Unser Ziel ist es, herauszufinden, wie man Code aus dem Bibliotheks-Repository verwenden kann, während man innerhalb des Projekt-Repositorys entwickelt. Dieses Szenario könnte immer häufiger vorkommen, wenn zum Beispiel Code, der in der mql5.com Code Base geteilt wird, von seinen Autoren auch in MQL5 Algo Forge als öffentliche Repositorys gespiegelt wird. In solchen Fällen könnte das Einbinden eines oder mehrerer Repositorys als externe Bibliotheken in ein Projekt auf die gleiche Weise gehandhabt werden, die wir in diesem Artikel untersuchen werden.

Die ersten Schritte

Betrachten wir die Situation zunächst aus der Sicht des Entwicklers, dem beide Repositorys gehören. Das bedeutet, dass wir Änderungen am Code in beiden Repositorys vornehmen können, ohne auf eine Überprüfung und Genehmigung durch den Pull Request-Mechanismus zu warten. Wir beginnen damit, einen sauberen Terminal-Ordner zu erstellen und zwei Dateien von einer zuvor installierten Kopie von MetaTrader 5 zu kopieren:

Um die Suche nach dem Arbeitsordner des Terminals tief im Dateisystem zu vermeiden, empfehlen wir, das Terminal im portablen Modus zu betreiben. Unter Windows besteht eine Möglichkeit darin, eine Verknüpfung mit der ausführbaren Datei des Terminals zu erstellen und das Flag /portable in das Zielfeld der Verknüpfungseigenschaften einzufügen. 

Eröffnen Sie nach dem Start des Terminals vorsichtshalber ein neues Demokonto, aktualisieren Sie auf die neueste Version, melden Sie sich bei der Community an und starten Sie dann MetaEditor mit der Taste F4. Verbinden Sie es mit MQL5 Algo Forge, falls es sich nicht bereits automatisch verbunden hat.

Im Navigator sehen wir nun den Ordner „Shared Projects“, in dem die Repositorys aufgelistet sind, die wir zuvor über die Weboberfläche erstellt haben. Wenn wir diesen Ordner jedoch im Explorer öffnen, ist er immer noch leer. Dies bedeutet, dass die eigentlichen Repository-Dateien noch nicht auf unseren Computer heruntergeladen worden sind.

Um sie zu klonen, klicken Sie mit der rechten Maustaste auf jedes der benötigten Repositorys und wählen Sie im Kontextmenü „Git Clone“. Das Protokoll bestätigt das erfolgreiche Klonen sowohl von Adwizard als auch von Simple Candles. Die Ordner mit den geklonten Repositorys erscheinen nun im Explorer:

Zu diesem Zeitpunkt ist der Code für beide Projekte lokal verfügbar und einsatzbereit.

Erstes Problem

Wir öffnen SimpleCandles.mq5 und versuchen, es zu kompilieren:

Wie erwartet, treten Kompilierungsfehler auf. Wir wollen versuchen, ihre Gründe zu verstehen. Diese sind nicht kritisch, da wir wissen, dass der Code zuvor erfolgreich kompiliert wurde. Das einzige, was sich geändert hat, ist die relative Platzierung der Bibliotheks- und Projektdateien. Die ersten beiden grundlegenden Fehler kommen daher, dass der Compiler die Bibliotheksdateien nicht dort findet, wo er sie erwartet. In Teil 28 haben wir uns darauf geeinigt, die folgende Ordnerstruktur zu verwenden, um die Bibliothek und die Projektteile zu speichern:

Das heißt, wir speichern die Bibliothek des Repositorys in einem Unterordner des Projekt-Repositorys. Dadurch erhielten wir eine vorhersehbare Struktur für das Auffinden von Bibliotheksdateien. Dieses Mal werden wir das jedoch ändern. Anstelle des obligatorischen Unterordners Include innerhalb des Projekts verwenden wir den Ordner MQL5/Shared Projects. Im Idealfall bleibt dieser Ordner stabil und erfüllt auch in zukünftigen MetaEditor-Versionen den gleichen Zweck.

Um das Problem zu beheben, werden wir die #include-Direktiven in zwei Dateien aktualisieren. Bevor wir jedoch irgendwelche Codeänderungen vornehmen, sollten wir uns an die gute Entwicklungspraxis halten und einen separaten Zweig für diese isolierte Aufgabe erstellen. Sobald die Korrekturen getestet sind, können wir den Zweig wieder mit dem Hauptentwicklungszweig zusammenführen.

Schauen wir uns an, welche Zweige wir bereits im Projekt-Repository haben. Dies kann auf verschiedene Weise geschehen:

• Über das Kontextmenü des Repository-Ordners in MetaEditor: 

• Über die Webschnittstelle auf der Seite der Zweige (branches)

• Verwendung eines externen Git-Tools wie Visual Studio Code. Neben dem Namen des Repositorys sehen wir main, den Namen des aktuellen Zweigs. Ein Klick darauf zeigt eine Liste der verfügbaren Zweige (und Menüpunkte zum Erstellen neuer Zweige):

Derzeit hat das Repository vier Zweige:

• main - der Hauptzweig. Sie wird mit dem Repository erstellt. Im einfachsten Fall kann die gesamte Arbeit hier erledigt werden, ohne dass zusätzliche Zweige angelegt werden. In komplexeren Fällen wird dieser Zweig verwendet, um den Status der Dateien zu speichern, die stabile Versionen des Codes bereitstellen. Alle laufenden Änderungen, die noch nicht abgeschlossen und getestet sind, werden in anderen Zweigen vorgenommen.
• develop - der Entwicklungszweig. In einfachen Fällen kann er als einziger Zweig verwendet werden, um Änderungen hinzuzufügen und neue Funktionen zu implementieren. Diese Option ist ausreichend, wenn neue Funktionen nacheinander eingeführt werden. Das heißt, wir beginnen erst dann mit der Implementierung neuer Funktionen, wenn das Projekt in einem voll funktionsfähigen und stabilen Zustand ist, nachdem wir die vorherigen Funktionen hinzugefügt haben. Bevor mit der Arbeit an einer neuen Funktion begonnen wird, werden die Zweige zusammengeführt: Die im Entwicklungszweig develop vorgenommenen Änderungen werden in den Hauptzweig main übernommen. Wenn mehrere Funktionen gleichzeitig entwickelt werden, wird es unpraktisch, in einem Entwicklungszweig zu arbeiten. In solchen Fällen können zusätzliche Feature-Zweige erstellt werden.
• Beispiele für derartige Verzweigungen sind die Artikel article-17608-close-manager und 17607. Ersteres ist ein Funktionszweig für eine auf Gewinn-/Verlustschwellen basierende Positionsschließungslogik. Dieser Zweig ist bereits mit develop zusammengeführt und develop wird dann mit main zusammengeführt. Der zweite Funktionszweig wird für Verbesserungen der automatischen Optimierung verwendet. Sie ist noch in Arbeit und noch nicht in die develop oder main integriert.

Es ist wichtig zu betonen, dass Git keine speziellen Regeln für die Verwendung von Zweigen vorschreibt. Wir können also die Option wählen, die für uns am bequemsten ist. Es gibt bestimmte Arbeitsabläufe, die einige Entwickler nützlich fanden und mit anderen geteilt haben. So sieht „Best Practices“ aus. Es steht Ihnen frei, das für Ihr Projekt passende Verzweigungsmodell zu übernehmen oder anzupassen. Sehen Sie sich als Beispiel einen der vorgeschlagenen Verzweigungsgrundsätze an, die in diesem Artikel beschrieben sind.

Kehren wir nun zu unserem Repository zurück.

Ein Detail, das Fragen aufwerfen kann, ist das Präfix origin/ (oder refs/remotes/origin/, wie in MetaEditor angezeigt). Dieses Präfix zeigt einfach an, dass der Zweig im entfernten Repository existiert, nicht nur lokal. Normalerweise halten wir lokale und entfernte Zweigstellen synchronisiert. In MetaEditor löst die Ausführung eines Commit-Befehls automatisch einen Push-Befehl aus, sodass der Commit an das entfernte Repository gesendet wird.

Wenn Commits außerhalb von MetaEditor gemacht werden, ist es möglich, lokal zu committen, ohne zu pushen. In solchen Fällen können der lokale und der entfernte Zweig mit demselben Namen unterschiedlich sein. Der Präfix origin/ hilft, sie zu unterscheiden. Mit diesem Präfix ist ein Zweig in einem entfernten Repository gemeint; andernfalls ist es ein lokaler Zweig.

Einen neuen Zweig erstellen

Da die geplanten Änderungen nur sicherstellen, dass der Code korrekt kompiliert wird, nachdem die Platzierung des Bibliotheksteils geändert wurde, werden wir einen neuen Zweig aus der Entwicklungsumgebung develop erstellen. Wir wechseln zunächst zu origin/develop, woraufhin es in der Liste als lokales develop erscheint.

Dann erstellen wir einen neuen Zweig (führen den Befehl New (Neu) aus) und geben den gewünschten Namen ein. Unserer Konvention folgend, beginnen artikelbezogene Verzweigungen mit article- und dem eindeutigen Bezeichner des Artikels. Optional kann ein kurzes Suffix folgen, das das Thema des Artikels beschreibt. Deshalb trägt der neue Zweig den Namen „article-17698-forge2“.

Wir könnten eine Verzweigung auch auf andere Weise erstellen: über die Webschnittstelle, die Visual Studio Code-Schnittstelle oder die Befehlszeilenschnittstelle. Von der Befehlszeile im Stammordner des Repositorys aus können wir Folgendes ausführen:

git checkout -b article-17698-forge2 develop

Dies weist Git an, zu einem neuen Zweig (-b) namens article-17698-forge2 zu wechseln (checkout), der auf dem Entwicklungszweig basiert.

Wenn eine Verzweigung außerhalb der Weboberfläche erstellt wird, existiert sie nur auf unserem lokalen Rechner, bis der erste Push an das entfernte Repository erfolgt. Auch das Gegenteil ist der Fall: Wenn ein Zweig im entfernten Repository über die Weboberfläche erstellt wird, erscheint er auf unserem lokalen Rechner erst nach dem ersten Pull aus dem entfernten Repository.

Sie können Änderungen wie diese vornehmen:

oder so:

Der Konsolenbefehl für die Push-Operation muss, wenn er die Erstellung eines neuen Zweigs beinhaltet, zusätzliche Parameter enthalten, die bestätigen, dass der Zweig wirklich im entfernten Repository erstellt werden soll:

git push --set-upstream origin article-17698-forge2

Danach existiert der Zweig sowohl in der lokalen Kopie des Repositorys als auch in dem in MQL5 Algo Forge gehosteten Remote-Repository. Jetzt können wir Änderungen vornehmen, ohne befürchten zu müssen, dass die Funktionalität anderer Zweige beeinträchtigt wird.

Änderungen vornehmen

Die erforderlichen Änderungen sind sehr einfach. In der Datei SimpleCandles.mq5 aktualisieren wir die Zeile, die eine Datei aus der Adwizard-Bibliothek enthält. Da sich die Stammordner der Repositorys Simple Candles und Adwizard nun auf der gleichen Ebene innerhalb des Ordners Shared Projects befinden, muss der Pfad zu Expert.mqh zunächst eine Ebene nach oben (../) gehen, bevor er in die Unterordner des Bibliotheks-Repositorys absteigt:

#include "Include/Adwizard/Experts/Expert.mqh"
#include "../Adwizard/Experts/Expert.mqh"

Eine ähnliche Anpassung ist in der Datei Strategies/SimpleCandlesStrategy.mqh erforderlich:

#include "../Include/Adwizard/Virtual/VirtualStrategy.mqh"
#include "../../Adwizard/Virtual/VirtualStrategy.mqh"

Nach diesen Änderungen wird SimpleCandles.mq5 wieder erfolgreich kompiliert. Jetzt können wir die Änderungen an das Repository übergeben:

Wie bereits erwähnt, wird bei der Übergabe über die MetaEditor-Schnittstelle automatisch der Push-Befehl ausgeführt, der die Änderungen an das entfernte Repository in MQL5 Algo Forge sendet.

Wenn wir mit Konsolenbefehlen arbeiten, können wir das gleiche Ergebnis wie folgt erreichen. Wenn wir nicht nur bestehende Dateien bearbeiten, sondern auch neue erstellen, müssen wir diese zunächst dem Repository-Index hinzufügen:

git add .

Dieser Befehl fügt alle neuen Dateien hinzu, die im Repository-Ordner gefunden werden. Um nur bestimmte Dateien hinzuzufügen, ersetzen Sie den Punkt (.) durch deren Namen. Danach werden die Änderungen mit einem bestimmten Kommentar versehen und an das entfernte Repository übertragen:

git commit -m "Fix relative paths to include files from Adwizard"
git push

Zu diesem Zeitpunkt sind die Änderungen im Zweig article-17698-forge2 abgeschlossen. Er kann mit dem Entwicklungszweig zusammengeführt und dann geschlossen werden.

Zweites Problem

Hier erleben wir eine unangenehme Überraschung. MetaEditor verfügt derzeit nicht über Werkzeuge zum Zusammenführen von Zweigen. Mit anderen Worten: Wir können jetzt neue Zweige erstellen, aber wir können keine Änderungen von einem Zweig in einen anderen übertragen! Hoffentlich wird diese Funktion in naher Zukunft hinzugefügt. Für den Moment müssen wir wieder einmal auf alternative Werkzeuge zurückgreifen, um Repository-Operationen durchzuführen.

Es gibt im Wesentlichen zwei Möglichkeiten, Zweige zusammenzuführen. Die erste Möglichkeit besteht darin, die Zusammenführungsschnittstelle in Visual Studio Code oder Standardkonsolenbefehle zu verwenden. In unserem Fall können die folgenden Befehle verwendet werden:

git checkout develop
git pull
git merge --no-ff article-17698-forge2

Zunächst wechseln wir in den Entwicklungszweig. Dann aktualisieren wir sie vorsichtshalber (für den Fall, dass Änderungen vorgenommen wurden, die unseren lokalen Rechner noch nicht erreicht haben). Der letzte Befehl schließlich führt die eigentliche Zusammenführung durch. Merge-Konflikte sind möglich, aber in unserem Szenario unwahrscheinlich, da wir immer noch den Fall betrachten, dass ein einzelner Entwickler an dem Projekt arbeitet.

Wir wollen uns jedoch nicht mit den Feinheiten dieser Methode aufhalten. Stattdessen werden wir uns den zweiten Ansatz genauer ansehen. Hier verwenden wir die Webschnittstelle von MQL5 Algo Forge.

Pull Requests zum Zusammenführen verwenden

Wie andere Git-basierte Plattformen (z. B. GitHub, GitLab oder Bitbucket) enthält auch MQL5 Algo Forge einen Mechanismus namens Pull Request (PR).

Ein Pull Request ermöglicht es einem Entwickler, Änderungen in einem Zweig vorzuschlagen, die in ein Repository zusammengeführt werden sollen. Mit anderen Worten: Die Erstellung eines PR ist eine Möglichkeit, den Eigentümer des Repository und andere Mitwirkende zu benachrichtigen: „Ich habe die Arbeit in meinem Zweig abgeschlossen, bitte überprüfen Sie diese Änderungen und führen Sie sie in den Hauptzweig (main/master/develop) ein.“

Ein PR ist keine Funktion von Git selbst, sondern eine zusätzliche Schicht, die auf Git aufbaut. Er organisiert den Prozess der Codeüberprüfung und -diskussion, bevor die Änderungen in den Hauptzweig übernommen werden.

Pull Requests lösen auch mehrere andere wichtige Aufgaben in der modernen Entwicklung: kontinuierliche Integration (CI) mit automatisierten Tests, Qualitätskontrolle durch andere Entwickler und Dokumentation von Änderungen in Form von PR-Kommentaren, die erklären, warum bestimmte Änderungen vorgenommen wurden. Diese Praktiken sind jedoch vor allem für teambasierte Projekte relevant, während MQL5-Projekte in der Regel Einzelprojekte sind. Auf jeden Fall könnte der Arbeitsablauf mit der Entstehung von Gemeinschaftsprojekten in Zukunft an Bedeutung gewinnen.

Allerdings haben wir bereits den Beginn eines typischen Workflows zum Hinzufügen neuer Funktionen oder Korrekturen mithilfe von PRs repliziert:

1. Laden wir die letzten Änderungen. Vor Beginn der Arbeiten haben wir das lokale develop aktualisiert.

2. Wir erstellen einen neuen Zweig für die Aufgabe. Aus dem aktualisierten Entwicklungszweig develop haben wir einen Zweig mit dem eindeutigen Namen article-17698-forge2 erstellt.

3. Nehmen wir Änderungen im neuen Zweig vor. Wir haben mehrere Dateien geändert und getestet und die Änderungen dann festgeschrieben.

Die nächsten Schritte sind wie folgt.

4. Wir erstellen einen Pull Request. Wir navigieren in der Weboberfläche von MQL5 Algo Forge zur Registerkarte Pull Requests und klicken auf die große rote Schaltfläche 'New pull request'.

Dies öffnet die Seite für die Auswahl des Zweigs. In diesem Stadium ist der PR noch nicht erstellt worden; zunächst muss festgelegt werden, wo die Änderungen zusammengeführt werden sollen. Sobald die Zweige ausgewählt sind, können wir die Liste der Änderungen überprüfen. Dann klicken wir erneut auf „Neue Pull-Anfrage“.

Es öffnet sich eine neue Seite, auf der wir die Änderungen detailliert beschreiben können. Hier können wir auch Gutachter zuweisen. Standardmäßig wird die Anfrage an uns selbst gerichtet, was genau das ist, was wir in diesem Fall brauchen.

5. Überprüfung und Diskussion. Da wir alleine arbeiten, können wir diesen Schritt auslassen. Normalerweise umfasst diese Phase:

   • Prüfer, die den Code untersuchen und (allgemeine oder auf bestimmte Zeilen bezogene) Kommentare hinterlassen,

   • der PR-Autor antwortet auf Kommentare und nimmt Korrekturen im selben Zweig vor,

   • und alle neuen Vorstöße werden automatisch zum bestehenden PR hinzugefügt.

6. Verschmelzung. Nachdem die Reviewer zugestimmt haben (falls vorhanden) und die CI erfolgreich war (falls konfiguriert), kann der PR zusammengeführt werden. In der Regel gibt es mehrere Zusammenführungsoptionen:

• Merge commit: Erzeugt einen separaten vereinigten Commit, wobei die Historie des Zweigs erhalten bleibt.

• Squash und Merge: Fasst alle PR-Commits zu einem einzigen Commit zusammen, der dem Zielzweig hinzugefügt wird. Nützlich, um zu vermeiden, dass die Historie mit unbedeutenden Übertragungen wie „Tippfehler behoben“ überladen wird.

• Rebase and merge: Überträgt PR-Commits auf den Zielzweig (in unserem Fall ist das develop). So entsteht ein sauberer, linearer Verlauf.

Für unsere Zwecke wählen wir die erste Option, da wir den gesamten Commit-Verlauf erhalten wollen. Klicken Sie also auf „Create merge commit“.

Jetzt kommt die letzte Seite der Operationen von Pull Request. Hier aktivieren wir die Option 'Delete branch ...', um den temporären Entwicklungszweig zu schließen. Die Commit-Historie zeigt weiterhin, dass der Zweig existiert. Aber es ist sinnlos, sie offen zu halten, da wir unser Ziel erreicht haben. Für zukünftige Änderungen, die andere Aufgaben lösen, werden wir neue Zweige erstellen. Auf diese Weise bietet die Zweigliste des Repositorys immer einen klaren Überblick über die derzeit parallel laufenden Arbeiten.

Lassen Sie die restlichen Einstellungen unverändert und klicken Sie auf „Create merge commit“.

Der Prozess ist nun abgeschlossen: Der Zweig article-17698-forge2 wurde in develop zusammengeführt und gelöscht:

Im Allgemeinen ist die Verwendung von Pull Requests sogar in Ihrem eigenen Repository eine gute und empfohlene Praxis, sogar für Einzelprojekte. Vor dem Zusammenführen können alle Änderungen visuell überprüft und dabei oft Dinge entdeckt werden, die bei den Übertragungen übersehen wurden: unnötige Kommentare, verirrte Dateien oder nicht optimale Bearbeitungen. Im Grunde ist dies eine Form der Selbstdisziplin. Darüber hinaus führt die Übernahme dieses Arbeitsablaufs zu guten Gewohnheiten (Verzweigung, Code-Review usw.). Wenn Sie später in ein Entwicklungsteam eintreten, wird Ihnen dieser Prozess also bereits vertraut sein.

Ja, es ist nicht nur möglich, sondern bei jedem ernsthaften Projekt sogar erwünscht, sich selbst PRs zukommen zu lassen. Es verbessert die Codequalität und sorgt für Disziplin. Für schnelle Korrekturen, die aus einem oder zwei Commits bestehen, können Sie natürlich auch direkt mit git merge zusammenführen. Bei größeren Änderungen ist eine PR jedoch der bessere Ansatz.

Schlussfolgerung

Insgesamt ist der Arbeitsablauf mit persönlichen Repositorys nun gut etabliert. Wir haben den Weg vom Klonen von Repositorys bis zur Verfeinerung eines Prozesses, bei dem Änderungen den Code funktionsfähig und für die weitere Entwicklung bereit machen, behandelt. Das Projekt-Repository kann nun sinnvollerweise Code aus einem anderen Repository (oder mehreren) als Bibliotheken verwenden.

Wir haben jedoch nur ein Szenario betrachtet: wenn derselbe Nutzer sowohl das Projekt als auch die Bibliothek besitzt. Das andere Szenario ist, dass der Projekteigentümer die Repositorys eines anderen als Bibliotheken verwenden möchte. Dieser Fall ist nicht so einfach. Und doch war diese Art von Arbeitsablauf, mit aktiver Wiederverwendung von Gemeinschaftscode und Zusammenarbeit, eines der erklärten Ziele bei der Umstellung auf das neue Repository-System. Der Grundstein ist jedoch gelegt.

Wir werden hier vorerst aufhören. Wir sehen uns im nächsten Teil!