这是一个创建于 3031 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在 github 上为一个项目贡献代码(其实也就是帮忙改改 bug 加点小功能),然后每次都被作者 if you ...... I will be happy to merge
问题包括
命名规范和代码规范(驼峰命名,私有方法命名,换行问题)
一个 issue 里面提了很多问题(作者说要尽量分开)
无意义修改(只是把一些代码位置调整)
感觉作者都快被我弄烦了
想请教一下各位,作为贡献者,你们平时是怎么做的,有哪里需要注意的;作为项目的拥有者,你们比较反感什么样的 pull request 或者 issue 呢?
问题包括
命名规范和代码规范(驼峰命名,私有方法命名,换行问题)
一个 issue 里面提了很多问题(作者说要尽量分开)
无意义修改(只是把一些代码位置调整)
感觉作者都快被我弄烦了
想请教一下各位,作为贡献者,你们平时是怎么做的,有哪里需要注意的;作为项目的拥有者,你们比较反感什么样的 pull request 或者 issue 呢?
 |
1
Return2legacy 2016-08-07 07:29:14 +08:00 via Android  1
其实最烦的是只开一个分支，然后一个 PR 就推一堆上去，而且可能还在不断更新，然后还叫你自己看着用。
|
 |
2
sox 2016-08-07 08:33:07 +08:00 via Android 1
代码风格这个只能靠 linter 解决吧
|
 |
3
clino 2016-08-07 08:36:47 +08:00 via Android 1
你自己多注意一下原作者用的编程规范吧
其实经验越多一般对这些方面会更注意 我曾经对一个 patch 做 code review 做了快 20 次才过 |
 |
4
fcicq 2016-08-07 08:45:49 +08:00 1
有耐心慢慢改就好, 但是不要触及对方的耐心极限(提交讨论的次数 /频率可能有不成文的限制), 能一次改好的不要改两次. 多人管理的项目可能需要私下先疏通征求意见避免彻底失去 merge 的希望. 而对大型的项目做贡献有折腾好几年的准备也就可以了.
|
 |
5
raincious 2016-08-07 08:51:05 +08:00 1
如果你要修 Bug 的话，为了整洁应该一个 Bug 一个 Bug 的修复，不要一次改动太多代码，否则 Review 起来别人也头疼。
|
 |
6
eloah OP @Return2legacy 我都有好好说明改动和为什么改动的,这样的话可以吗
|
|
7
eloah OP |
 |
10
airyland 2016-08-07 10:11:56 +08:00 1
1.看 contribution 规范(其中也包含了代码规范)
2.先沟通再 PR ，这个很重要，不要浪费彼此时间 3.先 rebase 不要多个 commit 甚至 conflict 4.commit 写有意义的，不要写 "update index.html", 要写英文 5.新特性请补充 demo(如果有的话)，补充 test(如果有的话) 6.修改的话不要重开 PR ，不要重开 PR ， 不要重开 PR ！！！自行 squash 7.作者提出修改意见时，请及时更新 暂时想到就这么多。。 |
 |
11
kn007 2016-08-07 10:14:23 +08:00 1
用英文，作者要是有对 PR 什么建议，合理照做就是了。
|
|
12
Return2legacy 2016-08-07 11:00:21 +08:00 via Android
@eloah 每个 commit 有必要说明这是提高效率，如你所说的第二条和 5 楼所说的，每条 commit 尽量针对单一问题，或者说单一特性，精炼但不繁复，因为要顾及到后期维护， revert 也好什么也好，能易操作的。每个 PR 要有条理，然后就是代码质量问题了。
|
 |
14
JamesRuan 2016-08-07 17:45:51 +08:00 1
哈哈，我的 github 项目就见过一次 PR ，把我激动地不行了。
然后我依然是： If you ...... I will be happy to merge 。 实在是发 PR 的人的代码质量和我的要求差别太大，两个来回后我就受不了了，直接在他的基础上自己手动改了 merge 了完事。 |
|
17
eloah OP @Return2legacy 好的,明白啦,非常感谢
|
Select Language