我使用Vundle作为Vim中的插件管理器,有时我想对某些插件进行修改以更正错误或实现个人更改。
一般来说我会这样做:
1. fork原始repo 2. 编辑`.vimrc`文件并将行`Plugin 'original-repo'`更改为`Plugin 'my-fork'`,运行`:so %`然后`:PluginInstall` 3. 进行更改并提交 4. 推送到我的fork 5. 发送PR
此时,PR可能会被接受或拒绝。如果是前者,一切都好。如果是后者呢?
我的意思是一般情况下我可以决定在我的fork中保留未被接受的编辑(毕竟我刚提交了它),以及本地分支中(也就是,我在我的`.vimrc`文件中保留了`Plugin 'my-fork'`),因为我认为这个编辑对我来说很重要,出于某种原因。 另一方面,我不想让我的fork因为我分支发生了一两个提交而变得陈旧;也就是说,我仍然希望我的fork包含原始repo的新提交。 此外,我还想能够发送其他提交的PR,注意发送PR的最佳实践是从同步的fork发送PR。
我可以想象工具是有针对性的,比如:
- 网络用于创建fork和发送PR - `git`用于管理本地fork的不同分支 - `Vundle`用于管理Vim插件
这些我已经在使用了。
因此问题是:我应该遵循什么工作流来管理Vim插件,以便我可以参与提交PR(显然我无法事先知道哪些PR会被接受,哪些会被拒绝)?
一般来说我会这样做:
1. fork原始repo 2. 编辑`.vimrc`文件并将行`Plugin 'original-repo'`更改为`Plugin 'my-fork'`,运行`:so %`然后`:PluginInstall` 3. 进行更改并提交 4. 推送到我的fork 5. 发送PR
此时,PR可能会被接受或拒绝。如果是前者,一切都好。如果是后者呢?
我的意思是一般情况下我可以决定在我的fork中保留未被接受的编辑(毕竟我刚提交了它),以及本地分支中(也就是,我在我的`.vimrc`文件中保留了`Plugin 'my-fork'`),因为我认为这个编辑对我来说很重要,出于某种原因。 另一方面,我不想让我的fork因为我分支发生了一两个提交而变得陈旧;也就是说,我仍然希望我的fork包含原始repo的新提交。 此外,我还想能够发送其他提交的PR,注意发送PR的最佳实践是从同步的fork发送PR。
我可以想象工具是有针对性的,比如:
- 网络用于创建fork和发送PR - `git`用于管理本地fork的不同分支 - `Vundle`用于管理Vim插件
这些我已经在使用了。
因此问题是:我应该遵循什么工作流来管理Vim插件,以便我可以参与提交PR(显然我无法事先知道哪些PR会被接受,哪些会被拒绝)?
.vimrc
中保留Plugin 'name/repo'
行用于那些我不编辑/协作等的插件,而对于我编辑/...的插件则使用Plugin 'myname/myfork'
吗? - Enlico