Gibt es eine Möglichkeit, Gerrit dazu zu zwingen, alle Commits in einem Branch zum Code-Review zu pushen?

Question

Gerrit wird möglicherweise nicht überprüfte Änderungen zusammenführen, die früher in der Commit-History liegen und sich in einem anderen 'Branch' des Repositories befinden. Hier ist ein Beispiel:

1. Überprüfe den gerrit branch devel
2. Erstelle file1.txt, füge hinzu, commite, schiebe nach refs/heads/temp_branch
3. Erstelle file2.txt, füge hinzu, commite, schiebe nach refs/for/devel zur Codeüberprüfung

Wenn file2.txt akzeptiert und zusammengeführt wird, wird auch file1.txt zusammengeführt, da es stromaufwärts ist und nicht in einem separaten Änderungs-Branch markiert ist, der sich unter Überprüfung befindet. Dies ist potenziell sehr problematisch und die einzige Lösung, die mir einfällt, ist, dass jeder Push zu jedem Branch zur Codeüberprüfung gezwungen wird. Dies ist nicht ideal, da Sie möglicherweise einige Branches mit einer Gruppe von Genehmigenden haben möchten oder ohne Codeüberprüfung (für einige Codeswaps?).

Die Lösung hier besteht darin, dass jeder Commit im Verlauf zur Codeüberprüfung platziert werden muss, wie es auch der Fall gewesen wäre, wenn file1.txt nicht in einem anderen Branch im selben Repository gepusht worden wäre.

Gibt es eine Einstellung in Gerrit, die diese Regel vorschreibt? Kann jemand an einen Workflow denken, der es ermöglicht, in refs/heads/ zu puschen, ohne andere Branches zu riskieren?

Vielen Dank.

Answer 1

Ich vermute, dass Sie dieses Verhalten sehen, weil der Commit in Schritt 3 den Commit von Schritt 2 als Elternteil hat. Sie können keinen Commit einreichen, solange nicht alle seine Eltern eingereicht wurden. Ich stimme Ihnen zu, dass dies wie ein Fehler in Gerrit aussieht - es sollte sich weigern, einzureichen, bis Schritt 2 eingereicht wurde.

Versuchen Sie diesen Workaround - fügen Sie Schritt 2a nach Schritt 2 hinzu:

2a. Überprüfen Sie erneut den Entwicklungs-Branch

Wenn die Commits in 2 verschiedene Branches gehen, ergibt es keinen Sinn, dass sie linear sind.

Noch eine Überlegung - welche Merge-Strategie verwenden Sie für dieses Projekt? Wenn es Cherry-Pick ist, würde ich versuchen, es auf Merge-if-needed zu ändern, oder wenn es nicht Cherry-Pick ist, würde ich versuchen, es auf Cherry-Pick zu ändern. Ich glaube, das Verhalten hier ist unterschiedlich zwischen den Merge-Strategien.