Verwalten eigene Fork von Vim-Plugins mit Vundle

Question

Ich benutze Vundle als Plugin-Manager in Vim und es passiert, dass ich Änderungen an einigen Plug-Ins vornehmen möchte, um Fehler zu korrigieren oder persönliche Änderungen zu implementieren.

Was ich in der Regel tun, ist

1. Gabel das Original Repo
2. bearbeiten die .vimrc Datei und ändern Sie die Zeile Plugin 'original-repo'-Plugin 'my-fork', laufen :so % und dann :PluginInstall
3. Änderungen vornehmen und sich verpflichten
4. Drücken Sie auf meine Gabel
5. senden Sie eine PR

An dieser Stelle kann der PR akzeptiert oder abgelehnt werden. Im ersten Fall ist alles in Ordnung. Was ist mit dem letzteren Fall?

Was ich meine ist, dass ich im Allgemeinen beschließen kann, die nicht akzeptierte Bearbeitung in meinem fork zu behalten (ich habe es gerade erst begangen), sowie im lokalen Zweig (das heißt, ich behalte Plugin 'my-fork' in meinem .vimrc Datei), da ich diese Bearbeitung für wichtig halte, aus irgendeinem Grund. Auf der anderen Seite möchte ich nicht, dass mein Fork alt wird, nur weil ich durch ein oder wenige Commits divergierte; das heißt, ich möchte immer noch, dass meine Gabel neue Commits des ursprünglichen Repos enthält. Außerdem möchte ich immer noch in der Lage sein, PR von anderen Commits, die ich tun kann, zu senden, wobei ich auf die PR-Best Practice des Sendens von PRs aus einem synchronisierten Fork achten muss.

kann ich mir vorstellen, was die Werkzeuge für den Zweck geeignet sind, das heißt

• die Bahn die Gabel zum Erstellen und senden PRs
• git verschiedenen Zweigen der örtlichen fork
• Vundle verwalten Vim zu verwalten Plugins

die ich bereits verwende.

Also die Frage ist: Was ist der Workflow, den ich befolgen sollte, um Vim-Plugins zu verwalten, an denen ich möglicherweise mit PRs commits teilnehmen kann (und ich kann natürlich nicht im Voraus wissen, welche PRs akzeptiert und welche abgelehnt werden)?

Answer 1

GitHub als ganze Anleitung gewidmet working with forks.

Kurz:

1. Sie eine neue Remote-Repository definieren, die auf den ursprünglichen Punkte,
2. Sie holen und fusionieren aus, dass „upstream“ Remote-Repository Repository synchron zu halten.