Team git flow mit Tests

Question

Wir haben einen Git Workflow geplant, von dem wir dachten, dass er gut funktionieren würde, aber Probleme haben.

In SourceTree Wir haben 4 Hauptzweige

1. _dev (von der wir feature-Zweigen zu erstellen, entspricht jede Funktionszweig auf eine JIRA Aufgabe)
2. _qa (zu dem Wir führen Feature-Zweige zusammen, sobald die Funktionen fertig sind und der Code auf _dev überprüft wird.
3. _Next-release (zu dem wir zusammenführen e der Funktionszweig, wenn eine Funktion durch QA zugelassen ist)
4. Master (auf die wir den gesamten _Next-release Zweig fusionieren, wenn der Sprint vorbei ist, wodurch nur die zugelassenen Funktionen) verschmelzenden

Wir haben auch Versionszweige zu denen wir den Master-Zweig zusammenführen, wenn eine Version veröffentlicht wird (wir tun dies um sicherzustellen, dass wir zu diesem Zweig zurückkehren und Anpassungen vornehmen können, wenn unser Produkt ein installierbares ist)

Our problematisches Szenario ist:

1. Dev1 schafft feature1 (Niederlassung von _dev)
2. Dev1 geht feature1 _dev (sagen wir es an dieser Stelle für die Code-Review wartet)
3. Dev1 erstellt und startet Arbeit an feature2 (Niederlassung von _dev wieder)
4. Dev1 führt feature2 in _dev zusammen und übergibt Code-Überprüfung.
5. Dev1 versucht feature2 zu fusionieren

Ergebnis _qa: beide feature1 und feature2 scheinen in QA zu fusionieren, obwohl feature1 noch nicht bereit ist.

Wir fusionieren nach rechts, um den Zweig klicken und „merge featureX in Stromzweig“

Kommissionierung Bitte beachten Sie, wir haben 4-Umgebungen, die (sollten), um jeden Zweig reflektieren, so QA einen Platz haben, Funktionen zu überprüfen.

Warum sind Features, die mit Features zusammengeführt werden, die wir nicht zusammenführen möchten?

Was ist der gemeinsame Workflow, der nur validierte Funktionen in einer Version Fusion ermöglicht es, während QA eine Umgebung, so dass Funktionen zu überprüfen und für eine saubere Geschichte zu ermöglichen, dass jedes Merkmal des Lebenszyklus widerspiegeln - dev -> QA -> Mitteilung - > Version

Dank

Answer 1

Zuerst ein Wort der Vorsicht: Wenn Sie mit diesem Workflow-Stick, und Ihre aktuellen Probleme lösen, werden Sie andere, subtilere Fragen zu stellen.Workflows wie diese, die versuchen, zu Zusammenführungen einzelner Feature-Zweige in mehreren Phasen des Entwicklungslebenszyklus zurückzukehren, geraten in Schwierigkeiten, da sie die möglichen Interaktionen zwischen Änderungen in verschiedenen Zweigen ignorieren.

Mit dem gesagt, lassen Sie uns auf einige Ihrer Fragen konzentrieren. Ihr Szenario (mit Illustrationen) sieht so aus:

Zunächst einmal haben Sie _dev und _qa Filialen. (Die anderen, werden wir für den Moment beiseite gesetzt, der Einfachheit halber.)

A -- B -- C <--(_dev)(_qa) 

Ich gehe davon aus, dass wir in einem Zustand beginnen, wo alles in _dev passiert hat _qa (und alles natürlich, dass _qa bestanden hat sollte in _dev sein), so dass sie auf den gleichen Commit zeigen. Dies kann einige komplizierende Faktoren auslassen, die Ihren Arbeitsablauf behindern würden, aber es gibt uns immer noch genug, um das Problem zu verstehen, mit dem Sie derzeit konfrontiert sind. Jetzt

Dev1 schafft feature1

A -- B -- C <--(_dev)(_qa) 
      \ 
      D -- E <--(feature1) 

Dev1 geht feature1 _dev (sagen wir es an dieser Stelle für die Code-Review wartet)

 (_qa) 
      | 
A -- B -- C ------ M1<--(_dev) 
      \ /
      D -- E <--(feature1) 

Dev1 erstellt und beginnt mit der Arbeit an Feature2

 (_qa)   F -- G <--(feature2) 
      |  /
A -- B -- C ------ M1<--(_dev) 
      \ /
      D -- E <--(feature1) 

Dev1 geht feature2 in _dev und Code-Review durchläuft.

 (_qa)   F -- G <--(feature2) 
      |  / \ 
A -- B -- C ------ M1 ------ M2 <--(_dev) 
      \ /
      D -- E <--(feature1) 

Dev1 versucht feature2

Ok _qa zu verschmelzen, so was passiert hier? Nun, feature2 ist ein Nachkomme von _qa (seit wir mit _qa und _dev an der gleichen Stelle begonnen haben). Sie könnten also _qa auf feature2 vorspulen (und selbst wenn Sie dies nicht tun, wird der resultierende Zusammenführungs-Commit den gleichen Inhalt haben, als hätten Sie). Aber feature2 wurde bei M1 verwurzelt; Die Änderungen von feature1 sind erreichbar vonfeature2 aber nicht erreichbar von_qa, so dass die Zusammenführung sie enthalten würde.

Wenn wir damit begonnen hätten, dass _qa von _dev erreichbar ist (anstatt dass die beiden auf denselben Commit zeigen), würde genau die gleiche Analyse gelten. Wenn aus irgendeinem Grund, _qa Änderungen enthalten nicht erreichbar Form _dev wir so etwas wie

 Q <--(_qa)  F -- G <--(feature2) 
    /   / \ 
A -- B -- C ------ M1 ------ M2 <--(_dev) 
      \ /
      D -- E <--(feature1) 

In diesem Fall haben könnte, würde git einen Merge-Basis zwischen _qa finden und feature2 - das heißt einem gemeinsamen Vorfahren.Das wäre B. Es wäre dann kombinieren „Änderungen zwischen B und _qa“ mit „Änderungen zwischen B und feature2. Auch hier sind die Veränderungen zwischen B und feature2die Änderungen enthalten, die von feature1 gemacht wurde, weil feature2 bei M1 (dh einen Punkt verwurzelt war nach feature1 war In allen Fällen ist der Punkt derselbe: In den meisten Fällen (einschließlich während einer Zusammenführung), sieht git Commits (oder Deltas zwischen ihnen) nicht als "Zugehörig zu" dieser Verzweigung oder dieser Verzweigung Stattdessen ist es wichtig, ob eine Änderung auf dem Pfad zur Zusammenführungsbasis ist.

Eine Situation, in der Git kann in der Regel gemacht werden, um die Änderungen "von einem Zweig" isoliert betrachten würde eine rebase sein. Ihr Workflow müsste jedoch gründlich überarbeitet werden, um andere Vorteile zu erzielen. Es ist nicht der Weg, den ich hier empfehlen würde.

Eine andere Möglichkeit, Ihren Workflow zu verbessern, wäre, Entwickler dazu zu zwingen, neue Feature-Zweige auf der Zusammenführungsbasis zwischen _dev und _qa zu starten. ABER Dies kann nur die Dose die Straße hinunter kicken (es sei denn, Änderungen werden immer "in Ordnung" bleiben, sobald sie _qa erreichen, was keine vernünftige Annahme ist - insbesondere wenn QA jemals Mängel entdeckt). Außerdem erhöht dies die Isolation zwischen der Arbeit für ein Feature und dem nächsten Feature, was letztlich bedeutet, dass Sie wahrscheinlich mehr Zusammenführungskonflikte haben werden.

Wie auch immer, ich denke, das spricht Ihre warum Frage. Wie für die was:

Nun, während Sie „git flow“ als Oberbegriff für „eine Branching und Merging-Strategie“, tatsächlich git Flow verwendet habe, ist der Name eines spezifischen Verzweigen und Zusammenführen Strategie . Ich schlage vor, es zu lesen. Die Anforderungen, die Sie beschrieben haben, sind nicht einzigartig oder sogar ungewöhnlich. Anstatt zu denken, dass Sie diesen Fluss anpassen müssen, um diese Bedürfnisse zu erfüllen, sehen Sie, wie Menschen diese Bedürfnisse mithilfe dieses Flusses erfüllen.