In meiner Firma haben wir einen CI / Build-Server, mit dem wir Releases (sowie Features und den Entwicklungszweig) testen und erstellen. In demGit Flow Verzweigungsmodell, wenn es Zeit ist, Sie zu veröffentlichen. Der CI / Build-Server erstellt dann automatisch den Zweig und stellt ihn für manuelle Integrationstests auf einem Staging-Server bereit. Sobald wir mit dem Build zufrieden sind, möchten wir es bereitstellen. Aber im Git-Flow-Verzweigungsmodell müssen wir zuerst zusammenführen, um zu meistern und zu markieren. Die Frage ist, müssen wir nach dieser Zusammenführung einen weiteren Build- und Testzyklus ausführen, oder was?

Es erscheint seltsam, zusammenzuführen und mit Tags zu versehen, die auf ein anderes (technisch) Commit verweisen als das Release, aus dem sie erstellt wurden. Es scheint auch schlecht zu sein, nach dem Einstieg in den Master neu zu erstellen, da wir uns dann gezwungen fühlen würden, diesen Build zu testen, um sicherzustellen, dass er auch in Ordnung ist.

Die Optionen, die ich mir ausgedacht habe, sind:

Erstellen Sie den Release-Zweig, führen Sie ihn zusammen, erstellen Sie ihn neu und testen Sie ihn im Master-ZweigErstellen und testen Sie in der Release-Verzweigung und vertrauen Sie darauf, dass kein neuer Build erforderlich istÄndern Sie das Git-Flow-Modell, um den Schritt des Zusammenführens zum Master zu entfernen und markieren Sie einfach das endgültige Commit im Release-Zweig, den Sie freigeben möchten.Was würde verloren gehen, wenn man nicht zum Meister verschmilzt?In diesem Fall könnten wir uns wahrscheinlich nur im Meister entwickeln