Git-Push nach Feature-Branch-Rebase abgelehnt

OK, ich dachte, das wäre ein einfaches Git-Szenario. Was vermisse ich?

Ich habe einen masterZweig und einen featureZweig. Ich arbeite daran master, einige daran featureund dann noch mehr master. Am Ende habe ich so etwas (die lexikografische Reihenfolge impliziert die Reihenfolge der Commits):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

Ich habe kein Problem damit git push origin master, die Fernbedienung auf dem neuesten masterStand zu halten oder eine Remote-Sicherung für meine Arbeit zu verwalten git push origin feature(wenn diese aktiviert ist feature) feature. Bis jetzt sind wir gut.

Aber jetzt möchte ich mich zusätzlich featurezu den F--GCommits auf Master neu gründen , also ich git checkout featureund git rebase master. Immer noch gut. Jetzt haben wir:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Problem: In dem Moment, in dem ich die neue featureverzweigte Verzweigung sichern möchte git push origin feature, wird der Push abgelehnt, da sich der Baum aufgrund der Neubasierung geändert hat. Dies kann nur mit gelöst werden git push --force origin feature.

Ich hasse es zu benutzen, --forceohne sicher zu sein, dass ich es brauche. Also brauche ich es? Ist die Rebasieren unbedingt bedeuten , dass der nächste pushsein sollte --forceful?

Dieser Feature-Zweig wird nicht mit anderen Entwicklern geteilt, daher habe ich de facto kein Problem mit dem Force-Push. Ich werde keine Daten verlieren. Die Frage ist konzeptioneller.

Das Problem besteht darin, dass git pushdavon ausgegangen wird, dass der Remote-Zweig schnell zu Ihrem lokalen Zweig weitergeleitet werden kann. Das heißt, dass der Unterschied zwischen lokalen und Remote-Zweigen darin besteht, dass am Ende einige neue Commits wie folgt ausgeführt werden:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

Wenn Sie git rebaseCommits ausführen , werden D und E auf eine neue Basis angewendet und neue Commits erstellt. Das heißt, nach dem Rebase haben Sie so etwas:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

In dieser Situation kann der Remote-Zweig nicht schnell zum lokalen Zweig weitergeleitet werden. Theoretisch kann ein lokaler Zweig in einen Remote-Zweig zusammengeführt werden (in diesem Fall benötigen Sie ihn natürlich nicht), aber da git pushnur Schnellvorlauf-Zusammenführungen ausgeführt werden, werden Fehler und Fehler ausgelöst.

Die --forceOption besteht darin, den Status des Remote-Zweigs zu ignorieren und ihn auf das Commit zu setzen, das Sie in ihn verschieben. Also git push --force origin feature-brancheinfach origin/feature-branchmit local überschreiben feature-branch.

Meiner Meinung nach ist es in Ordnung, Feature-Zweige neu zu gründen masterund sie zwangsweise in das Remote-Repository zurückzuschieben, solange Sie der einzige sind, der an diesem Zweig arbeitet.

Anstelle von -f oder --force sollten Entwickler verwenden

--force-with-lease

Warum? Weil es den Remote-Zweig auf Änderungen überprüft, was absolut eine gute Idee ist. Stellen wir uns vor, James und Lisa arbeiten an demselben Feature-Zweig und Lisa hat ein Commit vorangetrieben. James stößt jetzt seine lokale Niederlassung zurück und wird abgelehnt, wenn er versucht zu pushen. Natürlich glaubt James, dass dies auf Rebase zurückzuführen ist und verwendet --force und würde alle Änderungen von Lisa neu schreiben. Wenn James --force-with-lease verwendet hätte, hätte er eine Warnung erhalten, dass es Commits gibt, die von jemand anderem gemacht wurden. Ich verstehe nicht, warum irgendjemand --force anstelle von --force-with-lease verwenden würde, wenn er nach einer Rebase pusht.

Ich würde stattdessen "checkout -b" verwenden und es ist leichter zu verstehen.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

Wenn Sie löschen, verhindern Sie, dass ein vorhandener Zweig mit einer anderen SHA-ID eingegeben wird. In diesem Fall lösche ich nur den Remote-Zweig.

Eine Lösung hierfür besteht darin, das zu tun, was das Rebasing-Merge- Skript von msysGit tut - nach dem Rebase den alten Kopf von featurewith zusammenzuführen -s ours. Am Ende erhalten Sie das Commit-Diagramm:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... und Ihr Push-of featurewird ein schneller Vorlauf sein.

Mit anderen Worten, Sie können tun:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Nicht getestet, aber ich denke das ist richtig ...)

Es kann sein, dass sich in diesem Zweig nur ein Entwickler befindet oder nicht, der jetzt (nach der Rebase) nicht mit dem Ursprung / der Funktion übereinstimmt.

Als solches würde ich vorschlagen, die folgende Sequenz zu verwenden:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Ja, neuer Zweig, dies sollte dies ohne --force lösen, was meiner Meinung nach im Allgemeinen ein großer Nachteil ist.

Ich vermeide den Force Push, indem ich einen neuen Zweig erstelle und die Arbeit an diesem neuen Zweig fortsetze und nach einiger Stabilität den alten Zweig entferne, der neu basiert wurde:

• Den ausgecheckten Zweig lokal wiederherstellen
• Verzweigen von der neu basierten Verzweigung zu einer neuen Verzweigung
• Verschieben dieses Zweigs als neuen Zweig auf Remote. und Löschen des alten Zweigs auf der Fernbedienung

Andere haben Ihre Frage beantwortet. Wenn Sie einen Zweig neu gründen, müssen Sie erzwingen, um diesen Zweig zu verschieben.

Rebase und ein gemeinsam genutztes Repository verstehen sich im Allgemeinen nicht. Dies schreibt die Geschichte neu. Wenn andere diesen Zweig verwenden oder von diesem Zweig verzweigt haben, ist eine erneute Basis ziemlich unangenehm.

Im Allgemeinen funktioniert Rebase gut für das lokale Filialmanagement. Die Remote-Zweigstellenverwaltung funktioniert am besten mit expliziten Zusammenführungen (--no-ff).

Wir vermeiden auch, Master in einen Feature-Zweig zusammenzuführen. Stattdessen werden wir auf Master zurückgesetzt, jedoch mit einem neuen Zweignamen (z. B. Hinzufügen eines Versionssuffix). Dadurch wird das Problem der erneuten Basierung im gemeinsam genutzten Repository vermieden.

Was ist los mit einem git merge masterauf dem featureAst? Dadurch bleibt Ihre Arbeit erhalten, während Sie sie vom Hauptzweig trennen.

A--B--C------F--G
       \         \
        D--E------H

Edit: Ah sorry hat deine Problemstellung nicht gelesen. Sie benötigen Kraft, wenn Sie a rebase. Alle Befehle, die den Verlauf ändern, benötigen das --forceArgument. Dies ist ausfallsicher, um zu verhindern, dass Sie Arbeit verlieren (die alte Dund Ewürde verloren gehen).

Sie haben also eine ausgeführt, git rebasedie den Baum so aussehen ließ (obwohl er teilweise versteckt ist Dund Esich nicht mehr in einem benannten Zweig befindet):

A--B--C------F--G
       \         \
        D--E      D'--E'

Wenn Sie also versuchen, Ihren neuen featureZweig (mit D'und E'darin) zu verschieben, verlieren Sie Dund E.

Für mich funktionieren folgende einfache Schritte:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

Nachdem Sie alle oben genannten Schritte ausgeführt haben, können Sie auch den myFeature-Zweig mit dem folgenden Befehl löschen:

git push origin --delete myFeature

Folgendes funktioniert für mich:

git push -f origin branch_name

und es entfernt keinen meiner Codes.

Wenn Sie dies jedoch vermeiden möchten, können Sie Folgendes tun:

git checkout master
git pull --rebase
git checkout -b new_branch_name

Dann können Sie alle Ihre Commits für die neue Niederlassung auswählen. git cherry-pick COMMIT ID und dann schieben Sie Ihren neuen Zweig.

Da das OP das Problem versteht, sucht es nur nach einer schöneren Lösung ...

Wie wäre es damit als Übung?

• Haben Sie auf tatsächlichen Feature-Entwicklungszweig (wo Sie nie neu gründen und erzwingen, damit Ihre Kollegen Feature-Entwickler Sie nicht hassen). Hier können Sie diese Änderungen regelmäßig mit einer Zusammenführung von main abrufen. Messier Geschichte , ja, aber das Leben ist einfach und niemand wird in seiner Arbeit unterbrochen.

• Haben Sie einen zweiten Zweig zur Entwicklung von Funktionen, in dem ein Mitglied des Feature-Teams alle Feature-Commits regelmäßig dazu drängt, tatsächlich neu zu gründen, tatsächlich zu erzwingen. Also fast sauber basierend auf einem relativ neuen Master Commit. Wenn die Funktion abgeschlossen ist, schieben Sie diesen Zweig auf den Master.

Möglicherweise gibt es bereits einen Musternamen für diese Methode.