it-swarm.com.de

Ist es eine gute Praxis, Zweige zu verwenden, um verschiedene Editionen derselben Software zu verwalten?

Wir haben ein Produkt, das einige verschiedene Editionen hat. Die Unterschiede sind gering: verschiedene Zeichenfolgen hier und da, sehr wenig zusätzliche Logik in der einen, sehr wenig Unterschied in der Logik in der anderen. Bei der Entwicklung der Software müssen die meisten Änderungen zu jeder Edition hinzugefügt werden. Es gibt jedoch einige, die dies nicht tun, und einige, die sich unterscheiden müssen. Ist es eine gültige Verwendung von Zweigen, wenn ich Zweige der Versionen release-editionA und release-editionB (..etc) habe? Gibt es Fallstricke? Gute Praktiken?

Update: Vielen Dank für den Einblick an alle, viele gute Antworten hier. Der allgemeine Konsens scheint zu sein, dass es eine schlechte Idee ist, Zweige für diesen Zweck zu verwenden. Für alle, die sich fragen, besteht meine endgültige Lösung für das Problem darin, Zeichenfolgen als Konfiguration zu externalisieren und die unterschiedliche Logik als Plugins oder Skripte zu externalisieren.

75
Tamás Szelei

Dies hängt vom Ausmaß der Änderung ab, aber ich würde es für die von Ihnen beschriebenen Unterschiede nicht als bewährte Methode betrachten.

Im Allgemeinen möchten Sie, dass ein Git-Zweig in Zukunft zusammengeführt oder schreibgeschützt als Referenz gespeichert wird. Git-Zweige, die auf unbestimmte Zeit nebeneinander existieren, bedeuten Arbeit für alle: Änderungen müssen weitergegeben und zusammengeführt, Konflikte gelöst werden, der ganze Spaß. Wenn nichts anderes, muss jeder Entwickler daran denken, Änderungen in fünf Repositorys anstatt in eines zu übertragen.

Wenn Sie kleine Änderungen vornehmen, scheint der gesamte Aufwand für das Zusammenführen und Verwalten von Zweigen im Vergleich zum Problem übertrieben. Verwenden Sie Ihren Präprozessor oder Ihr Build-System, um zwischen Versionen zu unterscheiden. Tut ein einfaches #ifdef Mache den Trick? Dann löse keine Probleme mit Git, es ist übertrieben.

47
thiton

Dafür sind Zweige nicht wirklich da. Zweige sollten kurz- bis mittelfristige Nebenpfade zu Ihrer Entwicklungslinie sein, keine langfristigen parallelen Versionen desselben Codes.

Ich würde alle verschiedenen Versionen in denselben Zweig mit Unterverzeichnissen für die Teile einfügen, die sich zwischen den Editionen unterscheiden, und Ihren Build-Prozess einrichten (Sie haben einen automatisierten Build, oder?), Damit jede Edition bei Bedarf ausgegeben werden kann (oder alle auf einmal).

Schließlich möchten Sie eine "einzige Quelle der Wahrheit" behalten; Bei Zweigen duplizieren Sie Code, aber nicht alle, und bestimmte Zusammenführungen würden Ihr Setup tatsächlich beschädigen.

17
tdammers

Eine Lösung besteht - wie bereits erwähnt - darin, das Build-System so zu konfigurieren, dass verschiedene Editionen unterstützt werden.

Ich würde auch in Betracht ziehen, es als Feature-Umschalter zu implementieren und eine Konfigurationsdatei zu verwenden. Je weniger Sie bauen müssen, desto besser.

Schauen Sie sich diese Seite an.

12
Magnus

Ich würde denken, dass dies eine gute Idee ist, vorausgesetzt, Sie können dies nicht innerhalb eines Zweigs tun, ohne den Code zu stark zu gruppieren.
Ich würde es vorziehen, es in einem Zweig zu behalten und lokalisierte und Konfigurationsdateien zu verwenden, insbesondere wenn Sie sagen, dass die Unterschiede gering sind.
Ein anderer Weg könnten verschiedene Builds sein, zum Beispiel packt Ihre Build-Datei verschiedene Dateien für verschiedene Kunden, aber ich kann auch sehen, wie das Build-Tool verschiedene Zweige überprüft. Wenn Sie Git verwenden, würde ich sagen, keine echten Fallstricke. Eine Verzweigungsstrategie könnte darin bestehen, für verschiedene Aufgaben verschiedene Zweige zu entwickeln, in den Hauptzweig einzuchecken und von Master zu EditionX und Y zusammenzuführen.

3
Farmor

Dies klingt eher nach einem Job für verschiedene Build-Konfigurationen. Thitons Antwort geht in diese Richtung, aber ich würde es viel weiter bringen als #ifdef:

Verwenden Sie verschiedene Build-Ziele, um verschiedene Editionen der Software zu erstellen. Ziele können sich unterscheiden durch

  • die Konfiguration, die sie enthalten,
  • die darin enthaltenen Objekt- oder Quelldateien oder
  • die Vorverarbeitung des Quellcodes.

Diese Vorverarbeitung kann natürlich den klassischen C-Präprozessor umfassen, kann aber auch die Verwendung eines benutzerdefinierten Präprozessors, einer Vorlagen-Engine zum Erstellen benutzerdefinierter Ansichten, usw. beinhalten.

Auf diese Weise müssen Sie nicht jede einzelne Änderung aktiv auf mehrere Zweige übertragen, was gegen DRY) verstößt (natürlich kann auch dies automatisiert werden, aber ich sehe keinen Vorteil).

2
Konrad Rudolph

Ich würde Zweige nur für wesentliche Änderungen verwenden, andernfalls fügen Sie am Ende jede kleine Änderung zu zahlreichen Zweigen hinzu, was überhaupt keinen Spaß macht und sehr fehleranfällig ist, insbesondere wenn Sie mit mehr Personen arbeiten.

1
John

Wenn Sie sie alle als unterschiedliche Produkte veröffentlichen, wird empfohlen, mehrere Niederlassungen zu haben. Wenn nicht, wird immer noch empfohlen, so etwas wie einen Trunk oder einen Master-Zweig zu verwenden.

Ich denke auch, dass dies von Ihrem Entwicklungsprozess abhängen würde, insbesondere von der Bereitstellung. Wenn Sie einen Prozess haben, bei dem nur ein Zweig in die Produktion eingeführt werden kann und Zweige als "inkrementelle Builds" behandelt werden, bedeutet dies, dass Release B nur dann in die Produktion eingeführt werden kann, wenn Release A zuerst eingeführt wurde, da alle Änderungen von A sind bereits in B, dann ist es der richtige Weg, mehrere Zweige zu haben. Dies funktioniert, wenn Sie Teams auf der ganzen Welt haben und Änderungen normalerweise nach Priorität geordnet sind.

1
setzamora