Git-Push nach Rebase

Lesezeit: 5 Minuten

Ich weiß, dass diese Frage schon einmal gestellt wurde, aber ich kann mich nicht um diese Sache kümmern …

git checkout master
git pull
git git checkout feature
git rebase origin/master

then resolve all the problems....
Try to push - not gonna happen...

Git sagt mir wirklich, dass nach einer Rebase (Umgang mit n:ths von Konflikten)

Ich habe zwei Möglichkeiten, verwenden --force was riskant und dumm erscheint.

oder pull erneut und sich erneut mit den Zusammenführungskonflikten befassen … und in der gleichen Situation enden?

error: failed to push some refs to 'ssh://[email protected]/yyy/xxx.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Ich habe lokal: Feature Branch, Master ( aktuell )

und remote: featureBranch ( was ist jetzt vorne ?! ) und master.

Ich möchte nur meinen Feature-Zweig aktualisieren, damit er sogar der Version auf dem Master nahe kommt … Warum ist Git so …

Ich habe viele Threads darüber gelesen, und die einzige Lösung scheint zu sein, zu verwenden --force

Diese Dosierung scheint mir überhaupt eine Lösung für ein so häufig verwendetes Werkzeug zu sein …

  • Haben Sie also alle Konflikte gelöst, bevor Sie versucht haben, zu pushen?

    – U. Windl

    14. Mai 2019 um 7:53 Uhr

  • Mögliches Duplikat von Git-Push nach Feature-Branch-Rebase abgelehnt

    – kowsky

    14. Mai 2019 um 8:01 Uhr

Daran ist nichts auszusetzen git push --force aus Prinzip.

Was es tut, ist, den entfernten Kopf Ihrer Filiale durch Ihren lokalen zu ersetzen.

Es gibt zwei Fälle, einen, in dem es in Ordnung ist, Kraft auszuüben, und einen, in dem es überhaupt nicht in Ordnung ist:

Wenn Sie rebasiert haben (und daher eine neue Kette von Commits für Ihren Zweig erstellt haben), sind Ihr Zweig und die Remote auseinandergegangen, was zu erwarten ist. Und Sie haben sie absichtlich voneinander getrennt. Zum Beispiel war Ihre Filiale nicht auf dem neuesten Stand masteralso basierst du es neu, um es darüber zu “bewegen”. master (Technisch gesehen werden die Commits in diesem Fall von der neuen Basis neu erstellt master aber tatsächlich sieht es so aus, als wäre es verschoben worden). Also du kennt dass sie voneinander abweichen und dass Ihre lokale Version die richtige ist. In diesem Fall ist es in Ordnung, git zu sagen: “Nimm diese Version, verwerfe die, die du hast”.

Wenn Sie jedoch mit Personen in demselben Zweig arbeiten und eine Person den Zweig mit neuen Änderungen pusht, während Sie Ihre eigenen Änderungen vornehmen, dann wird Git Ihnen auch mitteilen, dass Ihr lokaler Zweig und sein Upstream auseinandergegangen sind, wenn Sie pushen möchten. und so sollten Sie zuerst ziehen und so weiter. In diesem Fall es ist wichtig nicht push --force Andernfalls wird die Arbeit Ihres Kollegen gelöscht, und er/sie wird ziemlich verärgert sein. In diesem Fall müssen Sie also tatsächlich pull zuerst (ich würde empfehlen pull --rebase keinen Merge-Commit zu erstellen und Ihren Verlauf sauberer zu halten, aber das ist sehr subjektiv), dann push (und nach dem Ziehen, nein --force wird benötigt werden).

Fazit ist, wissen Sie was git push --force wissen, wann es in Ordnung ist, den Upstream mit Ihrem lokalen zu überschreiben (Sie können dann Force drücken) und wann es nicht in Ordnung ist (Sie müssen ziehen).

Und um auf Ihren ursprünglichen Fall zurückzukommen, Sie haben Ihren Zweig umbasiert, sodass er (per Definition) auseinandergegangen ist. Wenn Sie also alleine an dem Zweig arbeiten oder dafür gesorgt haben, dass in der Zwischenzeit niemand etwas darauf geschoben hat, git push --force ist das, was Sie brauchen.

  • Danke, ich denke immer noch, dass dies zu verworren ist. Da ich also den aktuellen FeatureBranch zwangsweise ersetzen werde, bedeutet dies, dass, wenn irgendjemand (andere) aktiv mit FeatureBranch arbeitet und Änderungen hat, noch auf Remote verschoben werden müssen. Alle diese “noch nicht gepushten” Änderungen gehen (für immer) verloren, da es keinen FeatureBranch mehr gibt? Alles, was ich tun möchte, ist, meinen Zweig mit Meister, oh mein Gott, auf den neuesten Stand zu bringen

    – Clomez

    14. Mai 2019 um 11:16 Uhr

  • Ja zu deiner letzten Frage.

    – padawin

    14. Mai 2019 um 11:26 Uhr

  • Wenn Sie mit jemandem in einem Zweig arbeiten (was vertretbar ist, aber das ist eine Workflow-Frage), würde ich Folgendes vorschlagen: Stellen Sie zuerst (vor dem Rebasing) sicher, dass Ihr Zweig mit der Remote (auch bekannt als , Sie haben alles, was sich auf der Fernbedienung befindet), dann rebasieren Sie es, um das zu tun, was Sie brauchen (überarbeiten, es auf dem Master haben …), und schieben Sie dann endlich die Kraft zurück. Und halten Sie Ihre Kollegen auf dem Laufenden.

    – padawin

    14. Mai 2019 um 11:29 Uhr

  • Da ich also den aktuellen Zweig erzwingen werde, bedeutet dies, dass alle diese “noch nicht gepushten” Änderungen verloren gehen, wenn jemand anderes aktiv mit dem Zweig arbeitet und Änderungen nicht gepusht hat, da es keinen Zweig gibt mehr?” Nicht notwendig, sie können mit Merge oder Rebase pullen und so ihre Änderungen beibehalten. “Alles, was ich tun möchte, ist, meinen Zweig mit dem Master auf den neuesten Stand zu bringen“Das ist das Problem. Um die Situation zu vermeiden, die Sie gerade beschrieben haben, dürfen Sie niemals gepushte Commits bearbeiten (ändern, rebasieren, filtern und verzweigen) oder Verzweigungszeiger verschieben (zurücksetzen). Betrachten Sie gepushte Commits/Zweige, die in Stein gemeißelt sind.

    – promov

    14. Mai 2019 um 11:30 Uhr


  • Ich würde Ihrem letzten Kommentar @phd leicht widersprechen und sagen, dass jeder gemeinsam genutzte Zweig oder Basis- / Elternzweig (z. B. Master) nach dem Push unberührt bleiben sollte. Wenn Sie sich wohl genug fühlenspielt es für persönliche Feature-Zweige keine Rolle, und ich würde dazu ermutigen, sie so schnell wie möglich zu pushen, um sie nicht lokal zu haben, aber trotzdem nicht zu zögern, sie zu überarbeiten (obwohl sie nur persönliche Feature-Zweige sind. Sobald sie zusammengeführt sind, sollten sie in Betracht gezogen werden wie fest)

    – padawin

    14. Mai 2019 um 11:33 Uhr


1144090cookie-checkGit-Push nach Rebase

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

Privacy policy