Wie pflege ich ein gegabeltes Git-Repo mit Feature-Zweigen, die stromaufwärts nicht gezogen werden?

Hier ist ein typischer Workflow für Github ...

Wie ein Projekt ->gabelt es -> git clone https://github.com/you/someproject.
Offenes Projekt. Wie das, was Sie sehen, aber nehmen Sie einige Änderungen vor.
Nachdem Sie darauf geachtet haben, nur in a feature-branch( git checkout -b some-feature) zu arbeiten, entscheiden Sie sich, eine Pull-Anfrage beim upstreamBetreuer zu stellen - nachdem Sie feature-branchIhre Github-Gabel gedrückt haben .
Der Maintainer lehnt aus irgendeinem Grund die Zugkraft ab.

Zum Beispiel ... hier ist eine fehlgeschlagene Pull-Anfrage, die ich gesendet habe und die dem obigen Szenario entspricht. ..

Nun normalerweise , wenn der Maintainer HAD fusioniert den Zug ... der Workflow wäre einfach ... auf meinem lokalen Rechner, ich würde alle lokalen Änderungen daran setzen , was auch immer feature-branchich war zu der Zeit ... git fetch --all, git checkout master, git pull upstream --ff-only. Dann spielen Sie meine Änderungen darüber hinaus nach Wunsch ab ...

ABER...

Was ist, wenn ich beschließe, dass Sie die Änderungen an meiner Gabel leider weiter bearbeiten möchten ... und dennoch in der Lage sein möchten, auftretende Änderungen zu verfolgen und zusammenzuführen upstream? Normalerweise lösche ich den Feature-Zweig und mache mich auf den Weg. Wie können Sie einen masterZweig pflegen , der stromaufwärts zusammengeführt werden kann, aber die Funktionen Ihrer Gabel beibehält, während Sie "permanent von den upstream" getrennt sind HEAD?

— alex grau
quelle

Unentgeltliche Änderungen an der Formatierung werden für kein einzelnes Projekt akzeptiert, von dem ich jemals gehört habe. Wenn Sie darauf bestehen, sie in Ihrem Repository zu behalten, heißen wir Sie in Ihrer kleinen, wohlverdienten Hölle willkommen. Wenn Sie nur Warnungen bereinigt haben, werden sie höchstwahrscheinlich akzeptiert, obwohl Sie möglicherweise immer noch aufgefordert werden, sie aufgeteilt in Teile mit angemessener Größe zu senden. Sogar Änderungen, um die Formatierung selbstkonsistent zu machen, werden möglicherweise akzeptiert. Änderungen, die die Formatierung auf eine andere ändern, werden jedoch nie vorgenommen. Weil alle anderen an die aktuelle Formatierung gewöhnt sind und Probleme beim Zusammenführen verursachen.

— Jan Hudec

Nur für den Kontext lautet die unterschiedliche Statistik der Pull-Anfrage: "15 geänderte Dateien mit 832 Hinzufügungen und 1.478 Löschungen

@ Jan Hudec Meine Frage ist, wie man die Werkzeuge benutzt ... NICHT, wenn dir meine Pull-Anfrage gefällt , lol. Persönlich kann ich mich nicht mit einer RIESIGEN Lizenz (für ein OSS-Projekt) am Anfang jeder Fing-Datei befassen, daher die große Anzahl von Löschungen. Und die anderen Änderungen waren konventionell und haben nichts anderes getan, als Compiler-Warnungen zu entfernen und zu machen der Code tatsächlich lesbar. Unabhängig davon geht es bei dieser Frage darum, wie man "anders arbeiten" kann, ohne zu erfahren, was "richtig" und "falsch" ist.

— Alex Grey

@alexgray: Deshalb schreibe ich es nicht als Antwort, sondern als Kommentar.

— Jan Hudec

Unabhängig von der Verwendung Ihres Szenarios können Sie dies folgendermaßen tun:

Master ist genau die Version, die der Upstream-Master hat
custom ist Ihr eigener "Master" -Zweig, in dem Sie die Formatierungsänderungen angewendet haben
Alle Feature-Zweige werden benutzerdefiniert verzweigt, wenn Sie nicht möchten, dass sie in den Upstream-Master gezogen werden
Sobald der Master aktualisiert wurde, werden Benutzerdefiniert auf Master und dann Ihre Feature-Zweige auf Benutzerdefiniert zurückgesetzt

Mit dieser Strategie sollte es funktionieren. Beachten Sie jedoch, dass jede Änderung, die Sie an einem benutzerdefinierten Feature-Zweig vornehmen, nicht in den Upstream-Master übernommen wird.

— Jim Martens
quelle