Wenn ich Git verwende, sollte ich vor dem Zusammenführen ein Rebase durchführen?

Ich arbeite an einem großen Rails-Projekt und das Team, mit dem ich zusammenarbeite, verwendet Github, um das Projekt zu verwalten. Während an vielen Änderungen lokal gearbeitet und dann direkt in unseren Entwicklungsbranch gepusht wird, erstellen wir einen Branch, wenn wir an einer sehr großen Änderung arbeiten. Wenn es an der Zeit ist, diesen Branch wieder in denDevelopment-Zweig zusammenzuführen, versuche ich oft, den Development-Zweig zurück in meinenFeature-Branch zu rebasen, bevor ich meinen Feature-Branch in denDevelopment-Zweig zusammenführe (um zu verhindern,dass die Arbeit anderer Leute überschrieben wird). Ich finde, wenn ich das tue, scheine ich zweimal auf die gleichen Merge-Konflikte zu stoßen. Beim Rebasing stoße ich auf eine ganze Liste von Konflikten, und beim Zusammenführen stoße ich erneut auf dieselbe Liste von Konflikten. Sollte ich development in meinen Feature-Branch rebasen, bevor ich mein Feature in development merge, oder sollte ich mein Feature einfach in Develop mergen?

Nehmen wir an, mein Feature-Zweig heißt “new_feature”. Mein Prozess zum Zusammenführen mit dem „develop“-Zweig sieht folgendermaßen aus:

git checkout develop 

git pull (this is set up on our rig to always pull rebase)

git checkout new_feature 

git rebase develop 

(lots of merge conflicts ensue) 

git checkout develop  

git merge -no-ff new_feature 

(same set of merge conflicts again)

Es ist, als ob die Zeitachsenänderungen von meiner Rebase dazu führen, dass sich mein neuer Feature-Zweig den ganzen Weg zurück spiegelt und dann Konflikte mit einer Psudo-Kopie von sich selbst entwickelt.

OK, das ist jetzt zu lang für einen Kommentar.

Um das Handbuch zu paraphrasieren (git help rebase)

   Assume the following history exists and the current branch is "new_feature":

                 A---B---C new_feature
                /
           D---E---F---G develop


   From this point, the result of either of the following commands:

       git rebase develop
       git rebase develop new_feature

   would be:

                         A'--B'--C' <new_feature
                        /
           D---E---F---G <develop

Nun, wenn Sie Konflikte hatten, der Ist-Zustand nach dem ersten Ausführen rebase wird sein

              A'--B'--C'--[local state]
             /        ^
D---E---F---G          new_feature
            ^ develop

wo [local state] ist die widersprüchliche Zusammenführung, die Sie noch beheben müssen. Nachdem Sie die Zusammenführungskonflikte gelöst und die gelösten Dateien zum Index hinzugefügt haben, führen Sie sie aus git rebase --continue: jetzt wird Ihr Zustand sein

              A'--B'--C'--H <new_feature
             /
D---E---F---G <develop

Offensichtlich kann an dieser Stelle das Zusammenführen von new_feature wieder mit dem Entwickeln wie folgt vorgespult werden:

              A'--B'--C'--H <new_feature  <develop
             /
D---E---F---G

aber wenn nicht, bekommst du stattdessen dies

              A'--B'--C'--H <new_feature
             /             \
D---E---F---G---------------I <develop

Was auch immer Sie aus Sicht der Zeitleiste bevorzugen, es ist nicht offensichtlich, warum beide ein Problem haben würden … es sei denn, Sie haben die Rebase nie abgeschlossen und die Konflikte damit gelöst Haber ich würde denken, Git würde sich darüber beschweren.

Klingt für mich so, als würden Sie Rebase rückwärts verwenden, aber es könnte nur eine verwirrende Formulierung sein.

Ich würde den Feature-Zweig rebasen auf zu entwickeln und dann (beim Entwickeln) a ausführen git merge --ff-only feature.

Da Sie in derselben Frage “groß angelegt” und “rebasieren” angeben, würde ich Ihnen raten, dies nicht zu tun. Verwenden Sie stattdessen Zusammenführungen.

Die Verwendung von –no-ff in Zusammenführungen ist großartig, um den ursprünglichen Verzweigungspunkt beizubehalten. Ich unterstütze die Verwendung.

1. Rebasen Sie Ihren Feature-Branch, führen Sie ihn zusammen, fertig. Dass “den Feature-Zweig vor dem Zusammenführen umbasieren” ist meiner Meinung nach eine bewährte Methode.

2. Niemals die Entwicklung umbasieren, niemals den Verlauf eines Trunks ändern (es sei denn, Sie und Ihr Team wissen, was Sie tun).

3. Rebase ist nur eine Reihe von Cherry-Picks, beginnend am Anfang des Zweigs. Wenn Sie „Develop“ auf „Feature Branch“ umbasen, legen Sie tatsächlich alle Entwicklungs-Commits oben auf den Feature-Branch, was keinen Sinn ergibt.

4. Wenn Sie Ihre Arbeit nach dem Zusammenführen des Feature-Zweigs fortsetzen, starten Sie einfach einen neuen Zweig aus der Entwicklung und Sie sind bereit, an der nächsten Sache zu arbeiten.