Git-Workflow: Wie füge ich Commits ein, die nur für einen neuen Zweig erstellt wurden

Question

Wir verwenden git, um Entwicklungs- und versionierte Releases zu verfolgen, und stießen auf einige Probleme beim Zusammenführen von Zweigen. Hier ist unser Workflow:

production/1.0.0 A--B 

stage/2.0.0  A--B--C--D 

development  E--F--G--J--L 
         \ 
feature     H--I--K 

Feature-Entwicklung geschieht auf einem Feature Zweig, der von der Entwicklung erstellt wurde und wenn Sie fertig sind verschmolzen ist für Demo- und Test zurück.

Das alles funktioniert gut, das Problem ist, wenn der Entwickler, der diesen Feature-Zweig erstellt hat, ihr Feature in einen Stage-Zweig für die Bereitstellung versetzt. Da sie bei G von der Entwicklung abgezweigt sind, wenn sie zusammengeführt werden, enthält sie EFG, wenn sie nur HIK zusammenführen wollen. Das Ziel mit unserem Git-Workflow ist es, dass Entwickler ihren eigenen Code für die Veröffentlichung markieren und koordinieren, dass der gesamte Entwicklungszweig in den Deployment-Zweig integriert werden kann, da die Entwicklung auf der ganzen Welt nicht möglich ist.

Gibt es einen Git-Befehl, um Commits, die in einem Feature-Zweig erstellt wurden, einfach zusammenzuführen? Ich kenne Rebase und Cherry Pick, aber eine Funktion kann aus einer großen Anzahl von Commits bestehen, bei denen Merge aus der Entwicklung ihren Feature-Zweig aufholt. Gibt es eine bessere Lösung?

Ist dieser Workflow korrekt? Versuchen wir etwas zu tun, das nicht nachhaltig ist?

Answer 1

Das wäre ein git rebase --onto gekoppelt mit git merge-base:

git checkout stage/2.0 
git rebase --onto stage/onto $(git merge-base development feature) feature 

, dass die Festschreibungen des feature Zweig wiedergeben würde nachG (das ist der „merge base“ zwischen Entwicklung und Funktion commit) auf die stage/2.0 branch .

Ergebnis:

stage/2.0.0  A--B--C--D 
          \     
feature      H'--I'--K' 

development  E--F--G--J--L 

Die alten H, I und K Commits sind noch in der reflog verwiesen (git reflog), aber haben Kirsche gepflückt und auf der stage/2.0 abgespielt.

Ist dieser Workflow korrekt? Versuchen wir etwas zu tun, das nicht nachhaltig ist?

Es ist mit folgender Einschränkung:
Es bedarf einer sorgfältigen Tests nach einer solchen Fütterungsmaterial einzubeziehen, weil H, I und K wo oben auf G getan, die überhaupt in der stage/2.0 Zweig nicht vorhanden ist .

Wenn diese Commits von Inhalt basierend auf G abhängig waren, wurde dieser anfängliche Inhalt nicht im Staging-Zweig gefunden. Einige Regressionstests sollten dies deutlich machen.

Mit git cherry-pick (die auch can replay multiple commits) würde diese Commits auf den Staging-Zweig duplizieren, so dass die feature Zweig wie (dh nicht auf dem Staging-Zweig indexiert).
Das scheint seltsam, wenn man bedenkt, dass Sie anfangen müssen, welche Commits ausgewählt wurden, und welche anderen neuen Commits wurden noch nicht ins Staging übernommen.

---

Was würde passieren, wenn die Entwicklung in Funktion zwischen I und K verschmolzen wurde? (Der Entwickler, der seinen Zweig cachiert)
Würde die Kirsche-Auswahl auch diesen zusammenführen und den ganzen Entwicklungszweigcode miteinbeziehen?

Ja, es würde den Merge-Commit enthalten, aber nicht den gesamten Zweig dev. In jedem Fall ist es nicht ideal. Die beste Vorgehensweise besteht nicht darin, dev zu feature zu verschmelzen, sondern eher feature über dev (git rebase dev) zu rebasieren. Dann
, wenn die Funktion fertig ist, rebase --onto stage/2.0

---

Was der rebase --onto Befehl tut, ist im Grunde den Funktionszweig auf stage/2.0.0 bewegen?

Ja.

Geht der Feature-Zweig verloren?

No: es wird neu erstellt von jedem neu Anwendung verpflichten Patch aufstage/2.0.0.
Die alten Commits des Feature-Zweiges vor dem rebase --onto gesehen sind immer noch da, aber unsichtbar, nur durch git reflog referenziert, wie oben erwähnt.

Der verschachtelte Befehl $(git merge-base development feature) Werden die Änderungen von Feature zu Entwicklung angewendet, bevor der Zweig in den Zweig stage/2.0.0 verschoben wird?

No: es ist ein Ausgang commit für diese Funktion Zweig zu berechnen, das heißt: die development begehen, von der feature Zweig gestartet wurde.
Wenn ich das nicht verwendet haben, sondern eine einfache git rebase, die Festschreibungen von feature Zweig umfassen würde alle zugänglich begeht von feature HEAD (und das würde auch die development Commits)