Git-Strategie für die Bereitstellung von White Label-Instanzen in verschiedenen Subdomains.

Question

Ich habe eine Situation, wo welche Git-Strategie geeignet ist zu verwenden?

Situation:

Wir haben eine Anwendung, die ein Git-Repository hat. In dem folgen wir der Verzweigungsstrategie

1. Branche: entwickeln: von allen Entwicklern verwendet, um die Funktionen

2. Branche zu implementieren: Prüfung: wo der bis Strom entwickelte Code Test eingesetzt wird die Anwendung.

3. Branche: Produktion: Nach der Genehmigung von Testteam verschmelzen wir testen Zweig Produktion & es zu Produktionsumgebung bereitstellen.

Problem:

1. Jetzt haben wir 3 verschiedene Installationen der Produktion (site1.mainDomain.com, site2.mainDomain.com, site3.mainDomain.com), diese 3 Installationen haben vorerst unterschiedliche Header (Logo, Header-Farbe).

2. Es kann die Möglichkeit geben, dass site1.mainDomain.com einige Funktionen hat, die in Zukunft entwickelt werden können & kann nur für site1.mainDomain.com verwendet werden.

3. Einige zukünftige Features können für site1.mainDomain.com, site2.mainDomain.com, aber nicht für site3.mainDomain.com gemeinsam sein.

4. Jetzt, wenn es ein Problem auf der Produktion von site1.mainDomain.com & gibt, das ist das Hauptproblem von der Basisbranche, wie wir dieses Ding handhaben werden.

Also um dies zu erreichen, welche Git-Strategie ist sinnvoll? Ich las über Sub-Module, git Sub-Baum, Git-Patches .. aber etwas verwirrt, um die Entscheidung zu treffen. Bitte schlagen Sie die bestmögliche Lösung und Strategie vor.

Vielen Dank im Voraus. Vijay

Answer 1

Ich empfehle dringend, Git nicht zu verwenden, um das Problem zu lösen.Ich kann es aus Erfahrung sagen, denn das Projekt, an dem ich arbeite, fiel in die Falle, dass ich zwei Git-Zweige ohne guten Grund unterhalten musste. Github Firewall Install (Github: FI, Vorgänger von Github Enterprise) hatte ebenfalls das gleiche Problem.

Ich schlage vor, ein Feature Flag (Feature Toggle) Muster zu sehen, um Ihr Problem zu lösen - http://martinfowler.com/bliki/FeatureToggle.html

Answer 2

Ich denke, Sie suchen sich den falschen Ort (Versionskontrollsystem) zur Lösung dieses Problems. In dieser Situation würde ich normalerweise verschiedene Einstellungsdateien für verschiedene Kontexte erstellen, alle im selben Git-Zweig behalten und nur eine kleine lokale Konfigurationsdatei für jede Implementierung haben (meistens den richtigen Kontext wählen). Dann kann Ihr Code basierend auf dem Kontext prüfen, welche Art von Inhalt angezeigt werden soll.

Ich würde dringend empfehlen, verschiedene Feature-Zweige für jede Website zu machen, denn das wird Sie in ein unordentliches Durcheinander und einen konstanten Zusammenführungskonflikt bringen, der wirklich schnell auflöst.