Sollte ich vor einer Pull-Anfrage mit dev branch rebasen?

Lesezeit: 2 Minuten

Unser aktueller Arbeitsablauf:

Erstellen Sie einen Feature-Branch von dev. Nachdem Sie das Feature entwickelt und den Zweig gepusht haben, gehen Sie wie folgt vor:

git checkout dev

git pull --rebase (auf Entwickler)

git checkout my-feature-branch

git rebase dev

Konflikte lösen und dann git push -f oder git push (beim ersten Mal) ausführen.

Meine Frage kommt von einem Mitglied unseres Entwicklungsteams:

Müssen wir den gesamten Prozess so durchführen, wie er ist, oder können wir die Pull-Anfrage einfach direkt stellen, insbesondere, dass die Antwort immer lautet: „Ich arbeite an einer Komponente, die von keinem anderen Entwickler geteilt wird“?

Danke im Voraus

  • Dies ist eine Workflow-Frage: und der beste Workflow wird immer meinungsbasiert sein. Sie alle haben Kompromisse. Tun Sie, wofür Sie sich als Team entscheiden, und bleiben Sie dabei. Verstehe die Vor- und Nachteile dessen, was du tust. Alle Arbeitsabläufe haben ihre Höhen und Tiefen.

    – Matt Messersmith

    18. Juli 2018 um 14:05 Uhr

Benutzer-Avatar
sergej

Nehmen wir an, während Sie an Ihrem arbeiten feature-branchneue Sachen werden in die integriert dev Zweig. Die Historie könnte also so aussehen:

1 - 2 - 3 - 5 (dev)
    \
     4 - 6 - 7 - 8 (feature-branch)

Wenn Sie einfach einen Pull-Request erstellen und die dev Zweigbetreuer müssten es zusammenführen, er müsste sich mit potenziellen Konflikten befassen – schlecht für die dev Filialbetreuer.

Wenn Sie die rebase feature-branch abzweigen dev und potenzielle Konflikte lösen, bevor der Pull-Request gesendet wird,

1 - 2 - 3 - 5 (dev)
             \
              4 - 6 - 7 - 8 (feature-branch)

es wird nur eine schnelle und einfache Fast-Forward-Merge für die sein dev Filialbetreuer.

Dieser Workflow zwingt Entwickler dazu, Konflikte lokal zu lösen und erleichtert dem Integrator das Leben.

  • Perfekte Antwort, danke, genau das, wonach ich gesucht habe. Danke euch allen.

    – OD

    19. Juli 2018 um 9:34 Uhr

  • würde Push erzwingen, wenn angenommen wird, dass Commit 7 bereits auf dem Remote-Zweig vorhanden ist (bis 7 Rebase nicht durchgeführt wurde oder dev nicht mit 3 & 4 festgeschrieben wurde)?

    – Jusuf

    30. Mai 2021 um 17:59 Uhr

Ihr Workflow ist nur der typische Rebase-Workflow, von dem ich erwarten würde, dass er verwendet wird, um einen Feature-Zweig direkt vor seinem Vorfahren zu halten, was in diesem Fall der ist dev Zweig. Wenn Sie die Möglichkeit offen lassen möchten my-feature-branch Vorspulen der dev Verzweigung während der Pull-Anforderung, dann müssen Sie all diese Schritte ausführen. Beachten Sie, dass der Force-Push möglicherweise erforderlich ist, da die Rebase aktiviert ist dev kann die Historie des Feature-Branch umschreiben.

Ob Sie einen Rebase-Workflow oder einen Merge- oder anderen Workflow durchführen sollten, ist subjektiv und hängt von vielen Dingen ab. Aber wenn eine Umbasierung am sinnvollsten ist, stimme ich Ihren aktuellen Schritten zu und sehe keine Möglichkeit, sie zu vereinfachen.

1131170cookie-checkSollte ich vor einer Pull-Anfrage mit dev branch rebasen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy