对上游提 pr，上游的管理员觉得 pr 里面的功能他不需要或者不满意

[albert0yyyy]

新手刚刚学会提 pr ，有点小打击。

我应该维护自己的 fork 分支吗？

但是我后面又不是经常维护，还想享受上游的更新咋整

[Jinnrry]

自己维护，定时 merge 上游不就行了

[NessajCN]

fork 可以同步上游更新

[anivie]

你提 pr 之前没先跟对方商量吗……

[lesismal]

很正常，没必要心理这么脆弱，有其他的可以继续 pr ，平常心，凭借兴趣、爱好、良好的愿景去做这些，顺其自然就好了

[albert0yyyy]

@anivie 我需要发邮件问问管理员是吗，比如我想做这个功能，问问他们上游需不需要，然后他们的想法还有我的想法

[albert0yyyy]

@Jinnrry
@NessajCN

如果和我写的代码冲突，然后我自己解决冲突就可以是嘛

[albert0yyyy]

@lesismal QAQ 确实

[flyqie]

你可以定时合并 pr

我就单独维护了一个 facebook/idb 分支

[3085570450tt]

@albert0yyyy #5 无需发邮件，开 issue 讨论即可。加油

[guanzhangzhang]

git remote add upstream https://github.com/xxx/xxx
git fetch upstream main
git rebase upstream/main

[superchijinpeng]

@guanzhangzhang 直接用 gh

[sworld233]

正常来说应该先开个 issue ，和仓库 maintainer 讨论确定之后，再开分支提 PR ，最终审查通过了合并。如果 maintainer 不愿意接受的话就只能自己 fork 然后更新了

[bronyakaka]

看下人家项目里的 CONTRIBUTING.md 贡献规则，很多要求先 open 个 issue ，否则会被直接关闭。
我有个项目也是，突然来个 pr 跟我说集成了 ai 功能，不想合并直接掘拒绝又有点残忍，搞得很尴尬

[ericguo]

上游有权利拒绝，很正常，这个功能你真的需要自己维护就好。加新功能一定要先开 issue 讨论，不过即使开了 issue ，讨论了，上游仍然有权利拒绝，而且从我的历史提 PR 经验来看，越是资深开发者，越是行使这个权利没有心里负担，所以 OP 接受就好了。掌控权永远在上游。

[irrigate2554]

fork 出来自己定时同步就好了，你看看我仓库几十个 fork 的项目都是这样的

[orzorzorzorz]

看你目的了。
如果是觉得“这功能很屌我踏马就想放在这项目里”，那你得做一整套的说服动作。从需求分析到代码打包独立拆分，从独自扛起大旗到“哎可以给需要的人加个开关的”的小绿茶，就看你能不能吃得下这套代价了。
如果是练个手，那可以把 pr 链接丢出来挂 v2 上，起个标题说“现在的开源项目真的高傲，我好心开个 pr 到最后直接被关了”，然后就能收获颗粒化到缩进的批评，对心态的磨炼是很有效果的。
当然可以不用这么激进，那句话怎么说来着，最痛苦的时候就是你成长最快的时候，加油。

[Pencillll]

要知道添加了新功能之后，你没有责任来进行后续维护，但管理员有责任，这是会增加负担的，所以对新功能持保守态度很正常

[uiosun]

@albert0yyyy #5 正常来说，PR 是基于 Issue 的，你可以从单词语义上理解这个流程。

所以，如果莫名其妙的就蹦出来一个 PR ，作为管理者，保持一种防御心态有助于软件的整洁，可以理解。

如果你觉得很需要，就提出自己的意见，如果你俩/或多个管理员无法形成共识，且项目对这个功能并没有明确禁止，就提 Issue 来征求更广泛的意见。

这是一个比较正常的流程，就算是最终被拒绝了，也无需难受，这在开源世界太正常了。

举点碰到的极端例子：PR 提了，功能大家都很需要，两位管理员也表示称赞，但提出一个小小的语法错误，你以为马上就能合并？结果是两年后才合并。

[mooyo]

先讨论再提 PR 比较好

[AstroProfundis]

很正常，这属于标准的应该自己 fork 一个的场景