Konflikte beheben

Dieses Kapitel beschreibt die Behandlung von Konflikten, die während der verteilten Entwicklung im Zusammenspiel zwischen FirstSpirit, External Synchronization und einem Versionskontrollsystem auftreten können. Die Szenarien betreffen in erster Linie die Synchronisierung von Projektinhalten und Änderungen an diesen durch mehrere Entwickler, wobei die Projektinhalte über ein Git-Repository zwischen den Arbeitsstationen der Entwickler synchronisiert werden.

Die meisten Konflikte im Umfeld von Versionskontrollsystemen können vermieden werden, wenn ein Entwickler unmittelbar vor Beginn der Arbeit an einem Arbeitspaket sein lokales Repository auf den neuesten Stand aktualisiert und die in diesem Stand vorhandenen Projektdaten in seine lokale FirstSpirit-Projektinstanz importiert, nach Abschluss der Arbeit an einem Arbeitspaket die Projektdaten aus seiner FirstSpirit-Projektinstanz exportiert und unmittelbar in das Git-Repository überführt. Trotz dieser Konvention können sich weiterhin Konfliktfälle herausstellen, die durch zeitgleiche Arbeit durch mehrere Entwickler entstehen. Dieses Kapitel befasst sich mit solchen Fällen.

Konventionen

Die vorgestellten Szenarien sind explizit auf das Modell der verteilten Entwicklung ausgelegt.

• Zwei Entwickler: Entwickler A und Entwickler B
• Jeder Entwickler benutzt eine eigene Workstation mit einem lokalen FirstSpirit-Server.
• Die FirstSpirit-Projektdaten, an denen die Entwickler arbeiten, werden auf jedem lokalen FirstSpirit-Server in einem Projekt „DevProject“ gepflegt.
• Die Daten des FirstSpirit-Projekts „DevProject“ werden über ein Git-Repository versioniert und zwischen den Arbeitsstationen von Entwickler A und Entwickler B synchronisiert. Dieses Repository enthält aber im Ausgangszustand noch keine Daten.
• Das Git-Repository existiert bereits und ist unter der URL ssh://firstspirit.example/externalsync erreichbar.
• Das Git-Repository wird auf jeder Workstation im Verzeichnis D:\Git\DevProject geklont.

Die Szenarien verwenden das Kommandozeilenwerkzeug FSDevTools (fs-cli) sowie den kommandozeilenbasierten Git-Client (git). Aufrufe dieser Werkzeuge sind zur besseren Lesbarkeit der Szenarien simplifiziert und entsprechen nicht unbedingt den Best Practices, die in dieser Dokumentation dargestellt werden. Bei Verwendung anderer Werkzeuge zur Nutzung von External Synchronization und/oder zur Versionierung der Projektdaten können Unterschiede im Arbeitsverlauf entstehen, und mitunter können einige Konfliktbehandlungsszenarien andere Arbeitsschritte erfordern.

Szenarien

Gleichzeitige Änderung an einer Vorlage

• Unterschiedliche Bereiche (Disjunktion)
  Die gleichzeitige Arbeit an einer Vorlage durch zwei Entwickler führt zu Änderungen an unterschiedlichen Stellen z. B. einer Ausgabekanaldefinition.
• Überlappende Bereiche (Konjunktion)
  Die gleichzeitige Arbeit an einer Vorlage durch zwei Entwickler führt zu Änderungen an derselben Stelle z. B. einer Ausgabekanaldefinition.
• Identische Änderungen
  Die gleichzeitige Arbeit an einer Vorlage durch zwei Entwickler führt zu einer identischen Veränderung der Vorlage auf beiden Arbeitsstationen.

Namensraumkonflikte

Diese Szenarien behandeln Konfliktfälle, die durch die Anforderungen von Namensräumen im FirstSpirit-Projekt entstehen können, die Git aber unbekannt sind. Insbesondere wird hier der Umgang mit der eindeutigen Benennung (UID) von FirstSpirit-Elementen innerhalb eines Namensraums in unterschiedlichen Szenarien der verteilten Entwicklung illustriert.

• Gleicher Vorlagentyp, gleiche UID, unterschiedliche Inhalte
  Die lokale Erstellung von Vorlagen gleichen Typs mit gleicher UID (eindeutiger Identifier) führt bei der verteilten Entwicklung zu einem Konflikt.
• Unterschiedliche Elemente mit gleicher UID (z. B. Inhalte-Verwaltung)
  Die lokale Erstellung von Elementen unterschiedlichen Typs mit gleicher UID in einem Namensraum (hier am Beispiel der Inhalte-Verwaltung) führt zu einem Konflikt.