Git-Rebase für einen gepushten Feature-Branch

Ich habe einen langjährigen lokalen Feature-Zweig, den ich regelmäßig gequetscht und mit master rebasiert habe, um ihn lokal auf dem neuesten Stand zu halten.

Wenn ich fertig bin, möchte ich mein Feature in einem einzigen gequetschten Commit auf dem Master haben.

Ich war jedoch besorgt, meine Arbeit im Falle von Hardwareproblemen zu verlieren, also habe ich dies vorsichtshalber in einen neuen Feature-Zweig auf Github verschoben. Seitdem bin ich mir nicht sicher, wie ich meinen Feature-Zweig auf dem neuesten Stand halten soll, da er bereits gepusht wurde (ich möchte lieber keine Änderungen vom Master zusammenführen, der Merge-Commits erstellt).

Ich bin der einzige Entwickler, der diesen Feature-Zweig verwendet. Ich mache mir also keine Sorgen darüber, den Verlauf eines bereits gepushten Zweigs neu zu schreiben. Ist es in Ordnung, zusätzliche Commits an meinen Remote-Feature-Branch zu pushen, diesen Branch zu quetschen, wenn ich mit dem Feature fertig bin, und ihn dann auf den Master umzubasen? Oder wird git einen Fehler über die Divergenz der Zweige ausgeben, da der Zweig bereits öffentlich war?

Alternativ dachte ich, dass ich, wenn meine Arbeit abgeschlossen ist, den Remote-Feature-Branch einfach untracken könnte (damit mein lokaler Branch keine Verbindung mehr zum Remote-Branch hat), die Commits im lokalen Feature-Branch quetschen und dann mein Feature rebasen könnte verzweigen Sie sich lokal auf dem Master.

Ist es in Ordnung, zusätzliche Commits an meinen Remote-Feature-Branch zu pushen, diesen Branch zu quetschen, wenn ich mit dem Feature fertig bin, und ihn dann auf den Master umzubasen?

Ja, ja und ja. Da Sie gesagt haben, dass Sie keine Angst haben, die Geschichte dieses Zweigs neu zu schreiben, können Sie damit machen, was Sie wollen.

Oder wird git einen Fehler über die Divergenz der Zweige ausgeben, da der Zweig bereits öffentlich war?

Git hat keine Vorstellung von öffentlichen und privaten Zweigen. Du kannst einen Branch öffentlich oder privat nutzen, Git wird sich darüber nicht beschweren.

Wenn Sie Ihren Zweig darauf umbasieren masterspielen Sie Ihre Commits im Grunde ab dem Punkt ab, an dem Sie von der Timeline aus verzweigt sind master. Wenn Commits drin waren master nach diesem Punkt, und Sie haben nach diesem Punkt Commits in Ihrem Feature-Branch gemacht master und Ihr Zweig sind auseinandergegangen. Beim Rebase kann es je nach Änderungen in den beiden Branches zu Konflikten kommen.

Zusammenfassend lässt sich sagen, dass Sie in Ihren undokumentierten Feature-Branches alles tun können, was Sie wollen, und dann eine Rebase darauf aufbauen master. Je nachdem, was Sie tun, kann das Rebasing natürlich einfacher (wenig oder keine Konflikte) oder schwieriger (viele Konflikte) sein. Es ist wahrscheinlich gut, dass Sie oft rebasen, so entdecken Sie Konflikte nach und nach, anstatt viele Konflikte auf einmal.