Wir verwenden Git Flow in unserem neuesten iOS-Projekt und ich versuche, eine Methode für die Arbeit mit QA zu finden, mit der sie die neueste Version sowie eine neue Funktion testen können, ohne sich Gedanken darüber machen zu müssen, welche Fehler behoben wurden welche Niederlassung.

Gegenwärtig haben sie auf dem getestetrelease/v1.0.1 Zweig, der mehrere Fehler aus dem Original behoben hatrelease/v1.0. Gleichzeitig habe ich an einer neuen Funktion gearbeitet, die für die Version 1.1 geplant ist, aber von der Version 1.1 abgezweigt wurdedevelop Niederlassung zur gleichen Zeit wierelease/v1.0.1 und hat daher keine der Bugfixes drin.

Heute möchte die QA-Abteilung meine neue Funktion für eine Probefahrt nutzen. Wenn ich ihnen jedoch einen Build aus meiner Filiale erstelle, ist keine der von ihnen erneut getesteten und geschlossenen Fehlerbehebungen vorhanden. Ich werde daher eine Flut von Beschwerden und Paniken über wieder eingeführte Bugs erhalten ... Was ich vermeiden möchte!

Also, was ist der beste Weg, um sie dazu zu bringen, dies zu testen? Ich könnte fusionierenrelease/v1.0.1 in meinem Feature-Zweig, aber dann sollte ich sicherstellen, dass ich nicht wieder in verschmelzendevelop Vorrelease/v1.0.1 wurde veröffentlicht ... Und ich denke, bis zu einem gewissen Grad bricht dies die Git Flow-Methodik. Ich könnte eine völlig neue Verzweigung nur für QS-Tests erstellen, mit der meine Funktion zusammengeführt wirdrelease/v1.0.1, aber was mache ich dann mit Fehlern, die sie in diesem Zweig finden? Wo füge ich es nach der QS-Runde wieder zusammen?

Darüber hinaus muss ich die Build-Nummern und Versionsnummern berücksichtigen, damit sie sinnvoll sind. Derzeit werden die Versionsnummern für die Veröffentlichung verwendet, und die Build-Nummern werden mit jedem neuen Build für QA erhöht. Wenn sie jedoch Builds von zwei verschiedenen Zweigen erhalten, kann es zu Zusammenstößen der Build-Nummern kommen, die Verwirrung stiften.

Was wäre der beste Weg, um mit diesen Problemen umzugehen?