Wir versuchen dem @ zu folg gitflow Verzweigungsmodell, aber mit einer Wendung.

ir haben vier Serverumgebungen, in denen das Produkt bereitgestellt werden kann. Jeder Server dient einem bestimmten Zweck: Entwicklung, interne Tests, externe Tests und Produktio

DevServer, wo Entwickler ihre verschiedenen Funktionen während der Entwicklung testen. Entwickler können nicht lokal auf ihren Computern testen, sondern müssen ihre Änderungen auf dem DevServer vornehmen, um @ testen zu könne TestServer, wo QA-Tester mehrere Funktionen testen, sobald die Entwickler fertig sind ReleaseServer, wobei Releases isoliert getestet werden, bevor sie in die Produktion verschoben werden. ProductionServer. Der Produktionsserver

Wir versuchen, die Lösung von Zusammenführungen / Konflikten so einfach wie möglich zu gestalten. Deshalb haben wir zwei zusätzliche Zweige erstellt, die nicht Teil des Gitflow-Modells sind.

Normal gitflow branches

sich entwickelMeiste (entspricht 'ProductionServer') featureXXX releaseXXX (wöchentliche Releases werden auf 'ReleaseServer' bereitgestellt)

Aber auch diese beiden Zweige, die nicht zum Standard gehören und möglicherweise geändert werden müssen ...

dev-release (Kopie von DevServer) test-release (Kopie von TestServer)

Dann läuft der Vorgang wie folgt ab:

developer erstellen ihre 'featureXXX' aus 'develop'multiple Entwickler führen ihre verschiedenen 'Features' in der 'dev-release'-Verzweigung zusammen, und die' dev-release'-Verzweigung wird auf dem 'DevServer' veröffentlicht, auf dem alle Entwickler ihre verschiedenen Features testen können. Nicht alle diese Funktionen werden in derselben nächsten Version enthalten sein.Nachdem die Entwickler mit den oben genannten Entwicklertests zufrieden sind, führen sie ihre 'featureXXX' in der Zweigstelle 'test-release' zusammen und diese wird auf 'TestServer' bereitgestellt. Nicht alle hier aufgeführten Funktionen sind Teil derselben nächsten Version.enn ein Test auf 'TestServer' für featureXXX durchgeführt wird, kann der Entwickler sein featureXXX in 'develop' schließen.Developer erstellt dann entweder ein neues 'releaseXXX' oder führt sein 'featureXXX' in ein vorhandenes 'releaseXXX' zusammen.Der Zweig 'releaseXXX' wird auf 'ReleaseServer' implementiert und getestet.Once 'releaseXXX' Test wird abgemeldet, 'releaseXXX' wird in Develop and Master zusammengeführt und auf 'ProductionServer' bereitgestellt

Versauen wir das ganze Gitflow-Modell?

Hier ist unser Brancing-Prozess: