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

albert0yyyy · 2025-04-21T09:45:16Z

新手刚刚学会提 pr ，有点小打击。我应该维护自己的 fork 分支吗？但是我后面又不是经常维护，还想享受上游的更新咋整

PR

fork

branch

28 replies • 2025-04-23 15:16:10 +08:00

Jinnrry

Apr 21, 2025 via iPhone

1

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

NessajCN

Apr 21, 2025

1

2

fork 可以同步上游更新

anivie

Apr 21, 2025

3

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

lesismal

Apr 21, 2025

2

4

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

albert0yyyy

OP

Apr 21, 2025

5

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

albert0yyyy

OP

Apr 21, 2025

6

@Jinnrry
@NessajCN

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

albert0yyyy

OP

Apr 21, 2025

7

@lesismal QAQ 确实

flyqie

Apr 21, 2025 via Android

8

你可以定时合并 pr

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

UB

Apr 21, 2025

9

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

guanzhangzhang

Apr 21, 2025

10

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

cutiechi

Apr 21, 2025

11

@guanzhangzhang 直接用 gh

sworld233

Apr 21, 2025

12

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

bronyakaka

Apr 21, 2025

1

13

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

ericguo

Apr 21, 2025

14

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

irrigate2554

Apr 21, 2025

15

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

orzorzorzorz

Apr 21, 2025

1

16

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

Pencillll

Apr 21, 2025 via Android

9

17

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

uiosun

Apr 22, 2025

18

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

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

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

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

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

mooyo

Apr 22, 2025

19

先讨论再提 PR 比较好

AstroProfundis

Apr 22, 2025

20

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

LitterGopher

Apr 22, 2025

1

21

我和 #3 的是一样的，然后我在补充几点，关于为何要先提 issue:

1. 你提交的功能可能其他人已经实现了，只是你可能忽略了使用方法
2. 你提交的功能其他人正在实现，提前沟通可以避免有人做无用功
3. 你提交的功能可能不满足对方的‘产品’定位，比如一个生成二维码的库，你提交了一个验证二维码背后的连接是否为钓鱼网站的 PR ，你觉得对方会合并？
4. 提前沟通也有助于帮助其他人，可能其他人也有相通的想法，这时候他们只需要搜索 issue 就能知道是否已经有实现和其他帮助信息（同样也能帮助其他想要为此提交 PR 或有相似疑问的人）
5. 提前沟通可以一起商量一些实现方式，避免 kakakka 写完之后作者觉得你的实现不好而给你拒绝或让你反复修改