Verwalten Ihrer Projekte mit Versionskontrolle
Sie können Versionskontrolle verwenden, um die Entwicklung eines Datenprojekts zu verwalten und die Änderungen zu verfolgen.
Wenn Sie mit Versionskontrolle arbeiten, können Sie während des Entwurfs ein Commit für Versionen der Projekte durchführen. Damit können Sie Änderungen zwischen zwei Versionen des Projekts anzeigen. Sie können Ihre Datenprojekte auch mit einer Verzweigungsstrategie entwickeln. So können Sie in jedem Arbeitsbereich oder Zweig an einer isolierten Version des Projekts arbeiten. Der Arbeitsbereich kann von mehreren Benutzern gemeinsam genutzt werden. Sie können dann Ihre Änderungen aus dem Arbeitsbereich in einen Hauptzweig zusammenführen und aus der Entwicklung in die Produktion übertragen.
GitHub wird als Anbieter für die Versionskontrolle verwendet.
Erste Schritte
-
Erstellen Sie einen Benutzer in GitHub, den der Mandant für den Zugriff auf GitHub verwenden kann. Möglicherweise wurde der Benutzer bereits von einem Administrator für Sie erstellt.
Der Benutzer muss über die folgenden Bereiche verfügen:
-
repo
-
read:org
-
read:user
-
read:project
-
-
Sie benötigen Schreibzugriff auf die Repositorys, die Sie ändern möchten.
-
Sie müssen ein persönliches GitHub-Zugriffstoken („classic“) erstellen. Persönliche Zugriffstoken des Typs „fine-grained“ werden nicht unterstützt.
Weitere Informationen finden Sie in der GitHub-Dokumentation unter Verwaltung deiner persönlichen Zugriffstoken.
-
Die Organisation ist in der GitHub-Konfiguration obligatorisch.
-
Sie benötigen die Rolle „Kann bearbeiten“ in dem Bereich, in dem sich das Projekt befindet, um Aktionen zur Versionskontrolle durchzuführen.
-
Bevor Sie mit der Versionskontrolle beginnen können, müssen Sie die Verbindung zu GitHub mit dem zuvor erstellten GitHub-Benutzer einrichten.
-
Nachdem Sie eine Verbindung zu GitHub eingerichtet haben, können Sie ein Projekt mit einem Repository verbinden.
Einrichten der Konfiguration für GitHub
Alle Benutzer, die mit Versionskontrolle arbeiten möchten, müssen eine Konfiguration für die Verbindung mit GitHub über ein GitHub-Benutzerkonto einrichten.
GitHub-Verbindung

Sie können GitHub unter Projekte konfigurieren. Stellen Sie sicher, dass Sie sich gemäß Erste Schritte vorbereitet haben.
-
Klicken Sie auf
und dann auf GitHub-Konfiguration.
-
Richten Sie die Authentifizierung mit Ihrer Organisation und dem persönlichen GitHub-Zugriffstoken ein, wie unter Erste Schritte beschrieben.
-
Klicken Sie auf OK.
Sie können Ihre Projekte jetzt mit einem Repository verbinden.
Verbinden eines Projekts mit einem Repository
Sie müssen ein Projekt mit einem Repository verbinden, bevor Sie mit der Nutzung der Versionskontrolle beginnen können. Stellen Sie sicher, dass Sie eine Verbindung zu GitHub eingerichtet haben.
Verbinden Sie ein Projekt mit der Versionskontrolle.

-
Klicken Sie in Projekte für ein Projekt auf ... und wählen Sie Mit Versionskontrolle verbinden aus.
-
Wählen Sie das Repository aus, mit dem das Projekt verknüpft werden soll.
-
Fügen Sie einen Basisverzeichnispfad hinzu.
Wenn Sie eine Verbindung zu einem vorhandenen Projekt in GitHub herstellen möchten, müssen Sie den gleichen Pfad verwenden.
-
Sie können festlegen, dass das Projekt nach der Verbindung mit einem Commit- und Push-Vorgang an das Remote-Repository übertragen wird. Geben Sie eine Commit-Nachricht ein.
Wenn Sie nicht sofort einen Commit- und Push-Vorgang durchführen, wird ein Hauptzweig im Arbeitsbereich, aber nicht im Remote-Repository erstellt.
-
Klicken Sie auf Verbinden.
Das Projekt ist nun mit dem ausgewählten Repository verbunden. Dies wird am unteren Rand der Projektkarte mit , dem Namen des Repositorys und dem aktuellen Zweig angezeigt.
Wenn Sie das Projekt öffnen, enthält die Titelzeile jetzt ein GitHub-Menü mit Optionen zur Versionskontrolle. Dem Projektnamen wird außerdem der Name des aktuellen Zweigs angehängt.
Entwickeln eines Projekts mit Versionskontrolle
Sie können die Versionskontrolle mit verschiedenen Ansätzen nutzen:
-
Arbeiten Sie direkt am Hauptzweig. Diese Funktion eignet sich vor allem für einen einzelnen Entwickler eines Projekts, der Änderungen nachverfolgen möchte. Sie kann aber auch von einer Gruppe von Entwicklern verwendet werden, die synchronisiert arbeiten.
-
Arbeiten Sie mit einer Verzweigungsstrategie, zu der mehrere Entwickler beitragen können. Sie können auch Zweige erstellen, um neue Funktionen oder Änderungen voneinander zu isolieren.
Vereinfachter Workflow für ein Projekt mit nur einem Entwickler
Sie können direkt am Hauptzweig eines Projekts arbeiten. Dieser Ansatz ist einfacher und beinhaltet weniger Vorgänge, ermöglicht aber die Verfolgung der Änderungen. Wenn es mehr als einen Entwickler gibt, müssen die Entwickler darauf achten, synchronisiert zu arbeiten.
Wenn Sie Änderungen an dem Projekt vorgenommen haben, die Sie übernehmen möchten, führen Sie einfach einen Commit und Push aus.
Workflow für ein Projekt mit mehreren Entwicklern
Dieser Workflow kann verwendet werden, wenn mehr als ein Entwickler an einem Projekt arbeitet oder wenn Sie Änderungen isolieren möchten. Dazu müssen Sie einen Entwicklungszweig erstellen, den Sie mit anderen Benutzern teilen können. Mit diesem Workflow können die Entwickler die Änderungen der anderen verfolgen und entscheiden, wann sie die Änderungen mit dem Hauptzweig zusammenführen.
Workflow für ein Projekt mit mehreren Entwicklern und Versionskontrolle

-
Einen neuen Zweig erstellen
Erstellen Sie einen neuen Entwicklungszweig aus dem Hauptzweig. Sie können den Zweig mit mehreren Benutzern teilen.
-
Entwickeln
Nehmen Sie alle erforderlichen Änderungen am Projekt vor.
InformationshinweisDatenbankschemas und Verbindungen werden nicht in der Versionskontrolle gepflegt. -
Remoteänderungen anwenden
Wenden Sie Remoteänderungen aus einem anderen Zweig auf Ihren Arbeitsbereich an, um sicherzustellen, dass Sie mit den Änderungen aus dem anderen Zweig auf dem neuesten Stand sind. Dies ist hilfreich, um konfliktierende Änderungen zu vermeiden oder Probleme abzumildern.
Wenn Sie zwei Zweige mit Änderungen haben, die möglicherweise konfliktieren, können Sie folgende Problemumgehung verwenden:
-
Führen Sie ein Commit der Änderungen in beiden Arbeitsbereichen durch.
-
Führen Sie beide Zweige im Hauptzweig zusammen.
-
Wenden Sie die Remoteänderungen erneut an.
-
-
Commit und Push
Führen Sie für Ihre Änderungen einen Commit- und Push-Vorgang in den Entwicklungszweig durch. Der Push wird auf alle Objekte angewendet; daher ist es ratsam, Ihr Projekt zu validieren, bevor Sie den Commit-Vorgang durchführen.
-
Eine Pull-Anforderung öffnen und zusammenführen
Wenn Sie mit der Entwicklung fertig sind, müssen Sie die Änderungen aus dem Arbeitsbereich mit dem Hauptzweig zusammenzuführen. Das Zusammenführen eines Entwicklungszweigs mit dem Hauptzweig muss in GitHub erfolgen. Öffnen Sie hierzu eine Pull-Anforderung. Sie können eine Genehmigung für den Zweig einrichten, der mit dem Hauptzweig zusammengeführt werden soll. Weitere Informationen finden Sie in der Dokumentation zu GitHub-Pull-Anforderungen
Erstellen eines neuen Zweigs
-
Klicken Sie in Projekte für ein Projekt auf ... und wählen Sie Neuen Zweig erstellen aus.
Das Projekt muss mit der Versionskontrolle verbunden sein. Sie müssen auch die Berechtigung für den Bereich haben, in dem sich die Zielverbindung des Projekts befindet.
-
Wählen Sie diese Option, um einen Zweig vom Hauptzweig aus zu erstellen.
-
Geben Sie einen Namen für den Zweig ein.
-
Legen Sie in Zweigpräfix für alle Schemas ein Präfix fest, das allen Schemas im Projekt hinzugefügt wird. Dadurch können alle Schemas eindeutig benannt werden, um Namenskonflikte zu vermeiden.
-
Klicken Sie auf Erstellen.
Es wird ein neuer Zweig vom Hauptzweig aus erstellt und aus dem Repository ausgecheckt. Der Zweig enthält eine neue Version des Projekts mit allen Aufgaben im Status „Neu“. Das bedeutet, dass sie nicht vorbereitet sind und keine Daten enthalten.
Anwenden von Remoteänderungen
Sie können Änderungen aus dem Remote-Repository auf Ihren Arbeitsbereich anwenden. Dabei kann es sich um Änderungen handeln, die außerhalb der in Qlik Cloud integrierten Versionskontrolle erstellt wurden, z.B. in GitHub oder durch andere Tools. Dies hilft Ihnen, Konflikte zu vermeiden, wenn Sie Ihre Änderungen mit Commit und Push an den Zweig übergeben möchten.
-
Klicken Sie in Projekte für ein Projekt auf ... und wählen Sie Remoteänderungen übernehmen aus.
Das Dialogfeld Remoteänderungen auf Arbeitsbereich anwenden wird angezeigt, wenn Änderungen gefunden wurden.
-
Sie können nun auswählen, für welche Aufgaben die Änderungen angewendet werden sollen, und die Änderungen überprüfen. Für jede Änderung können Sie auswählen, welche Version Sie verwenden möchten: die Remote-Version oder die Version in Ihrem Arbeitsbereich.
-
Klicken Sie auf Remoteänderungen übernehmen.
Sie müssen Quellverbindungen und Zielverbindungen hinzufügen, wenn die Änderungen neue Datenaufgaben umfassen.
Commit und Push
Sie können für Ihre Änderungen einen Commit- und Push-Vorgang zum Anwenden auf den Zweig durchführen. Da Remoteänderungen, die nicht auf Ihren Arbeitsbereich angewendet werden, überschrieben werden können, sollten Sie Remoteänderungen übernehmen, bevor Sie Commit und Push durchführen.
-
Klicken Sie in Projekte für ein Projekt auf ... und wählen Sie Commit und Push aus.
Das Dialogfeld Commit und Push wird angezeigt, wenn Änderungen gefunden wurden.
-
Fügen Sie eine Commit-Nachricht hinzu, die Sie dabei unterstützt, die Änderungen nachzuverfolgen.
-
Klicken Sie auf Commit und Push.
Löschen eines Zweigs
Sie können einen Zweig löschen, nachdem Sie Ihre Änderungen mit dem Hauptzweig zusammengeführt haben.
-
Klicken Sie in Projekte für den zu löschenden Zweig auf ... und wählen Sie Zweig löschen aus.
Sie können den Remote-Zweig auch in der Versionskontrolle löschen.
Wenn es noch Änderungen gibt, für die kein Commit durchgeführt wurde, müssen Sie bestätigen, dass diese Änderungen beim Löschen des Zweigs verloren gehen.
Entfernen der Versionskontrolle für ein Projekt
Sie können Ihr Projekt von der Versionskontrolle trennen. Wenn es bereits Zweige gibt, müssen diese gelöscht werden, bevor Sie das Projekt trennen können.
-
Klicken Sie in Projekte für das zu trennende Projekt auf ... und wählen Sie Von GitHub trennen aus.
Freigeben eines Projekts an andere Bereiche oder Mandanten
Sie können eine Version eines Projekts in einem anderen Bereich in demselben Mandanten oder in einem anderen Mandanten freigeben. Dies ist nützlich, wenn Sie zwei Umgebungen erstellen möchten, z. B. eine für die Entwicklung und eine für die Produktion.
-
Erstellen Sie ein neues Projekt mit demselben Namen wie das ursprüngliche Projekt.
Legen Sie den gleichen Anwendungsfall und Plattformtyp fest. Sie können verschiedene Verbindungen verwenden.
-
Verbinden Sie das neue Projekt mit demselben Repository und Basisverzeichnispfad wie das ursprüngliche Projekt.
InformationshinweisWählen Sie nicht die Option Commit und Push aus. -
Wenn die Plattformverbindung auf das gleiche Ziel wie das ursprüngliche Projekt zeigt, stellen Sie sicher, dass Sie die Datenbank oder die Schemas der Datenaufgaben ändern. Eine Möglichkeit, die Schemas aller Aufgaben zu ändern, besteht darin, das Präfix für alle Schemas in den Metadaten-Projekteinstellungen zu ändern, bevor Sie die Remoteänderungen anwenden. Dadurch wird sichergestellt, dass alle Aufgaben mit diesem Präfix erstellt werden.
-
Wenden Sie Remoteänderungen an, indem Sie alle Dateien auswählen.
-
Fügen Sie fehlende Quellverbindungen für alle Bereitstellungsaufgaben hinzu.
Klicken Sie in der Bereitstellungsaufgabe auf Quelldaten auswählen, wählen Sie die Verbindung aus und klicken Sie auf Speichern.
InformationshinweisDie Verbindung muss vom gleichen Quelltyp sein und auf Tabellen mit den gleichen Namen wie im Originalprojekt zeigen. -
Fügen Sie fehlende Quell- und Zielverbindungen für alle Replikationsaufgaben hinzu.
Damit wird ein weiterer Arbeitsbereich erstellt. Sie können Änderungen am Projekt in einem der Arbeitsbereiche vornehmen und mit Remoteänderungen übernehmen den anderen Arbeitsbereich synchronisieren.
Sicherheitsüberlegungen
Stellen Sie sicher, dass Sie synchronisierte Sicherheitskonfigurationen zwischen Qlik Talend Data Integration und GitHub pflegen.
-
In Qlik Talend Data Integration basieren die Berechtigungen auf Bereichen, die mehrere Projekte enthalten können. In GitHub basieren die Berechtigungen auf Repositorys, die ebenfalls mehrere Projekte enthalten können. Als Best Practice wird empfohlen, sie aneinander auszurichten und alle Projekte in einem Bereich mit demselben Repository zu verbinden.
-
Beachten Sie, dass Qlik Talend Data Integration und GitHub unterschiedliche Berechtigungen und Rollen für Benutzer verwenden.
Bewährte Praktiken
Hier finden Sie einige allgemeine Best Practices für die Arbeit mit Projekten, die Versionskontrolle verwenden.
-
Fügen Sie eine README-Datei hinzu, die das Repository in GitHub beschreibt. Weitere Informationen finden Sie unter Info zu READMEs.
Wenn Sie mit einem leeren Repository beginnen, fügt die Versionskontrolle von Qlik Talend Cloud automatisch eine leere README.md-Datei hinzu.
-
Im Allgemeinen sollten Sie das GitHub-Repository von der Qlik Talend Cloud Versionskontrolle verwalten lassen.
-
Führen Sie nur ein Commit für Projekte durch, die gültig und für die Ausführung getestet sind.
Wenn Sie Projekte mit Bereitstellungsaufgaben oder Aufgaben für registrierte Daten hinzufügen, die noch nicht vorbereitet oder umgewandelt wurden, sind die Quellspalten noch nicht enthalten. Quellspalten werden hinzugefügt, nachdem die Aufgaben vorbereitet und umgewandelt wurden.
-
Wenn Sie einen Zweig für Replikationsprojekte erstellen, sollten Sie wissen, dass die Zweige standardmäßig dasselbe Ziel verwenden. Das bedeutet, dass laufende Aufgaben im Zweig die Daten der Hauptversion überschreiben können. Um Datenverlust zu vermeiden, ändern Sie die Zieleinstellungen im Zweig so, dass sie nicht mit der Hauptversion in Konflikt geraten.
-
Wenn Sie einen Zweig erstellen, gibt es möglicherweise Remoteänderungen, die noch nicht im Arbeitsbereich übernommen wurden. Übernehmen Sie Remoteänderungen entweder vor oder nach der Erstellung des Zweigs, es sei denn, Sie möchten die Remoteänderungen verwerfen.
-
Wenn Sie Änderungen am gleichen Datensatz in zwei verschiedenen Zweigen vornehmen, kann dies zu Konflikten bei der Zusammenführung führen, die nur schwer zu lösen sind.
Arbeiten in Zweigen
Sie können ein Projekt erstellen, es entwerfen und wenn es fertig ist, über den MAIN-Zweig für die Produktion bereitstellen. Die Version in MAIN entspricht Ihrer Produktionspipeline. Bearbeiten Sie den MAIN-Zweig außer bei der ersten Bereitstellung nie direkt.
Jedes Mal, wenn ein Entwickler eine neue Änderung an einem Projekt vornehmen möchte, z. B. das Hinzufügen einer Funktion oder Korrigieren eines Fehlers, muss ein neuer Zweig erstellt werden.
Entwickler können eine beliebige Anzahl von Zweigen für ihre Entwicklungsanforderungen erstellen.
-
Verwenden Sie Schemapräfixe für Zweige, um Datenbankkonflikte bei der Durchführung der Änderungen zu vermeiden.
-
In einem Zweig können die Entwickler beliebig viele Änderungen vornehmen und so oft wie nötig Commit- und Push-Vorgänge durchführen. Es wird empfohlen, jede Änderung in einem eigenständigen, separaten Commit zu isolieren. Wenn Sie beispielsweise eine Änderung an einer Umwandlungsaufgabe vornehmen, die sich auch auf den Data Mart auswirkt, stellen Sie sicher, dass Sie beide Änderungen in einen einzigen Commit einschließen.
-
Alle Teammitglieder sollten jederzeit die Funktion Remoteänderungen anwenden verwenden, um sicherzustellen, dass ihr MAIN auf dem neuesten Stand ist, insbesondere bevor sie ein Commit ihrer Änderungen durchführen.
Wenn die Entwickler mit der Arbeit an ihrem Zweig fertig sind, können sie eine Pull-Anforderung zur Überprüfung durch Kollegen erstellen.
Sie erstellen Pull-Anforderungen in GitHub unter Pull-Anforderungen. Sie müssen den Zweig angeben, von dem aus Sie eine Pull-Anforderung erstellen möchten.
Nach der Überprüfung und Genehmigung durch andere Teammitglieder können Sie die Pull-Anforderung mit der MAIN-Version zusammenführen.
Verwenden Sie abschließend Remoteänderungen anwenden im Projekt, um die genehmigten Zweigänderungen per Pull zurück an den MAIN-Zweig (Produktion) zu übertragen.
Arbeiten in Bereichen
Bei größeren und kritischen Bereitstellungen empfiehlt es sich, dedizierte Bereiche für Entwicklung und Produktion zu verwenden, um Änderungen zu isolieren und die Integrität der Pipeline sicherzustellen. Verwenden Sie dedizierte Datenverbindungen für Quellen und Ziele in jedem Bereich.
-
Produktion
Der MAIN-Zweig entspricht dem, was sich in der Produktion befindet. Das bedeutet, dass es nur eine MAIN-Version eines Projekts gibt.
Die Produktion wird in einem dedizierten Datenbereich isoliert, z. B. PROD. Dedizierte Verbindungen werden dem Produktionsbereich zugewiesen.
Es werden keine Änderungen direkt im Produktionsbereich/MAIN-Zweig vorgenommen. Alle Änderungen werden in anderen Bereichen mit dedizierten Verbindungen unter Verwendung von Zweigen vorgenommen.
Sie können die MAIN-Version eines bestehenden Projekts in GitHub wiederverwenden. Erstellen Sie ein leeres Projekt mit demselben Namen wie das bestehende Projekt in GitHub. Dadurch wird die neueste verfügbare Version im MAIN-Zweig abgerufen, um mit dessen Bearbeitung zu beginnen.
Benutzer erstellen einen neuen Zweig, nehmen ihre Änderungen vor, erstellen Pull-Anforderungen, führen sie zusammen und übertragen sie per Pull zurück an MAIN/Produktion.
-
Entwicklung
Entwickler können ihre Änderungen in einem dedizierten Datenbereich isolieren, z. B. in DEV. Dedizierte Verbindungen werden dem DEV-Bereich zugewiesen.
Änderungen werden durch Zweige isoliert, normalerweise einen Zweig pro Entwickler. Verwenden Sie Schemapräfixe, wenn ein Zweig erstellt wird, um Datenbankkonflikte bei der Durchführung der Änderungen zu vermeiden.
-
Überprüfung / Qualitätsabnahme
Prüfer erhalten zu folgenden Zwecken Zugang zu Entwicklungsbereichen und Verbindungen:
-
Projektzweige in Qlik Talend Cloud öffnen und testen
-
Pull-Anforderungen genehmigen, um mit dem Zusammenführen in GitHub fortzufahren
-
Teammitglieder informieren, wenn genehmigte Änderungen per Pull zurück an MAIN/Produktion übertragen werden können
-
Wenn Sie die genehmigten Änderungen wieder im MAIN-/Produktionsbereich bereitstellen, müssen Sie die Verbindungen erneut den Verbindungen des Produktionsbereichs zuweisen.
Einschränkungen
-
Es ist nicht möglich, ein Projekt mit Versionskontrolle zu trennen oder zu löschen, wenn Zweige vorhanden sind. Die Zweige müssen gelöscht werden, bevor Sie das Projekt trennen oder löschen können.
-
Es ist nicht möglich, ein Projekt mit Versionskontrolle umzubenennen.
-
Wenn Sie einen Mandanten löschen, werden Objekte, die mit Versionskontrolle in GitHub gespeichert sind, nicht gelöscht. Sie müssen diese Objekte manuell löschen.
-
Wenn ein Repository von vielen Projekten verwendet wird oder viele Dateien enthält, die nicht in Qlik Talend Data Integration gespeichert sind, kann sich die Leistung verschlechtern.
-
Datenbankschemas und Verbindungen werden nicht in der Versionskontrolle gepflegt.
-
Persönliche GitHub-Zugriffstoken des Typs „fine-grained“ werden nicht unterstützt.
-
Ein Zweig (außer dem Hauptzweig) kann nur von einem Projekt pro Repository verwendet werden, auch wenn sich zwei Projekte im selben Repository befinden.
-
Es ist nicht möglich, Remoteänderungen aus einem Projekt zu übernehmen, das eine andere Zielplattform verwendet. Wenn Sie beispielsweise ein Commit für Änderungen an einem Projekt in Snowflake durchführen, können Sie diese Änderungen nicht für ein Databricks-Projekt übernehmen.